build.allanninal.dev

Part 2 of 7 · Booking assistant series ~4 min read

How a booking request reaches the assistant

Most customers know what they want and would happily click a button. Some write long emails because that’s how they think. A few are regulars you’d never want to send through an AI in the first place. Three lanes at the door — one for each — and the scheduler only runs on the ones that need it.

Inbound routing: three lanes before the scheduler runs A vertical flow. At the top, two parallel inbound surfaces. On the left, “Web form” with structured fields for service, date window, and contact. On the right, “Email” with free-text body. Both feed an Intake Lambda that normalises the shape. Below it, a decision point labelled “Sender on the VIP allowlist?” From the decision, three lanes branch out. Left: “Web-form fast path” for clean structured requests — goes straight to slot proposal with no AI parsing. Centre: “AI handle” for free-text email or partial form submissions — passed to the parser. Right: “Direct escalate” for senders on the allowlist (regulars, partners, VIPs) — the request is forwarded to the human inbox right away. A bottom note reads: by the time the scheduler runs, the easy ones are answered and the VIPs are already through. Web form structured: service, window, contact Email free-text body Intake normalise the shape, log the request Source & sender check classify before any AI runs structured form free text on the allowlist Web-form fast path skip the parser, straight to slot proposal. cheapest, fastest, the 80% case. most customers AI handle parse the free text, then propose slots. a few cents per request. email enquiries Direct escalate forward straight to the human inbox, untouched. regulars, partners, first-time VIPs By the time the scheduler runs, the easy ones are answered and the VIPs are already through.
Fig 2. Three lanes at the door. The fast path costs nothing; the AI path runs only when there’s actually free text to parse.

Two surfaces, one shape

The assistant accepts requests from two places: a web form on your site, and the existing email address you already publish. Both paths drop a request into the same intake pipeline, in the same shape, so everything downstream — the parser, the scheduler, the confirmer — only ever has to handle one kind of object.

The web form is short on purpose. Three fields: which service, when (a date or rough window), and the customer’s contact. Submitting it is one click, no account, no widget that takes thirty seconds to load. The form posts directly to a Lambda function URL and returns either “here are your slots” or a polite “we can’t do that one, but here’s what we can offer.”

The email path catches the rest. Long messages, repeat customers who know your name, people who’d never use a form — all land in the same place. The intake step strips quoted threads and signatures the same way the email assistant in the previous series does, then passes the body to the parser.

Lane 1 — Web-form fast path

If the request came from the form and the three required fields are populated, the assistant skips the parser entirely. No AI runs. The structured request goes straight to the scheduler, which queries the calendar and proposes slots in a fraction of a second.

This is the cheapest possible path — just a Lambda invocation and a Google Calendar query. It’s also the most common, and that’s the point: the AI exists to handle the messy 20%, not to add cost to the easy 80%.

Lane 2 — AI handle

The default for everything that arrives as text. An email saying “hi, can I get a haircut sometime Tuesday afternoon? My name’s Maria.” A web form where the customer wrote their request in the “notes” field instead of picking a service. A reply on a thread you’d started days ago that now has “actually let’s do Friday at 2” in it.

These all need the parser, which is the subject of the next post. The parser pulls out service, time window, and contact identity, and hands the result to the scheduler in the same shape the form uses.

Lane 3 — Direct escalate

The allowlist. A short list of email addresses, domains, or patterns that always skip the AI. Examples that usually belong on it:

  • Existing customers booking a follow-up — you probably want to greet them yourself.
  • Partners or referral sources sending you work.
  • Anyone replying on a thread a human has already taken over.
  • Senders whose previous request the assistant got wrong — they get pinned to the allowlist for a few weeks while the rules tighten.

For senders on the list, the intake step forwards the request to your normal inbox unchanged, with a small header tag (X-Assistant-Lane: direct) so you know it bypassed the AI. The customer notices nothing — they just get a human reply — and you stay in the loop on the relationships that matter most.

In plain words

Most booking requests don’t need an AI to handle, and some shouldn’t. A short web form catches the easy 80%; an email path with an AI parser catches the messy 20%; a small allowlist sends regulars and VIPs straight to a human. By the time the scheduler runs, every request has a known shape and a known reason to be there.

All posts