A confident reply doesn't mean the booking happened
A bot can say "you're booked, see you Thursday at 3pm" with total confidence while the appointment goes nowhere: the stylist never got a notification, the slot never blocked on the calendar, or the message landed in a test chat instead of the real one. The reply text only proves the bot can string words together, not that anything actually happened on the other end. What needs checking is the outcome, not the conversation: did a booking show up where the stylist is actually going to see it.
Five scenarios worth walking through yourself
Running the one perfect path, pick a time, confirm, get a reply, isn't enough. At minimum, walk through five scenarios the way different real clients actually would:
- Happy path: a slot is free, the client picks it and confirms.
- Taken slot: the client tries to pick a time that's already booked, the bot should offer an alternative, not stall.
- Cancel and reschedule: the client cancels or moves an existing booking, the slot should free up or move on the calendar, not end up duplicated.
- Incomplete input: the client enters a name with no phone number or drops the conversation halfway, the bot shouldn't create a booking with a gap in it.
- Mobile screen: the same conversation on a small screen, buttons and text shouldn't get cut off or overlap.
Check the destination, not the conversation
After each test, look at where the booking was actually supposed to land: the stylist's calendar, a spreadsheet, or the chat where staff get notified. Does the time, name and phone number in that record match what the test client actually entered. If the bot notifies the stylist, confirm the notification actually arrived, not just that the flow was supposed to send it.
Keep a list of mismatches instead of patching on the fly
Every mismatch found is worth logging: what was expected, what actually happened, and after fixing it, that exact scenario gets retested. Fixing things ad hoc without a list almost always means the same bug resurfaces a month later, because something got fixed correctly, just not for the case that was actually broken.
Test where the client will actually be, not only in the dev panel
A conversation that looks right in the bot's testing panel can behave differently on the real channel, Telegram, WhatsApp, or a website widget the bot is embedded in. The final check should happen on the actual channel and device a real client would use, not only in a development environment.
Common mistakes, in short
- Only the perfect path gets tested, no taken slot, no cancellation.
- The stylist notification is checked against the flow's logic, not actual delivery.
- Testing happens in the dev panel instead of a real chat on a phone.
- A bug gets fixed but the same scenario never gets retested to confirm it.
Pre-launch checklist
- [ ] Happy path, taken slot, cancel/reschedule, incomplete input and mobile screen all tested
- [ ] Every test booking found in the real calendar or staff spreadsheet
- [ ] Stylist notifications confirmed by actual delivery, not just flow logic
- [ ] A mismatch list was kept and closed out with a retest, not just a fix
- [ ] The final test ran on the client's real channel and device
What you can hand off to us
Checking and fixing the bot is part of the studio's support plan, from $150 a month. You can also discuss testing your own booking bot.