What stops the AI promising something you can't deliver?

Almost everyone we speak to ends up asking the same question, and it's rarely the one we prepared for. It isn't whether the AI understands what the customer means. It's what it says when nobody is sitting next to it, watching.

That's a fair worry. An employee who isn't sure asks a colleague. A language model that isn't sure writes a sentence anyway, and it sounds exactly as confident as every other sentence it writes. So the whole design rests on one starting point: we don't trust the model to choose correctly. We build so the wrong answer isn't available to give.

Here are the guardrails that matter, without the jargon.

A booking is either real or it isn't a booking

Kim never invents an available time. When somebody asks about a time, the question goes to your booking system, and Kim may only offer the times that came back from it. There's no way around that: a time your system hasn't approved cannot end up in a sentence.

If the customer says yes, the booking is written for real, straight into the system you already work in. Staff see it where they always look. There's no separate list at our end that somebody has to remember to reconcile.

And if your booking system doesn't answer? Then Kim says a colleague needs to take over, and a human does. Kim never says "sorry, we're fully booked" in that situation. That one is worth pausing on, because it's a guardrail that costs us something: it would be more convenient to let the AI guess. But a system that's merely unreachable for a while looks identical to a fully booked one, and the difference is that the first would have Kim turning away every single customer for days while everything looked calm and green. A silent failure always costs more than a visible one.

Two guests cannot get the same slot

Two people can get in touch in the same second. One calls, one types in the chat, both ask about Thursday at seven.

So bookings are handled one at a time per venue. Capacity is recounted at the moment the booking is written, not a few seconds earlier, so there's no gap for the second conversation to slip into. If the network stutters and the same booking is sent twice, you still get one booking, not two.

None of that has anything to do with AI. It's craft, and it's the difference between something that talks about bookings and something that makes them.

Your rules are rules, not suggestions

Closed dates, how little notice you accept, minimum party size, how large a party should be handled by a person instead: you set all of that yourself in the portal.

What matters is where those rules live. They live outside the AI. They aren't an instruction Kim is asked to follow, they're a condition tested before a booking can happen at all. No customer can talk their way past them, however politely or persistently they ask, and they apply identically on phone, chat, SMS and email. That's also why you only have to set them once.

We check afterwards that Kim did what Kim said

This is the guardrail we're happiest with, and it rests on an uncomfortable insight: sooner or later a language model will say "I'll put that in for you" without a booking having been made. Every model does it sometimes. It isn't something you prompt your way out of.

So we assume it will happen. After every call, what Kim actually said is compared against what exists in the system. If it sounds like a booking was made and there is no booking, that raises an alert and a human at your end is told straight away.

The customer hung up happy. You still find out the same day, rather than when somebody turns up for a table that doesn't exist. The check is deliberately independent of which AI model is in use, so it keeps working the day we switch models.

And if you type something wrong yourselves?

Almost everything Kim can say comes from you: your opening hours, your menu, your prices, your FAQ. That's the strength, and it's obviously also the risk.

Four things apply there.

Kim quotes you, Kim doesn't remember. A price, a time or a rule has to come from your information in the moment. Kim may not state a figure that wasn't fetched, however plausible it sounds or however confidently the model "believes" it knows.

When the answer is missing, the gap doesn't get filled. If nothing covers it, Kim hands over to a human, and the question lands in a list in the portal so you can see what customers are actually asking that you have no answer for. That list is usually the most useful thing you get out of the first month.

Your own instructions sit underneath the safety rules, never above them. You can ask Kim to be more sales-minded, to greet people a certain way, or to always mention the weekend offer. You cannot, even by accident, write an instruction that makes Kim book without checking, or guess instead of handing over. That order can't be reversed from the portal.

Kim doesn't take orders from whoever is typing, either. A message trying to get Kim to change its behaviour or reveal its instructions is not followed. And Kim never asks for national ID numbers, passwords, bank authentication codes or card numbers, no matter who requests them.

What we don't promise

This should be said plainly, because vendors tend to skip it.

The guardrails govern what Kim may do, not what Kim knows. If the wrong opening hours are in the portal, Kim will give the wrong opening hours, as politely and as confidently as everything else. No technology on earth reads your business better than you do.

What we stand behind is narrower, and it's the part you can actually rely on: Kim invents nothing beyond what you've provided, and never claims something was done that wasn't. Errors in your information become wrong answers. Errors in our technology must not become a booking that doesn't exist.

That distinction is what the whole thing rests on, and it's the one we'd rather be judged on.

If you want to hear what it sounds like in practice, book a demo and we'll set Kim up on your own information.