Read the reviews of any large consumer app and you'll keep finding one complaint: "the bot didn't help." These companies have money and good engineers. Their bots still send you in circles and hide the way to a person.
We build support agents for hospitality. Zostel runs ours across the guest journey, from the first enquiry to the complaint after checkout. Our CTO, Aditya, went back through the build to see where the time went. Prompt writing took 5 to 10% of it. Integrations, testing and debugging took the rest.
If you're a founder deciding whether to build or buy your support bot, plan around that ratio.
The weekend version
Most teams start the same way. You point a frontier model at your help docs, write a system prompt and add a chat widget. It gets check-in time right, and the demo goes well.
Then a real guest writes in: "I booked the Manali one for the 14th. Can I add a night and switch to a private room?"
To answer her, the bot has to work out who she is and which Manali property she means. It needs her booking, live inventory, the new price and your change policy. Your help docs cover one of those four.
Document retrieval works on paragraphs. Your business runs on rows: bookings, rooms, prices. Aditya says RAG pipelines were never meant for structured data, and in production that mismatch became one of our biggest problems.
You also haven't told the weekend bot what to refuse. Developers found one US restaurant chain's support bot, wired it into their coding tools and used it as a free coding assistant.[1]
The other 90%
In hospitality, one sentence can mean three things depending on where the guest is. Before booking, "Can I change my dates?" is a search. After booking, it's a modification with a policy and a price difference attached. During the stay, it's an extension that depends on tonight's availability.
Before the agent answers anything, it should know who it's talking to. Pull as much context as you can before the first reply. Start with the guest's booking and their stage in the journey, then add what your team did for them last time. A guest who doesn't have to explain who they are gets to the problem in their first message.
Zostel's agent looks the guest up by phone number or booking ID and reads their stage from the booking state. Once it has that, "the Manali one" points to one booking. We hang each flow off that stage:
| Stage | What the guest asks | What the agent needs |
|---|---|---|
| Pre-booking | "Any private rooms next weekend?" | Inventory, pricing |
| Post-booking | "Can I move my dates?" | Booking, change policy, price difference |
| Pre-check-in | "Can I check in early?" | Booking, property operations |
| In-stay | "The hot water isn't working." | Property team, live escalation |
| Post-checkout | "I was charged twice." | Payments, CRM |
| After a 1-star rating | The agent calls to ask what went wrong | Review, stay history, CRM |
On a whiteboard, most of these rows look like edge cases. In production you'll see each of them daily, and most bots break on them.
Three more pieces sit under each stage:
- Handoff. In a Gartner survey, 64% of customers said they'd prefer companies didn't use AI for service.[2] Their top worry was that AI makes it harder to reach a person. Your handoff needs rules, context for the human and a plan for when nobody picks up.
- Memory. A returning guest expects the agent to know what your team already did for them, like last week's refund or date change.
- Evals and simulations. Any prompt or tool change can break a flow that worked yesterday. Evals replay saved conversations with a known right answer. Simulations go further, with a second model playing a guest who misspells names and changes plans midway. Run both on each change before a real guest sees it.
Tell the guest what happens next
Google's billing support chat opens with this:
"Explain your problem clearly in a few sentences, with as much detail as possible, and I'll try to help. If at any point I am not helpful and you'd like to chat with a human agent, let me know. I'll connect you to a human agent and share a copy of our conversation so they can better assist you."
Three sentences do three jobs:
- It commits to helping. The bot says it will try, and asks for the detail it needs.
- It keeps a human in reach. You can ask for a person at any point.
- It promises a clean handoff. The person gets the conversation, so you don't start over.
People on a support chat want their problem fixed. Most don't mind whether a bot or a person fixes it. What they need is to trust the support, and this message earns that trust before the bot has answered anything.
Zostel in production
Zostel's agents take inbound conversations and start outbound ones. Mid-conversation, they read from and write to the booking engine, room inventory, pricing, payments and the CRM, with 6 to 7 tool calls in an average conversation.
Booking was the hardest flow to build. An inbound guest can ask anything and branch anywhere. We needed enough fixed steps to land a correct booking, and enough slack for the guest to change their mind halfway through.
Property names are messy. Guests shorten them, misspell them or name the town, like "the Manali one." With better retrieval and newer models, the agent now picks the right property 96 to 97% of the time.
Pricing broke when guests did their own math. Availability has never been wrong, because the agent reads it from a read-only API. Pricing went wrong when a guest stepped in mid-conversation with their own numbers and the model let them override its calculation. If a number matters, compute it in code and have the model read it out.
Zostel decides what goes to a human. Today 14 to 17% of conversations reach a person: cancellations, date changes and live incidents at a property. The agent could handle cancellations, but Zostel keeps them with its team so staff hear why guests cancel. Your harness should make that a setting you can change.
The staff member who picks up sees a summary, the action needed and the reason for escalating, so the guest doesn't repeat themselves. The agent also records what staff resolved and starts the guest's next conversation from there. If nobody picks up within 15 to 20 minutes, the agent tells the guest it has escalated and alerts the property team. Zostel staffs support 24/7, so that rarely happens.
Group bookings run for days. Most bookings close in under 30 minutes. Group bookings take longer because one guest has to check dates with the rest. The agent remembers where the conversation stopped, follows up at the right time and nudges the group to finish. One group booking went back and forth daily for a week, and the agent kept track the whole way.
We don't ship a change until it passes over 250 tests. The suite covers misspellings, confused guests and simulated conversations, and it runs on each change to the agent. One failed scenario blocks the update.
The model still slips
With all of this in place, the model still makes mistakes. We see it take the wrong tool step, skip instructions, mismatch dates and switch languages mid-conversation.
Published benchmarks show the same thing. On Sierra's τ-bench in 2024, the best agent solved the same retail task eight times in a row only about 25% of the time.[3] In February 2026, a Princeton team tested 14 models released through late 2025, including GPT-5.2 and Claude Opus 4.5.[4] Accuracy rose with each release while reliability lagged. On the team's customer-service simulation, reliability improved at one-seventh the rate of accuracy,[5] and the most consistent model scored 73% on consistency.
Plan for the model to miss. Keep facts behind APIs and math in code, and keep the context tight so the model has less room to invent. We got Zostel's hallucination rate under 1% that way. Then test each change, and hand off whatever still slips through with the context a person needs.
Build or buy
If you're deciding, put these questions to your own team or to any vendor:
- Where does each answer come from: a document, an API or the model?
- What does the agent know about the customer before the first reply?
- Who does the math?
- What goes to a human, with what context, and what happens at 3 AM?
- Will the agent remember what your team told this customer last week?
- Does each change run against a test suite before it ships?
- How will you know when the agent gets something wrong?
You can write the prompt in an afternoon. Your customers will judge the bot on the other 90%.
If you'd rather start with that 90% built and see each conversation from day one, talk to us.
References
- Let's Data Science. A restaurant chain's support bot used as a free coding model (June 2026).
- Gartner. 64% of customers would prefer companies didn't use AI for customer service (July 2024).
- Sierra. τ-bench: benchmarking AI agents (2024).
- Rabanser, Kapoor, Narayanan et al. Towards a Science of AI Agent Reliability (February 2026).
- Fortune. AI agents are getting more capable, but reliability is lagging (March 2026).