Appearance
EAS booking & classification: what's happening and why it matters
Plain-English overview for anyone following the EAS engagement. (A separate technical doc holds the code-level detail for the fixes.)
Why this is the thing we keep coming back to
Everything Avoca reports to EAS — the capture rate, the weekly performance report, which shops are booking their leads and which are leaving money on the table — rests on two judgments the system makes about every single call: what was this call about (the reason), and was it a real booking opportunity (bookable).
If those two judgments are wrong, every number downstream is wrong. A shop can look like it's missing leads it never had, or look like it's capturing leads it actually lost. That's why this has been the focus: it's the foundation the entire EAS reporting and coaching story sits on. Get it right and the numbers are trustworthy; get it wrong and we're reporting fiction.
Two things had to be solved to make that foundation trustworthy for an auto-service client. Here's each, in plain English.
Problem 1: A customer is told they're booked, but the booking never lands
What was happening. A customer calls, the AI agent confirms an appointment — "you're all set for Tuesday at 8." But after the call, that booking sometimes never made it onto the shop's schedule. The customer believes they have an appointment; the shop has nothing on the board; the customer shows up to an empty slot.
Why it happened. Before actually creating the booking, Avoca ran a series of safety checks — re-confirming the time was still open, matching the exact service, finding the customer and vehicle in the system. If any check failed, Avoca would refuse to create the booking — even though the customer had already been promised one. The catch: AutoOps (the auto shops' booking system) doesn't block double-bookings or check availability the way Avoca was — as long as a real appointment time is set, it accepts the booking. So Avoca's own caution was the only thing blocking bookings AutoOps would have taken. We were guarding against restrictions AutoOps doesn't impose.
How we solved it. We flipped those checks from "block the booking" to "make the booking and flag the concern." Now whenever the agent promises an appointment, a booking always lands on the shop's board — with any caveats (couldn't confirm the vehicle, used a general service category, etc.) noted on the job for the shop to verify and tidy up. The customer's promise is always kept; the shop does the cleanup. The only thing that can still stop a booking is if no actual time was agreed on (nothing to book) or AutoOps's own system errors — and in those rare cases, the shop gets an urgent email to book it by hand.
Problem 2: The classification wasn't built for auto shops
The situation. Avoca's out-of-the-box classification — how it labels each call (booking, reschedule, cancellation, question, spam) and decides whether it was a real lead — is designed for home services (plumbing, HVAC, and the like). EAS is an auto-service business, and auto calls don't look like home-services calls. The clearest example: tow-ins — a customer arranging to have their disabled car towed to the shop. That's a real, valuable lead, but the default setup had no concept of it, so those calls were being mislabeled and miscounted.
What we did. We built a custom classification tailored to auto service for EAS: the right set of call reasons (including tow-ins and the auto-specific booking / unbooked / excused categories), tuned to how these calls actually go. We rolled it out to all 24 EAS shops, applied it to recent calls so the history is consistent, and rebuilt the weekly report on top of it. At this point classification is working — calls are being categorized correctly across the shops.
Where it stands — and the one problem left
Classification is solid. Booking promises are kept. The reports are running. But there's one issue still to resolve, and it's worth understanding why it happens — because it isn't a simple bug, it's a design tension baked into the system.
The symptom: sometimes a call is counted as a bookable lead even when its reason clearly wasn't a booking — e.g., a customer who just called with a question gets counted as a missed lead.
Why it happens. The system makes two separate judgments about each call:
- What was the call about — the reason ("question," "booking," "cancellation," etc.).
- A separate check that asks "did the agent confirm a booking?"
And there's a rule: if that second check says "yes," treat the call as a bookable lead — even if the reason says it wasn't a booking. That rule exists for a good reason: a genuine booking should always count as a lead, even if the category somehow got mislabeled. It's a safety net.
The paradox. That second check is its own AI judgment, and it sometimes says "yes" when it shouldn't — it misreads a question, or a non-booking, as a confirmed booking. When it does, the safety-net rule kicks in and overrides the correct reason, marking a non-booking as a bookable lead. So the system ends up trusting the wrong signal over the right one. The result: calls that were genuinely just questions get counted as lost leads.
Why that's a big deal. This is the difference between a report EAS leadership can trust and one they can't. If "questions" are being counted as missed bookings, the capture rate is understated, shops get flagged for problems they don't actually have, and the one thing Avoca is fundamentally measuring — are we booking the leads we get — stops being reliable. The whole value of the reporting and the coaching depends on this number being honest.
What's needed (the decision). The fix is to stop letting the "did they book?" check override the call's reason for EAS — let the reason decide whether a call is a lead, on its own. It's a small, reversible change, scoped to EAS only. The open decisions: (1) make that change, and (2) whether to also tighten the "did they book?" check, which is the underlying source of the false signals.
That, in short, is why classification has been the work: it's the bedrock under every number EAS sees, it had to be rebuilt for the auto industry from a home-services default, and the last remaining issue is a genuine design conflict between two AI judgments — not a typo to patch.