Our Voice Tools Never Book Anything on Their Own. That Is Why Phone Answering Comes Last for Everwood.

The Build

Nothing shipped from this research. Voice Tools already exists as a beta, switched off for every business until we turn it on, and this note is about what should come next.

Voice Tools is for the moments when somebody's hands are busy. A stylist has foil in one hand and a brush in the other. Voice Tools has three parts. Customers can talk to the booking assistant instead of typing. Staff can say an appointment out loud and have the form fill itself. Staff can also dictate a note straight onto a customer's profile.

The research was long and confident. Its first recommendation was an AI phone answerer. It would pick up when the salon cannot, capture what the caller wants, and text them a link to finish booking. Dictation for staff notes came second. After that it went deep into microphones, noise, accents, latency, per-minute costs and recording law.

Before ranking anything, I went back through what we already run.

The Problem

What we already run is careful.

Start with staff voice fill. A staff member taps record, says something like "Jess at two tomorrow, gel manicure with Annie," and taps stop. Plain code reads the dates, times, phone numbers and party size. A model helps with names and with how someone describes a service. Every service, staff member and add-on it hears is then matched against the business's own records, using the same matcher Build Note #021 described. What comes back is a review panel, not an appointment. It lists what it found and what is missing. Where a name matched more than one thing, it shows the options. The staff member taps Apply to Form. Filled fields are highlighted, ambiguous ones get picked by hand, and the appointment is saved with the same button as a typed one. The voice step cannot create an appointment at all.

Dictated notes work the same way. The words go into the note box. Saying "save this note" only fills the box. Clearing the box asks first. A person clicks Add Note.

Customer voice is the most interesting of the three. A customer taps the mic in the booking assistant and talks. When they pause, the recording is transcribed, tidied a little, and sent as their chat message. They do not press Send. From there it is an ordinary typed message. The assistant replies in text and never speaks. The mic does not listen while it is replying. Voice mode stops when a booking completes, and it pauses if it hears nothing. If the microphone fails, the customer is told they can keep typing.

What stops a misheard sentence from becoming a wrong booking is not the voice code. It is the booking flow. The assistant shows a summary, and a booking is only created after a clear yes at that summary. A yes given earlier, to some other question, does not count. Words like change or actually take the confirmation back.

We had also built a gentler version first, one that put the words in the text box and left Send to the customer. It is still in the code and still tested. It is not what the widget uses today.

So all three parts follow one rule the research never states. Voice produces text. The text shows up on a screen. A person reads it and decides. The booking rules underneath do not change because someone spoke instead of typed.

Now look at the research's top pick with that rule in mind. A phone call has no screen. The design the research recommends works around that: the AI does not book, it texts a link so the caller can finish on a screen. For us, that screen would be a booking page we host. We do not have one. Build Note #017 found it is blocked on a trust question: how do we know a booking request is legitimate when it did not come from the business's own website? Texting is deliberately low on our roadmap too. On top of that there is phone service we do not run, and callers would need to be told plainly that they are talking to software.

And I cannot say whether our businesses miss calls at all. We have never measured it. The research quotes a missed-call figure with no source, and it is cut.

Assumption vs Reality

The Fix

What changed is the design, not the code. This is the direction I would build toward.

Keep voice as a way to type, never a way to decide. Anything voice hears goes through the same booking rules as typed input, and nothing is saved until a person has seen it. Every surface already works like this, so the job is to keep it that way as Voice Tools grows.

Measure corrections before building anything new. When staff apply a voice fill and then change a field before saving, record which kind of field changed, never the words themselves. Do the same for customer voice mode: how often it pauses, retries, or gets abandoned for typing. Without that, every argument about voice quality, including this one, is a guess.

Give transcription the business's own words. My bet is that names are where voice fill goes wrong most: the customer's name, the staff name, what the service is called. I would expect dates and times to be heard fine. That is a hypothesis, and the correction numbers will confirm it or kill it. If it holds, send the business's own service and staff names along with each recording, then compare correction rates with and without them.

Treat names, phone numbers and emails as the hard fields for customers. A misheard name or phone number does show up in the booking summary, but only helps if the customer actually reads it. An email address is not read back at all; the summary only says one was provided. When the assistant asks for contact details, I would steer the customer toward typing, or show what was heard for them to fix before it is sent. I would decide between those after watching real customers, not before.

Tell people what happens to their voice. Before the first recording, the widget should say in one line that audio goes to a transcription service and the words are kept with the chat. Chat logs should also mark which messages were spoken, so a business looking back at a dispute knows a line might be misheard. The research spends pages on recording law. I will not turn that into legal advice. What I took from it is that the rules differ by place, and a room with a client in it deserves more care than a phone line. That wording needs a legal read before it ships.

Leave some things for later, and say so. No phone answering. No AI voice talking back to customers. No cancelling or rescheduling by voice. No always-on listening at the front desk. No card numbers read out loud. No telling people apart by the sound of their voice. No clinical note-taking. Other companies already build some of these, and I am not claiming they are wrong to. For Everwood, each one is a new product with its own trust problem, and none of them should come before we can measure the voice tools we already have.

Builder Notes

Before / After

What I'd Do Differently

I would have logged corrections from the day voice fill shipped.

We built careful review screens and never recorded what happens on them. Every edit a staff member makes to a voice-filled field is a free label saying voice heard this wrong, and we have been throwing those away. With a couple of months of them, this note would be about numbers instead of hypotheses.

I would also have written the customer-facing line about where audio goes at the same time as the privacy comments in the code. The code is honest about it. The customer never sees it.

This is the third note running that opens by finding we already built more than the research assumed. Starting every research brief with a plain description of what we already run, the fix I suggested last time, would have saved this one most of its competitor survey.