Is it very expensive to build an AI bot that books or charges properly?

The expensive part isn't doing it right, it's doing it wrong: rework, botched charges, upset customers. Making these six decisions up front costs an afternoon of thinking, not extra coding.

Can I let the AI book appointments on its own, with no one reviewing?

For actions with consequences — booking, charging, cancelling — it's best that the AI can't assert anything it hasn't actually done, and that the delicate parts go through a single controlled path. The AI proposes and speeds things up; the irreversible part stays tied down.

I already have a bot that fails — where do I start?

By identifying which of the six decisions you're missing. It's almost always who's in charge or where the conversation state lives. A single failure that reappears after you patch it is usually duplicated logic: the same action written in several places.

AI bots that take actions: the 6 decisions before you build

Making an AI bot that talks is easy: in one afternoon you have a demo that answers beautifully. Making one that acts — one that books, charges, cancels or touches real data — is another thing entirely, because every error has consequences for a real person. The good news: these disasters almost never come from the AI itself, but from how you wire it to the rest. And they boil down to six decisions you can get right on day one.

Here are the six, with the right answer and what breaks if you skip it.

1. Decide who's in charge of the conversation

Your bot will almost certainly have two ways to run a conversation: a fixed flow (ask for the service, then the day, then confirm) and the AI interpreting whatever the person writes freely. The classic mistake is letting both be in charge of the same thing at once. It's a car with two drivers and one steering wheel: while they go the same way, fine; the moment they disagree, it swerves.

The right decision: a single boss. Either the AI is in charge and the fixed flow is a set of tools it uses, or the fixed flow is in charge and the AI only translates what the person wants. One of the two, never both over the same decision.

If you skip it: loops (the classic "reply YES or NO" on repeat), buttons that derail a half-finished booking, absurd replies when the two systems step on each other.

2. Have a single source of truth for the state

In every conversation there's one critical piece of data: where are we? Is the person choosing a day, waiting for confirmation, or already done? That data has to live in one single place that everyone reads and everyone updates.

The mistake is scattering it: a table over here, some "handled" flags over there, the AI's memory reading the history on its own. When those copies don't match, the bot acts on stale information. It's a front desk where five people look at five different diaries and none of them notices when another crosses something out.

The right decision: one single place that defines the state of each conversation. If you have to look in five places to know what's going on, sooner or later they'll contradict each other.

If you skip it: the bot replies to someone a human already handled, reopens closed conversations, or reacts to old messages as if they were new.

3. Route the important actions through a single path

Creating a booking, charging, cancelling: these are delicate operations. The mistake is writing them several times, repeated in different corners of the system. Because the day you find a bug in one and fix it, the twin copies stay broken. You seal the crack in one pipe without seeing that the same pipe, with the same crack, also runs through the next room.

The right decision: every critical action goes through a single function, one mandatory path. That way, when you fix or improve it, you do it once and it holds for every case.

If you skip it: you fix a bug and the same one reappears elsewhere a week later. Payments left stuck to bookings that no longer exist.

4. The AI can't assert what it hasn't verified

This is the most dangerous one, because it's specific to AI. Models are built to sound confident and to please. And sometimes, to look good, they make things up with total poise: "your appointment is confirmed for Tuesday at a quarter past two," when they've booked nothing at all. It sounded good, so they said it.

The instinctive reaction is to add filters that check what it says and block the lies. It helps, but it's like hiring someone who lies and putting three people on to review everything they say. The underlying problem is still there.

The right decision: make lying impossible, not just hard. The rule: the bot can only say "your appointment is confirmed" if it just created it and holds the booking number in hand. If it doesn't have it, it can't assert it. You don't filter it afterwards: you prevent it beforehand.

If you skip it: phantom confirmations, invented data, customers who show up for an appointment that never existed.

5. Write down your business rules first, not with customers watching

The mistake is releasing the bot without having written your own rules first: which word maps to which service, which add-on is only offered if asked for, which requests must always go to a person. If you don't write them down, you discover them the hard way: one blown-up conversation after another. It's opening a shop with no price list and making them up as each customer asks.

The right decision: sit down first and write, in one single document, your business's rules and correct answers. The bot reads from there. It's not glamorous, but every rule you write beforehand is a customer who doesn't get a nasty surprise later.

If you skip it: the bot offers what it shouldn't, confuses services, and you end up learning your own policies from the mistakes it makes.

6. Have a safety net before publishing each change

This is the one that holds up the other five. The mistake is touching the live system directly, with no separate place to test and no check that warns you if fixing one thing broke another. Then every improvement is also a possible new breakdown, and the one who finds it is a customer.

The right decision: even something minimal — have a handful of example conversations you can "run" through the bot before publishing each change, and check they still come out right. You don't need anything sophisticated. Rehearsing before opening night saves you most of the scares.

If you skip it: the failures come out single file, not because there are many, but because nothing catches the error before it reaches the street. Your test bench ends up being your customers.

The day-zero checklist

Before you write a single line, answer these six questions:

Who's in charge of the conversation: the AI or the fixed flow? (pick one)
Where, in a single place, does the state of each conversation live?
Which single path do create, charge and cancel go through?
How do I guarantee the bot can't assert something it hasn't verified?
Where are my business rules that the bot must follow written down?
How do I test a change before a customer sees it?

If you have a clear answer to all six, you're ahead. If any is "I'll figure it out as I go," that's exactly where it'll fail you.

Our stance

Almost all of these errors don't come from the AI itself, but from how you plug it into the rest: who's in charge, where the truth lives, whether the logic sits in one place or ten, whether it can assert without checking, and whether you have written rules and a net underneath. That's why, when we build AI automations, the irreversible part is always tied down and a person can review it: the AI speeds things up, it doesn't decide alone and blind. A bot that only talks is easy; one that acts has to be built with care.

AI bots that take actions: the 6 decisions that prevent disaster