AI receptionists for SMS, voice and chat with code-checked booking

Problem

Local service businesses lose enquiries when nobody replies fast enough, and a basic AI answering agent that only takes a message still leaves staff to call back, find a time and enter the lead. Letting a language model book directly is risky: models invent plausible times, misread time zones, confirm bookings that were never written, and can send content that messaging rules forbid. Once an assistant is talking to customers, staff also need to review what it said, and each viewer should see only their own locations.

Goal

Take an enquiry from first message to a confirmed appointment and a clean, routed lead in one conversation, over SMS, voice or web chat, with code checking everything the model proposes before it touches a real calendar or CRM, compliance built in, no lead ever lost, and a safe way for staff to audit conversations.

My role

Sole engineer on the built systems: conversation design and agent briefs, workflows built as code and deployed through an API, the availability and booking services, the guardrails outside the model, compliance handling (consent, quiet hours, AI disclosure, opt-out), the lead-intake and follow-up pipeline, the offline and live test harnesses, operator tooling and the identity-scoped audit portal. Also contributed to the design of the regulated-setting phone receptionist described at the end, which is at design stage.

Solution

One pattern across three channels: the language model handles the conversation, and deterministic code makes every consequential decision.

An SMS scheduling assistant follows up on every web enquiry within business rules, replies through a single forced structured tool call, and books only after code re-checks live availability.

Voice and chat receptionists, generated from version-controlled briefs, call two webhook services mid-conversation (one finds real free times, one re-checks and books), and a post-conversation pipeline validates, routes and follows up every lead.

An identity-scoped audit portal lets staff read the assistant's conversations for only the locations their verified identity allows.

Design, not built: a safety-first phone receptionist for a regulated, safety-sensitive setting, where the same code-checks-the-model principle meets stricter escalation rules.

How it works

SMS assistant.

Workflows are generated from source files (prompt, facts and configuration) by a build script and pushed through the automation platform's API, so the repository is the single source of truth.

Intake: a new lead is checked for consent, a rollout allowlist and quiet hours in the recipient's own time zone before an opening text goes out.

Inbound: the webhook signature is validated, conversation state is loaded, and compliance keywords such as opt-out and help are handled by fixed code without the model.

Everything else goes to the LLM, which must reply through one tool with structured fields (the reply text, any booking choice, and whether to hand off to a person). If it times out, a smaller model takes over.

Code then decides. It re-checks the chosen slot against live availability before booking, supplies the wording itself whenever a commitment is made, strips links and phone numbers from outgoing text, keeps each message to one segment, and on hand-off alerts staff and goes quiet. Operators have a kill switch, manual send and book, and a live status view.

Voice and chat receptionists.

Each agent is generated from a versioned brief. It says it is an AI, collects contact details, and asks when the caller wants to come in.

Availability: the caller's own words ("next Tuesday afternoon") become a local-time search window, and the service returns a short list of real free times phrased the way a person would say them.

Booking: the time the model sends back is converted to the business's local clock, re-checked against business hours, the current time and a fresh free and busy read, and only then written. Any doubt falls back to a promise to confirm by email.

After the conversation, an intake workflow normalises and deduplicates the lead, screens disposable email domains, creates or updates the CRM contact, verifies the email and routes to a follow-up email, a call-back task or a bad-email tag. No branch discards a lead.

A scheduled polling job watches replies, opt-outs and bounces, and a shared error workflow alerts on any failure. Deploys fill credential placeholders at deploy time and refuse to run if duplicated feature switches disagree.

Audit portal.

An identity-aware proxy requires a workspace sign-in. The server re-checks the staff domain and maps the verified identity to the locations it may read, from configuration, never from request parameters.

Conversations are keyed by their owning location. The list returns summaries without transcripts, and the detail view answers "not found" for both unknown and other locations' conversations, so it never reveals that a record exists.

A dependency-free front end renders customer text safely and keeps the last good view if a poll fails; its tests mostly assert refusals.

Testing. An offline harness runs the exact code the deployed workflows run against a mock runtime, backed by live end-to-end and fault-injection suites. For voice and chat, scripted conversations are run repeatedly and graded on outcomes (booked or not, which time), not wording.

Design, not built: the regulated-setting phone receptionist.

One shared safety and escalation policy sits above per-location configuration, so every site follows the same non-negotiable rules. Anything that sounds urgent or unsafe goes straight to a person.

Calls reach the voice agent by forwarding existing numbers according to working hours, so nothing changes for callers.

Scheduling data comes from the organisation's existing system through an integration layer, read-only first; write-back is planned only once the data provider's terms allow it, with a guard against stale slots.

A scenario test suite runs against the policy before any voice testing, and go-live is staged one location at a time.

Technical challenges

An LLM cannot be trusted to book or promise, so every consequential step moved into code, including a re-check at booking time for slots the model invents or that were taken after they were offered.

Time zones: the workflow engine ran in UTC, so naive parsing turned a caller's morning request into a slot before dawn. A two-pass local-to-UTC conversion fixed it and stays correct across daylight-saving changes. The model sometimes sends an offset and sometimes a bare local time, so every time is normalised before any check; otherwise one interval is validated and another booked.

The calendar API can report an unreadable calendar inside a successful response. Reading that as "nothing busy" would offer every slot, so it is treated as no answer and goes to the fallback.

A live call must never crash: the services never throw and always return something the agent can say.

Carrier content rules on every outgoing message, and quiet hours per recipient time zone.

Multi-location access without insecure direct object references or existence leaks.

Testing non-deterministic agents and low-code workflows properly.

In the regulated design: one safety policy that no per-location setting can weaken, and protection against stale availability once write-back exists.

Capabilities

Instant follow-up by SMS, with question answering inside strict rules
Natural-language time requests turned into real availability
Re-check before booking, with spoken or written confirmation and a graceful fallback
Per-business configuration of hours and appointment lengths
Opt-out and help handling without the model
Quiet hours in the recipient's time zone
Outbound content filtering and staff hand-off alerts
Model failover, kill switch and manual override
Lead validation, deduplication, disposable-domain screening, email verification, CRM tagging and routing
Reply, opt-out and bounce monitoring with central error alerting
Workflows deployed from version control
Identity-scoped conversation audit
AI disclosure and consent handling

Technology

Impact

Every enquiry received an immediate, compliant follow-up that could end in a booked appointment and a tagged, qualified lead without staff involvement, while anything uncertain still reached a person. Code-side checks removed a whole class of failure: offering or confirming times that do not exist. The SMS system passed full live verification, including fault injection, before rollout, and staff could audit their own locations' conversations with no wider exposure. The regulated-setting receptionist is a design; no build or outcome is claimed for it. No metrics are claimed.

Skills demonstrated

Conversational AI design
LLM structured output
Deterministic guardrails around a model
Time-zone and daylight-saving-correct scheduling
Messaging compliance
Workflow automation as code
Calendar and CRM integration
Lead-pipeline design
Multi-location access control
Test-harness engineering for non-deterministic systems
Safety and escalation policy design for regulated settings
Operational tooling