You can build something that answers customer messages convincingly in about an afternoon. Connect a language model to a messaging channel, give it a paragraph describing the business, and it will reply in fluent, friendly, plausible English. It demos beautifully.
We know, because we built Onramp — a system that answers enquiries, qualifies them and books work for service businesses over WhatsApp. The afternoon version existed early. The production version took considerably longer, and almost none of the difference was about the model.
This gap is worth understanding before you buy anything in this category, because the demo is not the product.
The customer who replies three hours later
A conversation with a business is not a conversation with a chatbot on a website. It happens over hours. Someone messages at eight in the morning, you reply, and they respond at lunchtime — from a different phone, having forgotten what they asked.
That means state. Not chat history in a browser tab, but durable, stored conversation state that survives a restart, a deployment, a customer switching devices, and a two-day gap. It has to know what has already been established, what is still outstanding, and whether the thing it is waiting for has since become irrelevant.
This is ordinary software engineering. It has nothing to do with AI, and it is where a demo becomes a system.
Doing things is different from saying things
There is a hard line between an assistant that talks and one that acts.
If it books an appointment, that appointment is real. A duplicate message must not create two bookings. A misunderstood date must not silently put someone in the wrong slot. A customer changing their mind must actually free the diary rather than leave a ghost.
The relevant discipline is idempotency: the property that the same instruction arriving twice does not cause damage twice. Networks retry. Users double-tap. Messaging platforms deliver the same webhook more than once — this is normal, documented behaviour, not an edge case. Any system that takes real-world actions and does not handle it will eventually do something embarrassing, and it will do it in front of a customer.
Knowing when to stop
The most valuable thing an automated assistant does is recognise when it should not be handling something.
A frustrated customer. A complaint. A question outside what it knows. An unusual request that is technically answerable but commercially significant. In all of these the correct behaviour is to hand over to a person, cleanly, with context — not to produce a confident answer.
This is genuinely difficult, and it is not solved by instructing a model to be careful. It needs explicit detection, defined thresholds, and a route to an actual human who has been told they are on the other end of it. A system that never escalates is not more capable; it is less safe.
The rule we work to: the assistant should be conservative in inverse proportion to how expensive it is to be wrong. Answering opening hours incorrectly is embarrassing. Quoting a price incorrectly is a contract dispute.
Knowing whether it works
"It seems to be doing well" is not a measurement, and it is what most deployments run on.
Before going live, you need to be able to answer: how often does it resolve the enquiry without a human? How often does it escalate, and is that number moving? How often does it get something factually wrong? What is the cost per conversation, and what happens to that cost at four times the volume?
That means logging every conversation in a reviewable form, sampling them regularly, and maintaining a set of test cases that run against the system whenever anything changes — including when the model provider updates the model underneath you, which they will, without asking.
Without this you are not operating a system. You are hoping.
The unglamorous list
Everything above sits on foundations that no demo shows:
- Rate limiting and cost control, so an unusual day does not produce an unusual invoice.
- Graceful degradation, so that when the model provider has an outage — and they do — the system tells people it will get back to them rather than failing silently.
- Data handling that respects the law. These conversations contain personal data. Retention, access and deletion need deciding before launch, not after an enquiry.
- Monitoring that alerts you before the client notices. If your customer is the first to tell you it is broken, you do not have monitoring.
- A way to change its behaviour without redeploying the whole system, because the business will want changes weekly at first.
None of this is exotic. It is the standard discipline of running production software, applied to a component that happens to be probabilistic.
What this means if you are buying
The uncomfortable implication is that the interesting question is not "how good is the AI?" The models available to everyone are broadly similar and improving on their own schedule. What differs enormously between suppliers is everything around the model.
Useful questions to ask:
- What happens when a customer replies two days later?
- Show me what happens when the model provider is down.
- How do you stop a duplicate message creating a duplicate booking?
- What does it do when it does not know the answer?
- How would I find out it had been getting something wrong for a week?
An honest supplier will have specific answers, and probably some scar tissue. A supplier who answers all five by talking about how advanced their AI is has built the afternoon version.
That is the part worth paying for: not the answering, which is easy now, but everything that keeps it correct when nobody is watching.
If you are weighing up automating something customer-facing, we are happy to talk through what it would actually involve — including if the answer is that it is not worth doing yet.