Make worker selection in the AI booking flow accurate, contextual, and aware of real business constraints like availability, service matching, and party size.
The bot sometimes showed workers before it knew the date, listed workers who were unavailable, and had no path for "anyone is fine" or unavailable worker requests.
A simple question like "which worker do you want?" hides real business constraints. The product has to enforce when the question gets asked, not just what the question is.
The Build
The booking flow had a step where the customer picks a worker for their appointment. On the surface it seemed like the simplest part of the flow. The customer picks a service, picks a date and time, then picks who they want. One question, one answer, move on.
I already had some filtering in place from early on. Each worker has a list of services they can perform, stored in the database. A tool queried worker availability and cross-referenced booked appointments to remove times that were already taken. The data model was not the problem. The flow was.
The Problem
The bot sometimes showed workers too early. A customer would select a service and the bot would immediately list every worker, before it even knew what date or time the customer wanted. There was no way to know who was actually available without the date. The customer would pick a worker, then find out that worker was not free at their preferred time. That creates a back-and-forth that a booking form would never have.
Then the edge cases started showing up. What if the customer says "anyone is fine"? What if they ask for a specific worker who is not available at their chosen time? What if the business is a solo operation with only one worker? What happens when you add multi-customer parties to the flow, where multiple people are booking at once and the worker needs to be available for all of them?
Each of these sounds like a small detail. Together they turned worker selection from one question into a product design problem.
Assumption vs Reality
I thought worker selection was a lookup problem. Get the date, query who is free, show the list. The data model already had service lists per worker, so invalid matches were blocked. It felt like the hard work was already done.
The data model was solid, but the flow did not enforce when the question got asked. The bot had access to worker tools at every stage of the conversation, so it could show workers before it had enough information to filter them correctly. The problem was not missing data. It was that the AI was asking the right question at the wrong time.
The Fix
The biggest change was restructuring the state management. I built a phase-based system where the booking flow knows exactly what stage it is in. Each phase has its own set of tools and its own prompt. The worker selection tools are not available until the service, date, and time are confirmed.
This means the bot cannot show workers too early because it does not have the tools to query them yet. When the booking reaches the worker phase, it queries all workers for the selected date, filters out anyone who is unavailable, and only shows workers who can perform the selected service. The customer only sees valid options.
The product started as a solo-operator setup where there was only one worker. The bot knew exactly who to book with and skipped the question entirely. When I added support for multiple workers, the selection step became necessary. And when I added multi-customer parties, the filtering got more complex because the worker needs to be available for the full party, not just one person.
For "anyone is fine," the appointment is kept unassigned and the business can assign a worker later. In the future, I want to add an auto-assignment option where the business can configure how unassigned bookings get handled. Different businesses will want different behavior, some want customers to choose, some want the system to assign based on availability, and that should be a business-level setting.
When a customer asks for a specific worker who is not available, the bot handles it both ways depending on the situation. Sometimes it offers a different day with that worker, sometimes it suggests a different worker who is available. Both are valid paths depending on whether the customer cares more about the worker or the date.
A "simple" product question can hide real business constraints. Worker selection depends on the service, the date, the time, the worker's schedule, the worker's service list, the party size, and the customer's preference. You cannot ask it as a standalone question. It has to come at the right point in the flow with the right data already confirmed. Different business types need different flows, not just different data. A solo-operator salon should skip the question. A multi-worker salon should ask it. A business that prefers auto-assignment should handle it in the background. The product needs to be aware of these differences at the flow level, not just the data level.
For a salon owner, worker selection matters because customers have preferences. Some want their regular nail tech. Some just want the next available person. The booking system needs to handle both without making the customer jump through hoops. If the bot shows workers before it knows the date, the customer picks someone who turns out to be unavailable. Now they are frustrated and starting over. If the bot does not offer an "anyone is fine" option, customers who do not have a preference get stuck choosing someone they do not know. Both of these lose bookings. The goal is simple: ask the right question at the right time with only the options that actually work.
Builder Notes
The phase-based state management system was the key architectural change. Instead of giving the AI all tools at all times, each booking phase has its own tools and prompt. This prevents the AI from jumping ahead or using data it does not have yet.
Technical Note 1
Worker objects in the database include a services array. Invalid service-worker matches are blocked at the data level, not just by the prompt.
Technical Note 2
Worker selection tools are only available after service, date, and time are confirmed. The AI cannot query workers before that phase.
Technical Note 3
Each booking phase has a specialized prompt that keeps the AI focused on one job instead of carrying the full booking logic.
Technical Note 4
The product started as a solo-operator flow and added multi-worker support later. Solo businesses skip the worker question entirely.
Technical Note 5
Multi-customer parties add complexity because the worker needs availability for the full party duration, not just one slot.
Technical Note 6
"Anyone is fine" currently results in an unassigned appointment. Auto-assignment logic is a future feature that should be configurable per business.
Before / After
- Worker tools available at every stage of the conversation
- Bot sometimes showed workers immediately after service selection
- No handling for "anyone is fine"
- No fallback when a requested worker was unavailable
- Single flow for all business types
- Worker tools only available in the worker selection phase
- Workers shown only after service, date, and time are confirmed
- "Anyone" keeps the appointment unassigned for the business to assign
- Bot offers alternative days or workers when a request cannot be filled
- Solo-operator businesses skip the worker step automatically
What I'd Do Differently
I would design the phase-based system before building any of the individual steps. Knowing that each phase needs its own tools and prompt would have saved me from debugging why the bot was showing workers too early. I would also plan for "anyone is fine" and unavailable-worker fallbacks from the start instead of treating them as edge cases later.