Build it when
The logic is specific to your operation and no product models it, an engineer will still be here next year, or the system has to live inside infrastructure a vendor cannot reach.
THE DIY ROUTE, COSTED
Build your own AI receptionist with n8n, Make or a voice API
The demo takes an afternoon. A workflow tool, a model and a messaging or voice API will answer a question convincingly on the first try. What turns that into a receptionist is conversation state, real availability, handover, escalation rules and someone on call, and that is the part that takes months.
Send your website. See Elily answer as your business.
The short version
- Workflow tools give you plumbing. They do not give you your prices, your calendar rules or your handover.
- A conversation is not a workflow run. State is the first thing you will have to build yourself.
- Live calendar availability, not the model, is what makes a booking real.
- Build when the logic is genuinely yours. Buy when the job is answering customers.
What each building block is for
These tools change often, so this says what each category is for rather than what any of them currently costs or supports. Check the vendor for anything you are relying on.
| Building block | What it is for | What it does not give you |
|---|---|---|
| Workflow automation (n8n, Make, Zapier) | Wiring systems together: receive an event, call an API, write a record, send a message. | Conversation memory, your business content, availability rules, escalation. |
| Voice AI platforms (for example Vapi, ElevenLabs) | Speech: answering a call, speaking naturally, turning speech into text and back. | What to say, your prices, your diary, and the decision to fetch a person. |
| Model APIs | Understanding an unstructured question and drafting a reply. | Facts about your business. A model with no grounded content invents confidently. |
| Messaging APIs (WhatsApp Cloud API) | Sending and receiving on the customer's channel. | Everything above the transport layer. |
| Agent starters on GitHub | A head start on structure, and a way to see how other people solved it. | Support, maintenance, and any guarantee that it matches how your business works. |
What you still have to build after the demo works
None of this is exotic. It is simply the difference between a demo and a receptionist.
- Conversation state, so a customer who replies two hours later is not starting again.
- Grounding, so the model answers from your prices and hours rather than from a plausible guess.
- A content update path a non-technical person can use when a price changes.
- Live calendar reads, with time zones, buffers and a defence against two people taking one slot.
- Write-back for bookings, plus reschedules and cancellations that update rather than duplicate.
- Escalation rules, and a handover that carries the conversation to the person taking over.
- Message templates submitted and approved, for anything sent outside the 24-hour window.
- Logging you can search when a customer says it told them something odd.
- Rate limiting and retries, because delivery is not guaranteed to arrive once.
- Monitoring, alerting and someone who answers the alert at nine on a Saturday.
A realistic build order
If you are doing it anyway, this order finds the expensive problems earliest.
-
Write the business content first
Services, prices, hours, policies, the things you do not do. If this is not written down, no tooling will save the project.
-
Prove grounding before anything else
Get the model answering from your content, and try hard to make it invent something. If you cannot stop it inventing, stop here.
-
Add the channel
Webhook, verification, sending, receiving. Straightforward, and it is not where the risk lives.
-
Add state
Decide how a conversation is identified, stored and resumed. Get this wrong and everything above it feels broken.
-
Add the calendar
Reads before writes. Offer only slots you can honour, and handle two people asking at once.
-
Add escalation and monitoring last
Then run it against real messages for a fortnight before it touches a customer.
The maintenance nobody budgets
Platform APIs deprecate versions on their own schedule. Message template categories and policies change. Models are updated and behaviour shifts underneath you. A price changes in the shop and nobody updates the content store, so the receptionist quotes last season's figure for a month.
None of these are catastrophes on their own. Together they are a standing commitment of somebody's attention, indefinitely, for a system whose entire purpose is to stop needing attention.
That is the real build-versus-buy question. Not can we build it, which for most competent teams is yes, but do we want to own it in eighteen months.
The honest recommendation
Buy it when
The job is answering customers, quoting published prices and booking appointments. That problem is solved, and rebuilding it is a hobby with an invoice attached.
Benchmark your build against something finished
Before you scope it, send Elily your website link on WhatsApp. Half an hour with a working version is the cheapest requirements exercise available.
QUESTIONS BEFORE YOU START
Common questions
Can I build an AI receptionist with n8n?
You can build the plumbing: receive a message, call a model, send a reply, write a record. What n8n does not give you is conversation state, grounded business content, live calendar rules or a handover path, and those are what make it a receptionist rather than a demo.
Is there a template or workflow I can just import?
There are many starting points, and they are genuinely useful for seeing the shape of it. Treat them as a sketch: none of them know your services, your diary rules or when you want a human to take over, and that is most of the work.
How long does building one take?
A convincing demo takes an afternoon. Something you would let talk to customers unsupervised, with state, availability, escalation and monitoring, is measured in months and then never quite finishes, because the platforms keep moving.
What is the most common reason DIY builds fail?
Two, usually. The model invents an answer because nothing grounded it in the business's real content, or the booking is offered without checking live availability. Both destroy trust faster than no automation at all.
KEEP READING
Where this goes next
THE NEXT MESSAGE CAN BE HERS
Cost the build against a working version.
Send Elily your website link on WhatsApp. Seeing the finished behaviour is the fastest way to decide which parts are worth owning.
Scan to open the live chat
Last updated