Work out how Everwood should get customers to the right service when they describe the result they want instead of naming something on the menu.
I framed it as rules versus AI. We already ship AI matching, and its design settled that argument. The gap is that the facts which make a booking wrong are not in the menu at all.
A matcher can only choose between the facts it is given. Wrong-service bookings are a missing-information problem before they are a mechanism problem, and neither a rule nor a model can route on something the business never wrote down.
The Build
Nothing shipped from this research. Guided service matching is an idea on the roadmap, and it is still an idea.
The problem it names did not need selling to me. A customer wants to go from dark brown to blonde. The menu has five things with the word colour in them. They pick the one that sounds closest, or the cheapest, and the stylist finds out at the chair that the booking holds an hour less than the job needs.
The research framed the product decision as a fork. Either the business writes short questions and fixed rules that route a customer to the right service, or an AI reads what the customer typed and works out what they meant. It came down hard on rules, and spent a lot of its length on why AI is dangerous here.
Before picking a side, I checked what our booking assistant does today when somebody describes a service instead of naming one.
The Problem
It already matches services with AI.
When a customer tells the assistant they want the basic one, or something premium, a model reads that request against the business's real services in the category the customer is already in, and suggests one. It is careful in ways I would keep.
The model never sees the whole menu, only a short list of this business's own active services. It can only answer with a service from that list, and anything else it returns is thrown away. The name, price and duration the customer sees come from the business's records, never from the model. If the model is unsure, fails, or replies in a shape we do not expect, the customer simply sees the normal list. A suggestion is never a selection either. The assistant says it sounds like you may mean this one, shows every option in the category anyway, and asks. Only a plain yes on the next message picks it. Anything else clears the suggestion.
Requests that are about numbers never reach a model. Under fifty dollars filters the list. Cheapest and quickest are sorted from the prices and durations the business entered. That is ordinary code, and it gives the same answer every time.
So the argument was settled in our code before I asked the question. The words go to interpretation. The records decide the facts. The customer confirms.
That makes the research's central fear, an AI inventing something about a service, mostly handled for us. It also leaves the real problem in plain view.
Look at what a service is in our records. A name. A category the business types in freely. A description, a duration, and an optional price. That is all of it. A business can add styles under a service, each with its own description and the staff who specialise in it, but a style has no length or price of its own. Add-ons have a description and a price, and no length.
Nowhere in any of that can a business say long hair adds half an hour. Or that anyone with previous box dye books a consultation before a colour. Or that a treatment is only for returning clients. The facts that turn a reasonable-looking booking into a wrong one live in the owner's head, and we have never given them a place to put them.
A model cannot rank on a fact that is not there. Neither can a rule. Both options in the research assume the knowledge already exists in a form the system can use, and for us it does not.
Our two booking surfaces do not even agree on what the menu says. The step-by-step booking widget groups services under their category and shows each one's name, length and price. It does not show the description. The assistant sends that same description to the model when it ranks. An owner who carefully writes book this one if your hair is below the shoulder has written it somewhere one surface reads and the other ignores.
Assumption vs Reality
Guided service matching is a new capability with one big decision at the front of it: let businesses build question flows with fixed rules, or let AI work out what customers mean. Pick correctly and the rest is a question builder and a few screens.
The decision had already been made, and made well, when the assistant's matcher was built. I would not change it. I would extend it to every surface. What I had wrong was where the difficulty sits. The research spends its effort on mechanism, and on the risk of an AI making up a treatment. The harder thing is that the information a good match depends on does not exist in our product in any form, fixed or fuzzy. A rule builder with nothing to route on is a form with no questions in it. That changes what the first version is. Not a quiz, and not a smarter model. A small, structured place for a business to write down the handful of facts that change what a booking should be, attached to the services that actually get booked wrong. It also narrows the research's hard line on AI. It argues AI should never touch the customer-facing flow. Ours already does, and I think that is fine because of what it is allowed to do. The line I would draw is tighter and more useful. AI can help a customer find the question that matters. It can never answer that question for them, and it can never set the price, the length, or who is allowed to do the work.
The Fix
What changed is the design, not the code. This is the direction I would build toward.
Keep the matcher's contract and make it the rule everywhere. Language can go to interpretation, which may be a model. Facts come from the business's records. Nothing is selected until the customer says so. The assistant already behaves this way, and every new surface should inherit that contract rather than reinvent it.
Let a business attach a short question to a specific service, not to the whole booking. Somebody booking a men's cut should never see a question about colour history. A question has fixed answers the business wrote, and each answer can narrow which services are shown, pick a version of the service with its own approved length and price, or send the customer to a consultation or a message to the business. Or it changes nothing. Every one of those outcomes was chosen in advance by a person at the business.
Keep it short, and keep the menu. A customer who knows what they want should be able to ignore the guided path completely. The research is emphatic that long forms lose people. I have no data of our own on that, but I believe the direction, and the cheapest way to respect it is to ask only where the business has seen the mistake.
When more than one service still fits, show them, in the business's words. The assistant already does this: best guess first, every option still listed. I would add one line the business writes about how the options differ, so the customer chooses between two explanations instead of two names.
When nothing fits, or the answers add up to something the business would want to look at first, the answer is a consultation or a message. Never an empty list. A customer who wants to go from black to platinum in one visit should reach a person, and the business decides where that line is, not us.
Evaluate the rules in one place, on our servers, and let each surface decide only how to ask. The step-by-step widget might show a question as buttons. The assistant might ask it in a sentence. A hosted booking page, if the trust question from Build Note #017 is ever answered, and an agent booking on a customer's behalf, which Build Note #012 found is a trust problem before it is an API problem, would each ask their own way. None of them gets to reach a different answer. Descriptions already show what happens otherwise: one menu, read two ways.
Never infer the things that change the booking. Price, length, which staff member can do the work, and whether a customer can have the service at all come from the business's rules and the customer's explicit answers. A model can point a customer at the question. It cannot fill in the answer from something they mentioned in passing. The first version should also collect no health information at all. If the right service depends on a medical detail, that is a conversation between the business and its client, and the booking should route to it rather than capture it.
A matcher can only choose between the facts it has. I went looking for the right mechanism and found we already had a good one. It ranks real services, never invents one, and waits for a yes. It will still put a long-hair colour into a short appointment if the menu allows it, because nothing in the menu says otherwise. That is the trap in framing this as rules versus AI. Both are ways of acting on knowledge. Walk a decision tree or read a customer's words with a model, and the result is only as right as what the business told the system. The most important things a business knows about its own services have nowhere to live in most booking software, ours included. The general version: before choosing how a system should decide, check whether the facts it would decide on exist anywhere. Often the missing piece is not intelligence. It is a field nobody was ever asked to fill in.
For an owner, here is where things stand. If a customer uses our chat assistant and says they want your basic manicure or your quickest cut, it suggests a service from your actual menu, shows them the other options too, and waits for them to confirm. It does not make up services, and it does not quote a price or a length you did not set. If they ask what a service includes, it points them to your service page or your phone number instead of guessing. What it cannot do is know what you know. That a certain colour needs a consultation first. That long or thick hair takes longer. That a treatment is only for existing clients. There is no place in Everwood to tell us that today, so neither the assistant nor the booking widget can act on it. If customers regularly book the wrong thing with you, this is where it comes from, and a cleverer AI does not fix it on its own. What I want to build is a way for you to add a short question to the few services that get booked wrong, with answers you write and outcomes you choose. Show these services. Book the longer version. Ask for a consultation first. Your full menu stays open for everyone who already knows what they want. One thing you can do now without waiting for us: rename the services that get misbooked so the name says who each one is for. The step-by-step booking widget shows names, lengths and prices, but not descriptions, so for many customers the name is the only explanation they will read.
Builder Notes
A research pass on guiding customers to the right service that turned into an audit of the matching we already run. Nothing was built.
Technical Note 1
Shipped: the booking assistant's service matcher. When a customer describes a service instead of naming it, requests about price or speed (under an amount, around an amount, cheapest, quickest) are resolved by code from the prices and durations the business entered. No model is involved.
Technical Note 2
Shipped: tier language like basic or premium is ranked by a model, and only inside the category the customer is already in. The model sees a capped list of this business's own active services, can only answer with one of them, and every answer is checked against that list. Names, prices and lengths shown to the customer come from our records.
Technical Note 3
Shipped: every failure ends at the normal menu. An unsure model, a broken reply, a service that was not on the list, a timeout, or a business with no AI usage left all mean the customer sees the real list of services.
Technical Note 4
Shipped: a confident suggestion still lists every option in the category and asks. A plain yes on the next message selects it, and any other reply clears it. A less confident result puts the likely options first and lets the customer pick.
Technical Note 5
Shipped: mid-booking questions about what a service includes are deliberately not answered by the assistant. It refers the customer to the business's service page or phone and keeps the booking where it was. That instinct is the right one for this node.
Technical Note 6
Shipped: which staff can perform which service is already enforced during booking, so eligibility by staff member is not new ground.
Technical Note 7
The service record is thin. Name, free-text category, description, length, optional price. Styles under a service have a name, a description and specialist staff, and no length or price. Add-ons have a price and no length. So an answer like long hair adds time has no structured home today. Whether styles, add-ons or something new should become that home is a build-time decision.
Technical Note 8
The two customer surfaces read the same menu differently. The step-by-step widget groups by category, shows name, length and price, and never shows a service description or offers styles. The assistant hands the description to the model when it ranks.
Technical Note 9
Missing entirely: any business-written question, routing rule, intake step or eligibility screen before or during booking.
Technical Note 10
Not built and still blocked: a hosted booking page (Build Note #017) and booking by agents (Build Note #012). Both would need the same rules, which is the argument for putting those rules on the server from the first version.
Technical Note 11
Reported by the research and not verified: some scheduling platforms route customers through question forms before a calendar appears, others use variants that change a service's price and length at selection, and others collect forms only after the service is chosen, which does nothing to stop the wrong choice. Platform names are left out because no source was supplied.
Technical Note 12
Reported and not verified: stylists describing clients who booked the wrong service with no time left to do the work, and clients reading a corrected price at checkout as an upsell. No incident from an Everwood business is claimed.
Technical Note 13
Reported as a direction only: short flows that ask one thing at a time lose fewer people than long forms. Every abandonment and conversion percentage in the research arrived without a source and is cut.
Technical Note 14
A hypothesis of mine: most businesses need a question on only a few services, and the rest of the menu is fine. Merchant interviews naming the services that get changed after booking would confirm or kill it. We do not track that today.
Technical Note 15
Cut from the research and kept in the ledger: every abandonment and conversion figure, platform prices and user counts, the named medication example, the regulatory and legal claims, the scheduling techniques attributed to other platforms, the nine-platform comparison, and the named no-code builders.
Technical Note 16
Sixth time: the research came back with a finished public article attached, written as though guided matching already exists at Everwood.
Before / After
- The decision is rules versus AI
- AI in the customer flow is the risk
- The work is a question builder
- Matching is a capability we do not have
- The menu holds enough to match against
- That decision is made: AI interprets, records decide, the customer confirms
- The risk is AI setting a fact it should only suggest
- The work is giving businesses a place to write down what they know
- Matching ships in the assistant and should become one contract for every surface
- The menu is missing the facts that make a booking wrong
What I'd Do Differently
I would have asked what our assistant does today before asking anyone to research the choice between rules and AI.
The research is thorough on the argument, and the argument had already happened inside our own code, with a sensible outcome and tests for the ways it can fail. Twenty minutes with the matcher would have moved the whole question from which mechanism to which facts.
This is the second note running where the gap was not the thing I assumed we lacked. Build Note #020 found we had the machinery for search and had pointed it at ourselves. Here we had the matching, and pointed it at a menu that cannot carry the information that matters. The cheap fix is to open every roadmap research brief with a plain description of what we already run.