build.allanninal.dev

Part 3 of 7 · Booking assistant series ~5 min read

How the assistant understands the request

A booking request is really three questions stacked on top of each other: what service do you want, when roughly do you want it, and who are you. The parser’s only job is to pull those three out of whatever the customer wrote and hand them on as a clean object. Anything it can’t cleanly extract becomes a draft for human eyes, not a confident guess.

Parsing: three extractors turn fuzzy text into a structured request A vertical flow. At the top, an inbound box labelled “Free-text request” with an example: ‘Hi, can I get a haircut sometime next Tuesday afternoon? My name’s Maria, 0917-555-1234.’ An arrow leads down to the “Service-rules retriever” box, which pulls the relevant section of the service-rules file from a small vector index so the parser knows what services exist. From there, three parallel extractor boxes sit side by side. Left: “Service extractor” — matches free text against the service catalogue (haircut, colour, blow-dry, etc.) and returns a service ID with a confidence score. Centre: “Time extractor” — turns ‘next Tuesday afternoon’ into a structured window (date range plus time-of-day band) using the request’s timestamp as the anchor. Right: “Contact extractor” — pulls name, phone, and email if present, and looks up the contact in the existing customer table to attach an ID if it’s a returning customer. All three feed a merger box at the bottom labelled “Structured request,” which holds the three fields plus an overall confidence score. Below the merger, two arrows: one labelled ‘all three confident’ goes to the scheduler; one labelled ‘any field unclear’ goes to a draft proposal that a human approves. A bottom note reads: every field is either confident or asked about — the parser is never allowed to guess silently. Free-text request "haircut sometime next Tuesday afternoon, Maria, 0917-555-1234" Service-rules retriever pulls the relevant catalogue chunks Service extractor match against catalogue svc_id: haircut_basic conf: 0.96 Time extractor resolve relative dates window: 2026-05-05 13–17 conf: 0.88 Contact extractor name, phone, email + lookup name: Maria · phone: +63… conf: 0.92 Structured request service + window + contact + overall conf all three confident any field unclear → Scheduler propose slots automatically → Draft for review human approves before sending Every field is either confident or asked about — never silently guessed.
Fig 3. Three small extractors run in parallel, then merge. Confidence on every field; anything unclear becomes a draft.

Three things to pull, in parallel

The parser doesn’t do natural-language understanding in general. It does three very narrow things in parallel, and that’s a deliberate design choice — each extractor is small, has a single job, and is easy to test on its own.

The service

Match the customer’s words against the service catalogue from your service-rules file. The catalogue is a small list (haircut_basic, haircut_with_colour, blow_dry, first_visit, etc.) with names, durations, prices, and a few aliases each (“trim,” “quick cut,” “just a haircut”).

The retriever pulls the relevant chunk of the catalogue with a vector search before the model runs — so the parser sees only services that exist, not a hypothetical universe of them. The output is a service ID and a confidence score in [0, 1]. If the score is below the threshold, the parser doesn’t guess; the request becomes a draft (“was this a basic haircut or a colour?”) for you to clarify.

The time window

The hardest of the three, and the one most home-grown systems get wrong. “Next Tuesday” is unambiguous if you know what today is. “Tuesday afternoon” needs a definition of afternoon. “ASAP” is a window the size of your business hours. “The week of the 15th” is a different shape of window again.

The time extractor resolves all of these into the same shape: a date range plus a time-of-day band, both anchored to the request’s timestamp in your business’s timezone. “Next Tuesday afternoon” sent on Friday May 1 in Asia/Manila becomes {date_range: [2026-05-05, 2026-05-05], time_band: [13:00, 17:00]}. The scheduler in the next post will use that window directly to query the calendar.

The contact

Name, phone, and email if present, plus a lookup against your existing customer table. If the customer is returning, the extractor attaches their existing ID and any preferences on file (“always books with stylist A,” “wheelchair access required”). If they’re new, it just records what they wrote, plus a flag so you know to greet them as a first-timer in the confirmation.

This is the cheapest extractor — it’s mostly a regex pass for phone numbers and emails, then a database lookup. The AI only runs if the message is unusual enough that the regex misses something obvious.

Confidence, not certainty

Each extractor returns its result and a confidence score. The merger combines them: if all three are above threshold, the request goes straight to the scheduler. If any one is below threshold, the request becomes a draft proposal — a one-screen view in your phone where you can correct the field, hit approve, and the assistant carries on from there.

Drafts feel slower the first week. They’re actually faster: a five-second tap is cheaper than the ten-minute back-and-forth you’d have had to clarify the request yourself.

What the parser deliberately doesn’t do

  • It doesn’t guess preferences. “Maria, my usual” from a returning customer pulls in their last booking’s service if confidence is high; otherwise it asks. The assistant never invents a preference the customer didn’t state.
  • It doesn’t price. Pricing is in the service catalogue and shown to the customer at the proposal step, not invented in the parser. If the customer asks about pricing in the request itself, that’s passed through to the scheduler so the proposal can include it.
  • It doesn’t commit. Nothing the parser does writes to the calendar. That happens only in the confirmer, after the customer picks a slot.

In plain words

Three small extractors do one job each — what service, when, who — and each returns a confidence score. If everything’s clear, the assistant proceeds. If anything is borderline, you get a draft to approve in seconds. The parser is allowed to be confident, or to defer; never to silently guess.

All posts