Stop the AI booking assistant from asking dumb follow-up questions, skipping steps, and making up customer information.
The bot re-asked questions, ignored user input, skipped booking steps, and filled in contact details with random IDs from the context.
Dumb follow-up questions are not an AI problem. They are a product problem. The prompt, state tracking, and tool design all have to work together.
The Build
The booking flow had structure now. The bot was supposed to collect service, date, time, worker, name, phone, and email in order, confirm each field one at a time, then show a summary for the customer to review before confirming.
The alternative for the customer is a quick book form. Click a service, pick a date, pick a time, done. If the chat experience is worse than that, there is no reason to use it. The bar was not "works sometimes." The bar was "smoother than a form."
The Problem
The bot kept doing things that made it feel broken.
The worst behavior was when it skipped steps it should not skip, jumped to the end of the booking flow, and made up the customer's email and phone number. It was not generating fake numbers from nothing. It was grabbing IDs from the context, like a service ID or a database record ID, and using those as the phone number. I did not have a way to gate what counted as a valid phone number, so the bot treated any number-like string as close enough.
Here is a real example of another problem. The bot showed available times as ranges:
Bot: "Here are the available times for Monday: - 10:00 AM to 12:00 PM - 2:00 PM to 5:00 PM"
Customer: "3 PM"
Bot: "I did not find that exact time. Here are the available times for Monday: - 10:00 AM to 12:00 PM - 2:00 PM to 5:00 PM"
Customer: "3"
Bot: "Could you please select one of the available time ranges?"
The customer picked a valid time inside the range. The bot kept re-asking because the input did not match the exact range format. The tool was not built to check if a specific time fell within an available window. It was only matching exact strings.
The bot also forgot its own suggestions. It would say "How about next Monday?" and when the customer replied "that date works," the bot would ask which date they meant. It suggested the date and then lost it.
Assumption vs Reality
I thought the problem was bad instructions. If I made the prompt clearer and more detailed, the bot would stop asking dumb questions. I spent a lot of time rewriting prompt instructions thinking that was the fix.
It took time to step back and see the full picture. The problem was not just the prompt. It was a combination of everything. The prompt instructions were part of it, but the state tracking was not recording what the bot had collected. The tools were not filtering results by what the user had already said. And there was no gate on what counted as valid contact information versus a random number from the context. Fixing the prompt alone did not solve it because the other pieces were still broken.
The Fix
The fix was not one change. It was getting the prompt, state, and tools to work together.
The tools now filter by what the user already said. If the customer mentions 3 PM, the availability query checks if 3 PM is open instead of returning all available ranges and expecting an exact match. After making this change, the bot skipped the full time list and went straight to picking a worker that fit the customer's time and date.
The state object tracks every collected field. If the bot suggested a date and the customer accepted it, that date is recorded. The bot does not need to re-derive it from the conversation. It reads the state and knows what is confirmed.
The booking flow now enforces the field order. Service, date, time, worker, name, phone, email, summary, confirmation. The bot cannot skip steps or jump to the end. If the phone number is missing, it asks for it instead of pulling a random ID from the context.
The behavior is working right now in testing, but I am still watching it. AI products have a way of surfacing new edge cases when you think you are done.
Dumb follow-up questions are not an AI problem. They are a product problem. The AI can understand natural language just fine. It can extract dates, times, and service names from messy input. The issue is what happens after extraction. If the product does not track what was collected, the AI re-asks. If the tools do not filter by what the user said, the AI shows irrelevant options. If there is no validation on what counts as a phone number versus a database ID, the AI grabs whatever looks close enough. The prompt, the state tracking, and the tool design all have to work together. Fixing one without the others does not solve the problem. It just moves it.
Think of it this way. The bot had a goldfish brain. A customer would tell it their preferred time and two messages later it would ask again. It would collect booking details and then forget to write them down. Sometimes it would grab a random number from its own notes and use it as the customer's phone number. For a real customer trying to book an appointment, that is not just annoying. It is a reason to leave and call the salon instead, or not book at all. The fix was not making the AI smarter. It was building a better system around it so the information actually gets recorded and the bot knows what to ask next.
Builder Notes
This was a multi-layered debugging problem. The prompt, state, and tools were all contributing to the same visible symptom: dumb follow-up questions.
Technical Note 1
The phone number problem happened because the bot had no validation for what counts as a phone number. Any numeric string in the context was fair game, including service IDs and database record IDs.
Technical Note 2
The time range mismatch happened because the tool returned ranges like "2:00 PM to 5:00 PM" but only matched exact strings. It was not checking if a specific time like 3 PM fell within a range.
Technical Note 3
The forgotten suggestion problem happened because the bot suggested a date in its own message but did not write it to the state object. When the user accepted, the state still showed the date as missing.
Technical Note 4
The fix was not a single change. It was getting three systems to agree: the prompt tells the bot what to do, the state tells the bot what it knows, and the tools give the bot filtered, relevant data.
Technical Note 5
After the tool filtering fix, the improvement was immediate. The bot stopped listing all times and went straight to worker selection when the customer had already given a time.
Before / After
- Bot skipped steps and jumped to confirmation with made-up contact info
- Bot grabbed IDs from context and used them as phone numbers
- Available times returned as ranges with exact string matching only
- Bot forgot dates it had just suggested
- Prompt rewrites were the only fix attempted
- Booking flow enforces field order, no skipping
- Contact fields require explicit user input, no context scraping
- Tool queries filter by the time and date the user already provided
- State object records bot suggestions and user confirmations
- Prompt, state, and tools work together as a system
What I'd Do Differently
I would add input validation for every field from the start. Phone numbers should only come from user input, not from anything else in the context. I would also build the tools to accept specific values from the user and check them against availability, instead of returning full lists and expecting the user to match the exact format.