build.allanninal.dev

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

A booking assistant on AWS for a few dollars a month

Booking is the part of running a service business that quietly eats your week — a customer asks for “sometime next Tuesday afternoon,” you check your calendar, you write back with three options, they pick one, you write the confirmation, you remember to send a reminder. Here’s how to design a small assistant that does all of that for you, and only escalates the unusual ones.

The whole system on one page

Before any code, here’s the shape of what we’re building.

System architecture: four outside surfaces, three inside AWS At the top, four external surfaces in a row. Far left, “The customer” — the person asking to book. Centre-left, “Your service rules” — the Drive doc with services, durations, buffers, working hours, blackout dates, deposit policy. Centre-right, “Your calendar” — Google Calendar with existing events, working hours, and the bookings the assistant writes in. Far right, “Your team” — where ambiguous or VIP requests escalate. Each connects via an arrow to the AWS account container below. The customer has a two-way arrow representing both the inbound request and the outbound proposal/confirmation. Service rules feed in. Calendar is a two-way arrow — read for availability, written when a booking confirms. Team receives escalations. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Reader/Parser — receives the request, extracts service, time window, and contact. In the middle, the Scheduler — queries the calendar with the service rules, builds 2–3 viable slots, picks one of four moves: propose, draft, escalate, decline. On the right, the Confirmer — locks the slot, writes to the calendar, sends the confirmation, queues reminders. Internal arrows flow left to right. A note at the bottom reads: every request gets one of four outcomes, and the calendar is never double-booked. The customer asks to book Service rules durations, buffers, hours Your calendar Google Calendar Your team when a human is needed request in & out guides read & write escalate when needed AWS account Reader / Parser extracts service, time window, contact Scheduler picks one of four: propose, draft, escalate, decline Confirmer locks the slot, writes & reminds structured decision Every request gets one of four outcomes — and the calendar is never double-booked.
Fig 1. Four outside surfaces, three pieces inside AWS. Request in, slot proposal back, calendar updated atomically when the customer picks one.

What you set up once (the outside)

  • A receiving surface — a small embedded web form on your site (the fast path), or your existing email address (the free-text path). Either drops a request into the assistant in the same shape downstream.
  • A short service-rules file — the services you offer with their durations and prices, working hours, buffer times between bookings, blackout dates, who’s qualified to do what, deposit and cancellation rules, the tone you want for confirmations. Lives in a Google Doc you can edit anytime.
  • Your Google Calendar — the same one you already use. The assistant reads availability and writes confirmed bookings into it. Nothing else moves.
  • An escalation inbox — for ambiguous requests, VIP customers, and anything outside what you offer. Your normal inbox or a shared team queue, whichever you already use.

What runs on every request (the inside)

  • The reader / parser — takes the inbound request, in whatever shape it arrived, and turns it into a structured form: which service, roughly when, who’s booking. A web form arrives mostly structured already; an email might say “next Tuesday afternoon for a haircut.”
  • The scheduler — reads the structured request, queries the calendar, applies your service rules (duration, buffers, working hours, blackouts, who provides what), and picks one of four moves: propose 2–3 viable slots, draft a proposal for your review, escalate to a human, or politely decline.
  • The confirmer — once the customer picks a slot, atomically locks it on the calendar (so two simultaneous requests can’t double-book), writes the event with the right details, sends the confirmation in your tone, and queues the reminder messages.

In plain words

A booking request lands. The cloud reads it — whether it came from a web form or an email like “can we do sometime next week?” A small AI turns the request into a clean shape, queries your calendar, applies your rules, and writes back with two or three slots that actually work. The customer picks one with a single click. The cloud writes the event into your calendar, sends a confirmation in your voice, and quietly sends a reminder the day before. You see only the bookings that are unusual.

Total cost runs in coffee-money territory at typical small-business volume — cents per booking, going up smoothly with how often the inbox rings.

Design rules that shaped every decision

  • The calendar is the source of truth. Every check, every write, goes through Google Calendar — not a parallel database that drifts.
  • The assistant proposes from your service-rules file only — never invents durations, prices, or who can do what.
  • Slot writes are atomic. The confirmer claims a slot before it confirms; if the calendar moved, it re-proposes.
  • Auto-confirm only on clean requests with an explicit slot pick. Anything fuzzy becomes a draft proposal a human approves.
  • Configuration lives in a Drive doc you can edit. Updating durations, hours, or blackouts never needs a deploy.
  • If Google Calendar isn’t your calendar, Microsoft 365 swaps in cleanly — same shape, different SDK.

Why this shape

Booking is one of those problems where most existing tools either over-promise or under-deliver. Per-seat scheduling apps charge the same whether you take ten bookings a month or ten thousand. Generic AI “assistants” happily promise slots that conflict with what’s already on your calendar, or worse, invent service durations they don’t know. Customer-facing booking widgets force the customer to think in your service taxonomy — “is this a 30-minute consult or a 60-minute first visit?”

The setup above splits the difference. A web form for customers who already know what they want (the easy 80%); a free-text path for the rest, parsed by a small AI; the calendar as the authority on availability; your service rules in plain English in a Drive doc; and atomic writes so the calendar is never wrong even if two requests collide.

The next five posts walk through each piece in turn — how a request reaches the assistant, how the parser turns fuzzy text into structured form, how the scheduler picks slots, how a booking gets confirmed without double-booking, and what the whole thing actually costs. One diagram per post. A final engineering reference at the end gives engineers the dense version with precise service names and model IDs.

All posts