While testing our AI receptionist, we had a conversation that went like this:
Customer: Friday at 1 works. Assistant: You’re booked for Friday at 1 pm. We’ll text a reminder the day before. Customer: Great, will they call before they come? Assistant: Actually, Friday at 1 pm isn’t available. Would Thursday at 8 am work instead?
The booking was real. It was in the calendar. But on the next message the assistant looked at the list of open times, didn’t see Friday at 1 there (it was taken, by this same customer), and decided it had made a mistake.
Nothing about this is exotic. It’s exactly the kind of thing that turns a customer off for good, and it’s the kind of thing a demo never shows you, because demos are one happy path.
What actually happened
Each time a customer sends a message, our system gives the AI three things: the business’s approved facts, the open calendar slots, and the conversation so far. The AI sends back a decision: what to say, and whether to book, hand off to a person, or keep talking.
The AI doesn’t touch the calendar. The code does. When the AI says “book slot 20261023-1300”, the code checks that the slot is open and writes it down. If two customers pick the same time at once, one of them gets “sorry, that time was just taken”, never a double booking.
That part worked. The gap was in what we told the AI on the next turn. We showed it the open slots, and the customer’s own booking was, correctly, no longer open. We never said “this person already has Friday at 1.” So the AI did what a careful person with that information would do. It saw a time it had promised that was no longer on the list, and it corrected itself.
The fix
Two changes, both small:
- Tell the AI what’s already true. If this conversation already has a booking, the instructions now say so: this customer is already booked for Friday at 1 pm, confirmed in the calendar. Don’t offer times again unless they ask to reschedule.
- Make rescheduling explicit. If the customer does ask to move it, the code releases the old slot before booking the new one. One customer, one booking.
Then we wrote tests for both, so the bug can’t quietly come back the next time someone edits the instructions.
The rule underneath it
The lesson isn’t “AI is unreliable.” The AI behaved sensibly given what it knew. The lesson is about who owns what:
- The AI owns language. Understanding what the customer means, answering from approved facts, asking the next useful question.
- The code owns facts and commitments. What’s booked, what’s open, what anything costs, whether a text is allowed to go out.
- The code tells the AI the facts every single turn. It never assumes the AI remembers.
Every system we build follows that split. It’s why our quote engine has the AI read the job notes but plain code do the pricing, and why a receptionist can’t invent an appointment time that isn’t on the calendar.
What to ask anyone selling you one of these
If you’re evaluating an AI receptionist or chat assistant, from us or anyone else, ask:
- Who writes the booking into the calendar, the AI or the code?
- What happens if two people pick the same time?
- What does it do on the third message, after it has already booked someone?
- Can I see a transcript of it handling a reschedule?
If the answer to the first one is “the AI does it”, be careful.