Changing what your AI knows, without breaking what it already gets right

A hotel AI is not set up once. It is taught, like a new employee who never leaves, and most of that teaching happens after launch, while the assistant is talking to guests.

That is the part nobody plans for. Editing a knowledge base is not like updating a web page. It is editing a system that is in a conversation right now, and a change made to fix one answer can quietly change twenty others. What follows is how to keep it accurate without breaking what already works.

Separate facts, rules and tone

Most knowledge bases start as one long document and become unmaintainable within a few months. The fix is structural, and it costs nothing to do on day one.

"Breakfast runs 07:00 to 10:30, 07:00 to 11:00 at weekends" is a fact. "Always mention that children under six eat free" is a rule. "Warm, short, never more than three sentences" is tone. Keep the three in separate places.

Mixed together, you cannot change a breakfast time without rereading a page of personality, and eventually you stop trying. Separated, a duty manager can correct a fact in thirty seconds without any risk of changing how the assistant speaks. (Brief your AI assistant in plain language covers how to write the rules and tone in the first place, and tone of voice and house rules covers the tone layer in detail.)

Write each fact once

A fact written in two places drifts. Breakfast is 07:00 to 10:30 in the knowledge base and 07:00 to 10:00 in an arrival template, and one day somebody updates one of them. The assistant then quotes the old version, confidently, for months, and the only person who notices is a guest who turns up at 10:15.

One fact, one home. Everything else points at it. If your confirmation template and your assistant both need the breakfast time, they should both be reading the same line, not each carrying their own copy.

This is the single highest-return habit in the whole exercise, and it is almost always skipped because at the start duplication costs nothing.

Keep rules short and general

The temptation after a bad answer is to write a rule about that exact answer. Do it twenty times and your knowledge base becomes a list of exceptions that contradict each other, and the assistant chooses between them in ways nobody intended.

Ask a different question: why was the answer wrong? Usually the root fact was missing, ambiguous or stale. A guest asked about parking a van and got the car park height. The fix is not a rule about vans. It is the fact that your car park has a 2.1 metre barrier and oversized vehicles park on the street behind the property.

Fix the root fact. Keep the rule count low enough that you could read the whole set out loud in ten minutes.

Give temporary things an expiry date

Seasonal prices, holidays, campaigns, construction next door, a restaurant closed for a fortnight. Most of what a guest asks in any given week is about the current state of your property, not its permanent state.

Keep a separate place for temporary updates that override the main knowledge, with a start and end date on each item. "The main pool is closed for maintenance 12 to 19 November, the indoor pool is open and heated" is an override, not a fact, and it should disappear by itself on the 20th. An operator with two sites will run several at once, and each site needs its own.

Dates are what make this safe. An override without an expiry is just a fact that somebody has to remember to delete, and that is precisely the thing nobody remembers. Where that memory fails more generally, and who should own it, is the subject of who owns the knowledge base when it goes stale.

Let your web pages refresh the knowledge automatically where you can. Anything that updates itself is one less thing that goes stale while you are busy.

Make correcting it cheaper than apologising

The people who spot a weak answer first are the ones reading conversations all day. Make it cost them nothing to say so.

A thumbs down on a bad answer, a one-line correction, and the fix goes live. Not a ticket to a vendor. Not a meeting. If correcting the assistant takes more effort than apologising to the guest, your team will apologise, and the assistant will stay wrong for as long as it takes someone senior to notice.

Then add one habit: a weekly look at the questions the assistant could not answer. Fifteen minutes, one person, a short list. It is the most honest document about your property you will read all week, because guests wrote all of it. A boutique group of four hotels in one city found most of its gaps this way rather than from complaints, because guests who do not get an answer usually go quiet rather than object.

Test before you trust

This is the step that separates a knowledge base you can change confidently from one nobody dares touch.

Before you publish a change, replay real conversations from recent weeks against the new knowledge and read what comes out. You are not checking that your change worked. You are checking what else moved: a new rule about group enquiries that quietly alters how the assistant answers a couple asking about two rooms, or a reworded cancellation fact that now reads as a refusal.

A demo question proves nothing. You already know the answer to the demo question, which is why you chose it.

Takeaway

Budget time for teaching the assistant the way you budget for training staff, and give the knowledge a structure that survives being edited in a hurry: facts in one place with no duplicates, a short general rule set, temporary items with expiry dates, a correction loop that costs a staff member ten seconds, and a replay against real conversations before anything goes live.

The properties that do this weekly get the best results. It is also the reason a general-purpose assistant cannot simply answer your booking questions: the value sits in knowledge nobody has written down yet, and most of it only appears after launch. What to collect before you start is covered in your operations are the AI's real training data.