Multi-tenant voice and messaging platform · UK

BookerBot

One system answers the phone, the texts and the WhatsApp for five businesses, and books the job while the customer is still in the conversation.

Before

Enquiries arrived from ad campaigns, website forms and the phone, landed in an inbox or a voicemail, and waited for somebody to have a spare half hour. Most of the ringing round happened the next working day, by which point the faster company had the job.

After

Every inbound channel is watched. A conversation opens within about two minutes, qualifies against a prompt contract the client wrote themselves, offers real calendar slots, books one, and hands a human the calls that should not be automated. Five client workspaces run off the same codebase.

median from an inbound message to the agent’s reply: 8 sec
from a web form submission to a live outbound conversation: ~2 min
client workspaces on one codebase: 5

The problem

Four businesses in four sectors described the same problem to me in four vocabularies. A home survey firm was buying Meta and Google leads and letting them sit in a CRM overnight. A mortgage protection brokerage had a list of past clients nobody had time to ring. An agency wanted to follow up its own enquiries without hiring a coordinator. In every case the work was not hard, it was just relentless: answer within minutes, ask the same eight questions, offer a time, write it down, chase the ones who go quiet. Nobody does that reliably at 3am, and the first company to actually speak to somebody usually gets the job.

What I built

BookerBot is one codebase serving all of them. Each client is a workspace with its own prompt contract, its own qualifying fields, and its own workflows, editable by the client without a deploy. Inbound arrives on the phone, SMS or WhatsApp and is answered on the channel it came in on, with an automatic fall back to SMS when a WhatsApp send fails. Outbound is a sequenced workflow rather than a blast: steps with delays between them, parked outside business hours, suppressed the moment the contact replies, and each step can be a message or an actual phone call the agent places itself. Six cron jobs run the machinery, the fastest every two minutes, polling the website forms and the CRMs and moving every waiting contact one step forward. Mid-conversation the agent can check a live calendar and book into it, and it hands over to a named human the moment the conversation is outside what its contract allows.

What it looks like

A contact record showing a long WhatsApp thread between an inbound enquiry and the AI receptionist, with a timestamp and a token cost on every message. — One enquiry, start to finish. It opens the thread, works out the caller needs an EPC rather than a full retrofit survey, learns the loft was already done in 2019 and adjusts, offers two real slots and books one. Look at the gap between an inbound message and the reply under it: single digits. The median across every inbound message in production is 8 seconds. Each message also carries what it cost to generate, because a system whose unit economics you cannot see is a system you cannot price.

The live Alexander Hall demo: a chat in which the AI declines to quote a life cover premium, beside a panel listing four hard-coded compliance guardrails. — The tenant that changed how I build these. Alexander Hall is FCA-regulated, so the agent may not advise, quote a premium, or ask for bank details, and here it is refusing a direct request for a figure and routing to a human adviser instead. This frame is the real product, not fixtures: it is the public demo, live, and you can push on it yourself.

The receptionist configuration screen: an editable system prompt covering identity, personality and hard rules, above a table of eight fields the agent must capture. — The prompt contract, editable by the client rather than by me. The top half is who the agent is and what it must never do. The bottom half is the eight things it has to come away with, each one individually markable as required, which is what turns a chat into a qualified lead. Nothing on this screen needs a deploy. That matters more than it sounds, because the fastest way to kill one of these projects is to make every wording change a ticket.

The call handling screen: five configured objection handlers, each pairing a customer objection with the agent’s scripted response, above free-text routing instructions. — Five objections and what to say to each, written in the words the office already uses on the phone. "How much is it?" gets a real answer with a real caveat. "I need to think" gets an offer to follow up, not a push. Underneath, routing: who a call goes to and when, in plain English rather than a rules engine. This screen is the part of the job that is not engineering. It is sitting with the people who currently answer the phone and writing down what they actually say.

The call log with one call expanded, showing a turn-by-turn voice transcript, a written summary, the captured fields, a sentiment read and the duration. — The voice side. Every call is kept as a full transcript plus a summary, the fields it captured, and a sentiment read. The transcript exists so that when the office says "it got that wrong", there is a specific line to point at. Most of the refinements on this product came out of reading these, including keyterm prompting for Scottish first names so the transcriber renders Barry as Barry.

Shots marked data substituted are the real interface with invented content in place of the client’s. Every name, address, sum of money and email on those screens is made up. The layout, the components and the behaviour are exactly what the client uses.

What happened

Measured end to end against the live systems: a form submission at 12:02:44 became a live outbound conversation at 12:04:32. Once a thread is open the agent answers fast enough that nobody experiences it as a queue, a median of 8 seconds from an inbound message to its reply, with nine in ten under 12 seconds. Across seven months in production it has handled 923 messages over SMS and WhatsApp for 251 contacts, and placed 67 completed AI phone calls to 57 people. For the surveying client, in the sample week I reported on, 14 enquiries produced 8 appointments and £19,731 of quoted work. The pipeline has run continuously since, including through a stretch where it correctly proved the leads had stopped arriving upstream, on the ad side, rather than being dropped by the system. The hardest workspace to sign off was the FCA-regulated brokerage: it is fenced so the agent cannot advise, quote a premium or ask for bank details, and that fence is written into the prompt contract and tested rather than trusted.

Next.jsSupabaseTwilio (SMS / WhatsApp / voice)VapiGoogle CalendarWix + Reonic APIsVercel cron

Provenance: Message, contact, workspace and voice-call counts measured 2026-08-12 against the live BookerBot Supabase project: 923 rows in messages (19 Jan to 11 Aug 2026), 251 contacts, 5 rows in clients, 15 workflows, and 67 successful voice_call steps to 57 distinct contacts in contacts.step_history (18 Mar to 4 Jun 2026). Channel behaviour, cron cadence and booking tools read from the production source. Response latency measured 2026-08-11 over the full messages table. Speed-to-lead trace measured 2026-07-08 against the live Wix, BookerBot and Reonic systems. Funnel figures from the weekly report for w/e 5 Apr 2026.

Want the same thing done to your operation?

Ten working days, a fixed fee, and one automation live before we finish. If there is nothing worth automating, I will say so in the findings.

Book a call