One Phone Number, Two Audiences — A 200-Room Hotel Serves Human Guests and OTA Booking AI from the Same Agent

The hotel's director of revenue had a problem that didn't have a clean name in any vendor's sales deck.

About 15% of the hotel's reservations came from OTA systems that called the hotel directly — automated booking agents operated by the major travel platforms, which phoned to verify live availability and rates before completing reservations on their end. These systems called the main hotel number. A human had to answer.

At the same time, that same main number fielded calls from actual guests: reservation questions, early check-in requests, accessibility needs, local recommendations, loyalty program queries. Those callers needed a warm, helpful voice experience.

One phone number. Two completely different audiences with completely different expectations. The previous solution was two separate systems patched together: a dedicated API integration for OTA systems, and a standard phone system with a script-following agent for human callers. Two vendor contracts. Two configurations to keep synchronized. Two sources of truth for availability data.

"When our rates changed, I had to update in two places," the revenue director said. "When the PMS integration broke, it broke in one place but not the other and nobody noticed for three days."

The Situation

The hotel — 200 rooms, independent flag, urban market — was operating at 73% average occupancy. OTA channels represented approximately 35% of total bookings, with a meaningful portion of that coming through the automated booking call systems that the major platforms use for real-time inventory verification.

The OTA engineering teams that had built these systems were not calling a human to have a conversation. They were calling a number and expecting structured data. If a human answered, the interaction was awkward and slow — the caller AI would ask highly specific questions ("What is the rate for a standard king for two adults checking in April 14 and out April 16?") and a human would have to navigate to the PMS to look up the answer, while the calling AI waited on hold.

The human phone system, meanwhile, was handling a mix of guest inquiries where natural language mattered: guests who weren't sure what room type they'd booked, guests asking about amenities, travelers asking how far the hotel was from the convention center. An IVR menu was not appropriate for those callers.

The two-system approach had worked, but barely. The API integration for OTAs required dedicated engineering support from the PMS vendor ($850/month retainer), was brittle against version updates, and had broken three times in the previous year — each outage causing OTA reservations to stall or route to voicemail.

The Approach

Mode 5 is WFW's dual-mode configuration: one agent, one phone number, two response modes. The agent detects whether the caller is a human or an AI system within the first 500 milliseconds of the call and responds accordingly — natural voice for human callers, structured JSON for bot callers.

The implementation used Opera Cloud as the PMS integration: real-time availability, rate plan lookup, room type inventory, and reservation creation were all piped through a single API connection. That connection served both caller types. When a human asked "do you have anything available next weekend?", the agent queried Opera Cloud and responded conversationally. When an OTA booking AI called and sent a structured availability request, the agent queried the same Opera Cloud endpoint and returned:

{
  "available": true,
  "rate": 189.00,
  "currency": "USD",
  "room_type": "king_standard",
  "check_in": "2026-04-14",
  "check_out": "2026-04-16",
  "guests": 2,
  "booking_url": "https://[hotel-domain]/book?type=king_standard&checkin=2026-04-14&checkout=2026-04-16"
}

One data source. One integration. One phone number.

The bot detection mechanism relied on the caller identification pattern described in the WFW caller-type detection architecture: OTA booking AI systems announce themselves with a specific header format at call initiation. Human callers don't. The misclassification rate in the first 30 days was zero — no human callers received JSON responses, and no OTA systems received conversational hold music.

The Configuration

For human callers, the agent was configured with:

• Full room type inventory with descriptions (not just categories)
• Rate explanation logic ("our best available rate for that date is $189 — that's our standard rate, and you'll save 10% booking directly versus what you'd see on third-party sites")
• Loyalty program enrollment and points balance lookup
• Amenity information (parking, restaurant hours, fitness center, pet policy)
• Local area guidance (airport distance, convention center proximity, nearby transit)
• Escalation path to the front desk for complex requests

For OTA bot callers, the agent was configured to:

• Return availability and rate data in the standardized JSON format the OTA systems expected
• Create provisional holds on inventory during active OTA conversations (to prevent double-booking during the booking confirmation window)
• Return a booking_url that deeplinked directly into the hotel's reservation engine with pre-populated parameters
• Handle the OTA's follow-up confirmation call (a second bot call once the guest completed booking on the OTA platform, which updated the reservation status in Opera Cloud)

The revenue director configured the rate display logic once: which rate plans to surface for which channels, how to handle blackout dates, and how to respond to requests outside the standard booking window. That configuration applied to both caller types from the same interface.

The Results

OTA integration maintenance cost: Eliminated. The $850/month PMS API retainer was cancelled. The OTA integration is now handled by the WFW Opera Cloud connection, which is maintained as part of the platform.

OTA availability outages: Zero in the first six months, compared to three in the prior year. A single API integration has fewer failure points than two separate systems with different maintenance schedules.

Direct bookings from OTA channel: Up 3 percentage points. The booking_url in the JSON response now pointed to the hotel's own booking engine with a direct-rate incentive. A portion of OTA callers who received the structured response followed the booking URL directly rather than completing the OTA transaction. That 3% shift in booking source, at the hotel's OTA commission rate of 18%, translated to approximately $7,200/month in commission savings.

Human caller experience: Net Promoter Score for phone interactions increased 11 points over the prior 6-month baseline. The improvement was attributed primarily to faster response times and the elimination of hold music during rate lookups.

The Intelligence Loop

Workforce Wave's 30-day review surfaced one significant optimization opportunity: the agent was not surfacing the direct booking incentive early enough in conversations with human callers who mentioned having found the hotel on a third-party site.

The original configuration waited for the caller to ask about rates before mentioning the direct booking advantage. Workforce Wave found that 40% of callers who mentioned OTA sites abandoned the booking conversation before rates came up — they were researching, not ready to commit. A revised prompt introduced the direct booking mention earlier: "Since you mentioned you found us on [OTA site], I can tell you that booking directly through our website will get you our best rate — I can send you a link right now if you'd like."

The mention-to-direct-booking conversion rate on that cohort improved from 11% to 28%.

A second optimization addressed OTA bot calls that arrived with incomplete parameters (requests missing a checkout date, or with invalid room type codes from outdated OTA system configurations). The original agent returned an error state. The revised prompt attempted graceful recovery: interpreting the most likely intended parameter and asking for confirmation before proceeding. This reduced OTA call failure rate from 4% to less than 1%.

What They'd Tell You

The director of revenue, at the six-month mark:

"The OTA engineers couldn't believe it worked over the phone. But it's just JSON over a voice channel. Once we showed them, they wanted to build the same thing for their other hotel partners. We had three of them ask us which platform we were using. The part that surprised me wasn't the technology — it was that removing one maintenance burden I'd been living with for two years meant I had actual time to think about revenue strategy instead of debugging API connections."

The front desk manager noted something the revenue director hadn't fully quantified: "We used to get bot calls during check-in rushes and have to put a guest on hold to handle the OTA query. That doesn't happen anymore. The bot calls never reach the desk."