Relay booking core
Tenant isolation, reservations, inventory, rate plans, audit records, recovery queues, operator identity bindings, and activation receipts are implemented for release validation.
Relay is being prepared for hotels that need direct Booking.com, Expedia, and Agoda distribution, a native Windows connection to an approved Yardi or InnSoft Check-Inn interface, visible reconciliation, and guarded pricing.
OAuth login alone does not authorize inventory, reservation, or rate access. Live capability is shown only after provider, property, and production checks have receipts.
Tenant isolation, reservations, inventory, rate plans, audit records, recovery queues, operator identity bindings, and activation receipts are implemented for release validation.
Direct provider adapters stay disabled until each provider accepts the business, property, technical, security, and certification requirements.
The Windows connector uses an outbound-only service boundary. A live adapter requires the vendor-supported interface, hotel authorization, and property-side test environment.
Guardrails cap rate changes, preserve floors and ceilings, and log each recommendation. No unattended automatic pricing starts before the pilot and written approval.
Every package is a custom quote because room count, PMS contracts, provider accounts, Windows hardware, and support expectations vary by property.
A fixed discovery and evidence package before live system access.
One approved property moved through configuration, controlled connection, reconciliation, and staff handoff.
Ongoing operational coverage after a property passes its launch checks.
AES does not hide vendor fees inside a software claim or advance unapproved third-party charges.
PMS licenses, service contracts, interface or certification fees, vendor support, OTA charges, payment-provider fees, property hardware, Windows licensing, networking, email, and domains remain the hotel's responsibility.
Readiness work, implementation, Relay hosting, connector setup, monitoring, operational support, and approved custom work are quoted separately by AES.
Before a paid vendor step, the hotel receives the known amount or estimate, who charges it, what capability it enables, and whether it is recurring. Work stops at that gate until written approval is recorded.
Confirm ownership, rooms, rate plans, taxes, policies, staff roles, Windows environment, and the actual PMS version.
Complete direct OTA and PMS applications using the hotel's real business contracts. Passwords and MFA stay with the account owner.
Map identifiers, replay sample changes, reconcile reservations and inventory, prove recovery, and keep live writes disabled.
Enable only approved capabilities, monitor every sync, begin pricing as recommendations, and keep rollback available.
The hotel signs off on acceptance results, vendor costs, support ownership, incident contacts, and any later move to automatic pricing.
A founder will review the PMS, channel, room-count, and operating context and return the smallest useful first scope.
Do not send passwords, API keys, MFA codes, payment data, guest records, or copies of vendor contracts through this form.