TL;DR
The phrase "auto-booking from AI chats" hides four assumptions that vendors rarely deliver on: (1) the owner is told a booking happened, (2) the right service is picked from the catalog, (3) the day the lead asked for is honored or escalated, and (4) the system actually understands when a lead said yes. Most tools fail at all four. We just shipped fixes for all four in POG.
What you'll find in this guide
Why "auto-booking" became a buzzword
If you run a home-services business in the DMV — HVAC, plumbing, electrical, lawn, cleaning, roofing — you have probably been pitched at least one "missed-call text-back" or "AI receptionist" tool in the last twelve months. The pitch is always the same: your missed calls become leads, the AI replies, the AI books an appointment, you wake up to a calendar full of jobs.
It's a great story. The mechanics underneath are usually weaker than the marketing. Most of these tools were built around a single demo flow — lead texts in, AI replies, AI inserts a row in a database called "appointments." Click. Done. The demo gets you to write a check. The four gaps below show up after week two of using the product, when you start losing leads instead of catching them.
This post is the diff between "the marketing slide" and "the production code." If your vendor can't answer the four questions in here, they have not actually solved auto-booking. They have a demo.
Gap 1 — The owner doesn't know it happened
The AI books an appointment. You find out 9 hours later when you open the dashboard.
This sounds basic. It is basic. The reason vendors skip it is because owner-SMS introduces real cost (a few cents per text) and real risk (the first deploy can blast a backlog if the engineer doesn't think it through). The fix is two hours of work and one ALTER TABLE. Most vendors haven't done it.
Gap 2 — The wrong service gets booked
You offer five services. The AI books the first one in the dropdown every time.
_match_service_to_history(), scans the last 5 inbound messages from the lead and picks the best match. Fallbacks are logged to stdout for debugging.Gap 3 — The wrong day or wrong time gets booked
The lead says "Tuesday at 2pm." The AI books Wednesday morning.
pending_appointments with a reason of requested_time_unavailable and let the human dispatcher call the customer back._extract_requested_datetime() helper parses day-of-week, today/tomorrow, and AM/PM hints. If a slot isn't free that day, the booking escalates to a human queue. We never silently book a different day.The principle is the same one any senior dispatcher would tell you: under-promise, never re-schedule without consent. Once your AI breaks that rule, you've handed a competitor your customer.
Gap 4 — The system doesn't actually understand "yes"
The booking gate is a list of keywords. It fires on the wrong messages.
any(kw in message.lower() for kw in ["book", "schedule", "appointment", "yes", ...]). So when a lead asks "what's your booking policy?" or "how does scheduling work?" or "do you do appointments on weekends?" — the system fires "yes." It books an appointment. The lead is bewildered.{book, ask_question, decline, ambiguous}. Only book auto-books; ambiguous queues for human review; ask_question and decline stay in the conversation. Plus a fallback heuristic that runs when the LLM is rate-limited — because if the API is down, the worst outcome is "we were conservative and queued a couple of bookings for the dispatcher," not "we spammed the wrong customer."lead_scorer.classify_intent() now uses ai_engine.ai_json() with a keyword fallback. Our 10-message regression set hits 10/10 on the heuristic-only path (the production floor when the LLM is unavailable). Booking only happens on intent="book"; ambiguous goes to human review.What to demand from any vendor
If you are evaluating an AI lead-recovery tool today, here are the four questions to ask. Don't accept "yes" as an answer — ask them to show you, in their dashboard or in their code, exactly how it works.
| Ask the vendor | What a real answer looks like |
|---|---|
| "Does the owner get notified the moment a lead self-books?" | SMS to the owner's cell, in seconds. Show the message format. Show how you handle the deploy-day backlog. |
| "How do you pick which service to book if I have more than one?" | Match the conversation history. Show the matching logic. Show the fallback log entry. |
| "What happens if my lead asks for Tuesday at 2pm and Tuesday is full?" | The booking escalates to a human review queue with the original request preserved. Never silently rolls to a different day. |
| "How does the system decide a lead said yes?" | An intent classifier with a regression test set. Not a keyword list. If they say "we use AI," ask them to show the prompt and the labels. |
| POG | All four. Just shipped. Open the code if you want to see how. |
If a vendor can't answer those four questions cleanly, "auto-booking" is a marketing claim, not a feature.
The Punchline
We just fixed all four in POG. Every Katch Leads tenant gets these defaults from this point forward — no add-on, no upgrade, no extra charge.
FAQ
Is this a public beta or generally available?
Generally available. The four fixes shipped together to production on 2026-05-08 and are live for every Katch Leads tenant immediately. No flag, no rollout, no "contact sales."
What if my AI lead-capture vendor is not POG?
Take the four questions to them. If they answer all four with concrete mechanics, you have a good vendor. If they wave their hands or pivot to another topic, you now know what to ask in your renewal conversation.
Does the booking-link banner change anything for existing tenants?
If you already have a booking URL configured (Google Calendar, Cal.com, Calendly, or a custom one), nothing changes. If you don't, you'll see a yellow banner on the leads tab pointing you to the right setting. Auto-booking can't actually run without a link to share with the lead.
Why didn't you do this in version 1?
Honest answer: version 1 was the demo. The four gaps surface only when you have real multi-service tenants, real conversation history, and real after-hours leads. Once we had all three, the fixes wrote themselves.
main on 2026-05-08 and is live in production. If you'd like to see the actual code — the regression test set, the intent classifier, the date extractor — the repo is public on GitHub.