Voice AI is easy. Reservations are hard.
A 50+ property hospitality chain reversed a 32–41% year-over-year decline in the voice channel at its pilot properties in 60 days. The differentiator wasn't the voice model — it was a forward-deployed method that brought the property's PMS provider, the client's contact center, and the client's operations team into one working loop, building a shared data model of how reservations actually behave at each property.
A reservation call is not a conversation problem. It's a systems problem.
The starting point
Going into peak season, the two properties disclosed here were running 32–41% behind the prior year on voice bookings. The reservation team was stretched, after-hours callers rang out, and the true size of the miss was unknowable — you cannot report on calls you never answer.
The scale became visible only after launch: the AI immediately began answering 3.5–3.9x more calls than the human channel had been handling. That demand had existed all along.
Why most voice AI stalls
Speech technology is now a commodity. What defeats deployments is everything beneath the conversation: a payment link that expired mid-call, a booking that originated on an OTA rather than the brand site, a wedding block with its own forwarding policy, a guest the GM insists must always reach a human.
That knowledge lives in three different places — the PMS, the contact center, and the operations team — and in most hotels, no single system speaks all three languages.
The forward-deployed answer
Dextr staffs each client with a dedicated forward-deployed engineer (FDE), paired with an AI strategist and supervised by experienced operators. Their job is not to tune prompts. It is to convene three parties — the property's PMS provider, the client's contact center, and the client's operations team — in a twice-weekly working loop, and to turn what each party knows into a single, shared data model: an operational ontology of how reservations behave at each property. The AI runs on that ontology; every session versions it forward.
Best Practice · VP of Operations
If a policy lives in someone's head, the AI cannot honor it. High-touch guest lists, block-forwarding rules, escalation thresholds — most "AI failures" in production turn out to be policy ambiguities no one had ever written down. Put operations in the working loop from day one, and treat every escalation review as an opportunity to codify one more rule.
Three parties, one ontology, versioned twice a week.
Each party holds a piece of the truth. The PMS holds rates, inventory, and payment state. The contact center holds how calls actually go. Operations holds the policies that make each property itself. The FDE's twice-weekly loop moves knowledge in all three directions, and the output is cumulative:
A shared vocabulary for reservation states — so "modified," "expired," and "blocked" mean the same thing to every system and every person
Fluid data flow — the AI reads and writes the system of record directly; no parallel rate sheets, no swivel-chair reconciliation
Property-level fidelity — the model absorbs each property's quirks — inventory rules, seasonal guidance, guest-routing policy — instead of averaging them away
What the ontology covers — 55+ use cases, in eight families
Booking & payments
New reservations across room types and configurations, with the complete payment lifecycle handled end to end.
Provenance-aware servicing
Lookups, cancellations, and changes that respect where a booking originated — without making the guest explain it.
Modifications
Changes of every shape, with the correct financial outcome posted to the system of record.
Groups & events
Event blocks established, booked within, and routed according to each block's own policy.
Escalation & routing
Property-defined rules for when the AI resolves — and when, and where, a human takes over.
Guest services
Common guest requests — before and during the stay — resolved or routed by policy.
Notifications & recovery
Missed communications caught and recovered, with graceful fallbacks when something upstream fails.
Property-specific policy
The local details and house rules that make an answer sound like the property, not a bot.
A declining channel, reversed in one cycle.
Voice-channel revenue finished 3–6% ahead of the prior year at both properties — and 46–70% above each property's own no-AI trajectory (its pre-launch trend extended through the same 60 days).
The AI out-booked the human channel at both properties while agents kept the complex bookings — and its bookings carried 15–17% higher ADR. Conversion climbed week over week as the ontology deepened.
Best Practice · SVP of IT / CIO
Fund a bounded pilot; define the counterfactual up front. Vendor benchmarks are unfalsifiable — your own pre-launch trend is not. Set a 60-day window, agree on the trajectory math before go-live, and require reporting against it. Then hold the result to a high bar: here, the ROI multiple was large enough to survive any reasonable attribution haircut.
On conversion: the AI serves a broader, lower-intent call pool than agents do, so blended comparisons mislead. Its conversion rate rose steadily across the 60 days as the integration deepened.
What each buyer should take from this case.
VP of Operations
Owns the reservation team, staffing, service levels — and the policies that make each property itself
- Measure the demand you're missing before you staff for it. After-hours and overflow demand here was 3.5–3.9x the answered volume — none of it visible in any report until every call was answered
- Route by intent, and judge the channel honestly: AI takes volume, agents take complexity. Blended conversion against your best agents is the wrong yardstick; total channel revenue, containment, and reclaimed agent hours (50–60% here) are the right ones
- Bring operations into the loop as a first-class party. The twice-weekly sessions exist to codify what only your team knows — high-touch guest lists, block-forwarding rules, escalation thresholds. The ontology is only as good as what you put into it
SVP of IT / CIO
Owns the systems, the integration surface, and the investment case
- Evaluate integration depth as taxonomy coverage, not a feature count. Ask a vendor to walk the payment-link lifecycle, OTA-vs-direct provenance, and group-block inventory in your PMS. Here, 55+ live PMS use cases — with no parallel copy of rates — is what made accurate quoting and direct booking possible
- Demand provenance-aware design: the AI should know where a booking originated without asking the guest. That single property of the data model eliminates a whole class of failed calls
- Buy the operating model, not just the model. A named FDE paired with an AI strategist, supervised by experienced operators; an ontology that is a versioned, inspectable artifact rather than a vendor black box; and near-zero internal IT lift after go-live
See what your unanswered calls are worth.
Talk to the Dextr team about a 60-day pilot on your own inventory, measured against your own trajectory.