From Guest Message to Ticket: Routing the Requests Your Bot Cannot Answer

Every deployment reaches the same question at roughly the same point in onboarding. The knowledge base is populated, the tone is right, the common questions are answered. Then the operator asks:

How do I open a ticket automatically? Can it go to WhatsApp, or to email?

This is the question that separates a chatbot from an operational system, and it deserves more attention than it usually gets.

The escalation path is the product

It is tempting to judge an assistant by what it can answer. Operators who have run one for a while judge it by what it does when it cannot.

An assistant that answers eighty percent of questions well and improvises on the rest is worse than one that answers seventy percent and escalates the remainder cleanly. The improvised answer is the one that produces the complaint, the wrong expectation at the front desk, the review that mentions being told something untrue.

So the design goal is not to minimise escalations. It is to make escalations fast, contextual and owned.

What an escalation should carry

When the assistant hands a conversation to a person, that person needs to not start from zero. A useful escalation includes:

• What the guest asked, in their words.
• The conversation so far, so nobody makes the guest repeat themselves.
• Who the guest is and, where relevant, which reservation this concerns.
• Why it escalated - outside the knowledge base, explicitly requested a person, or detected frustration.

That last field is more useful than it sounds. Escalations triggered by frustration need a different response than escalations triggered by an unusual question, and staff can prioritise correctly if they can see which is which.

Send it where people actually look

Here is the part that decides whether any of this works: notify people on the channel they are already using.

For most hotel and attraction teams, that is WhatsApp. Not email, which gets read at the start and end of a shift. Not a dashboard, which requires someone to be at a screen. The floor staff, the duty manager, the person who can actually resolve the request are moving around, and the device in their pocket is where they will see it.

A ticket that exists only in a system nobody opens during a shift is functionally identical to no ticket. It is worse, in fact, because it creates the appearance of a process while the guest waits.

So the arrangement most operations end up with: the assistant opens a ticket for the record, and the ticket fires a notification into a WhatsApp group or to a specific person on shift. The system holds the history; the phone carries the urgency.

Sometimes the right answer is a phone number

Not everything should become a ticket.

Consider lost property. A guest messages about a jacket left behind. That request has a specific owner, often a specific desk, and sometimes a third party entirely - a venue operator, a transport company, a contracted service. Routing it into your ticket queue adds a hop and a delay before it reaches someone who can actually go and look on a shelf.

For those cases it is better to have the assistant hand over the direct route: lost property is handled by the front desk on this number, they hold items for thirty days.

The rule of thumb: escalate what you own, redirect what you do not. A ticket in a queue with no real owner is where guest requests go to be forgotten.

Writing rules that survive a real rota

Escalation rules fail in predictable ways, and almost all of them come from vagueness.

Complex questions go to the manager fails twice over. Nothing defines complex, so the boundary drifts. And the manager is not on shift at 11pm on a Saturday, which is exactly when the difficult messages arrive.

Rules that survive contact with reality name four things:

1. The topic. Billing disputes. Accessibility requests. Group bookings over twenty. Lost property. 2. The owner. A role, not a person, so it survives holidays and turnover. 3. The channel that owner watches, during the hours they watch it. 4. What happens if nobody picks it up. A fallback destination and a time limit. This is the rule most operations skip, and the one that prevents a request sitting unanswered overnight.

Test the unhappy path

Before go-live, deliberately send the assistant things it cannot answer. Send it a frustrated message. Send it something outside its scope. Send it a request at 2am.

Then watch what happens - not what the assistant says, but where the notification lands, who sees it, and how long until a human responds. That end-to-end path is the actual product. Conversation quality is what guests notice first; the escalation path is what they remember.

The honest framing

Automation in guest communication is not really about the questions the machine answers. Those were always answerable - they were just answered slowly, by a person who had answered them forty times that day.

The value is in what the machine does with the questions it cannot handle: recognising them fast, packaging them with context, and putting them in front of the right person while the guest is still paying attention. Get that path right and the rest of the deployment tends to work. Get it wrong and no amount of conversational quality will save it.