What You Actually Need Before an AI Assistant Goes Live

The question most operators ask early in an implementation is some version of what do you need from us? It is a good question, and the honest answer surprises people: very little of it is technical.

The engineering side of connecting an AI assistant to a property is largely solved. What determines whether a launch happens on time is a short list of decisions and preparations that only the property can make, and they are usually the thing everybody underestimates.

1. Accounts that outlive individuals

Almost every integration needs an account it can be granted access to. A calendar, a mailbox, a PMS user, a messaging number.

The temptation is to use somebody's existing account because it is quicker. Do not. Use accounts created for the purpose.

The reason is mundane and inevitable: people leave, change roles, go on holiday, and reset their passwords. An integration wired to a personal account is an outage waiting for a resignation. It is a five-minute decision at setup and a bad afternoon at some unpredictable point later.

A related question that comes up constantly with multi-area venues: one account for everything, or one per area? There is no universal answer, and it is worth thinking about rather than defaulting. One shared account with everything on it is simpler to administer. Separate accounts per area give cleaner, more precise answers when the areas have independent capacity. Choose based on how you actually take bookings, and choose before anyone connects anything, because restructuring later is more disruptive than deciding now.

2. Structural decisions nobody else can make

These are the questions that hold up more launches than any integration:

• Do these two activities share capacity, or are they independent?
• Is a request over a certain group size handled differently?
• Which questions should never be answered automatically, regardless of confidence?
• What happens outside opening hours?

None of these are technology questions. They are questions about how your operation works, and the answers have to come from someone who runs it. A vendor can tell you what is possible; only you can say what is correct for your property.

The efficient way to handle this is to write it out in plain language, as a description of what should happen. Something like: a guest asks about a Saturday party, the assistant checks that calendar, if the day is full it says so and offers the two nearest free dates, and above twenty people it stops quoting availability and takes their details instead.

That paragraph is worth more than an hour of settings discussion, because it contains the branches. And more often than not a good part of it is already configured - availability and escalation logic tends to be built generically and pointed at specific cases - so writing it down reveals both what already works and what genuinely needs building.

3. Your words, not the template's

Every deployment starts from draft answer text, and every deployment needs the property to edit it.

This is the step operators most often defer, and it is the one that determines whether guests feel like they are talking to your property or to a generic system. The draft will be accurate. It will not sound like you. It will not know that you always mention the shuttle, or that you have stopped offering the thing the website still lists, or that a particular question has a sensitive answer at your property for local reasons.

Budget real time for this and give it to someone who talks to guests. An hour from a front-desk supervisor improves the output more than a day of configuration.

4. A named owner for escalations

The assistant will hand conversations to people. That path needs an owner before launch, not after the first missed request.

Name three things:

• Who receives escalations, as a role rather than a person.
• On which channel, and during which hours. For most hotel and attraction teams this is WhatsApp, because staff are on the floor rather than at a desk. A notification into a system nobody opens mid-shift is the same as no notification.
• What happens if nobody picks it up - a fallback and a time limit.

That third item is the one almost everyone skips, and it is the one that prevents a guest request sitting unanswered overnight.

5. A simulation round, then a call to close the ends

Do not treat go-live as a switch. Treat it as a rehearsal followed by a short review.

Run simulations against the real connected systems with real data - the actual calendar, the actual PMS, real dates including a fully booked day and a closed day. Then deliberately test the unhappy paths: an out-of-scope question, a frustrated message, something at 2am.

What you are inspecting is not whether the assistant works. It is what it says and does at the edges, because those are the responses guests remember and the ones nobody thought to specify.

Then hold a short call to close the open ends before launch. There will be open ends. There always are, and they are cheap to fix the week before and expensive to discover the week after.

The realistic sequence

A launch that goes smoothly usually looks like this:

1. Accounts created and access granted. 2. Structural decisions made and written down in plain language. 3. Draft answers edited by someone who talks to guests. 4. Escalation owner, channel and fallback named. 5. Simulations run against real systems, including the awkward cases. 6. A short review call to close the remaining ends. 7. Go live.

Steps one to four are the property's work and are where the timeline actually lives. Nothing on that list requires technical skill. All of it requires somebody to decide, which is why the single most useful thing an operator can do at kickoff is name who that somebody is.