Where AI assistants help, and where they are just cost
Over the past two years almost every business has been asked whether it wants an AI assistant. Some of those projects are money out the window, and some are among the most useful things you can do with a software budget. The difference is predictable, and it has little to do with which model you pick.
The test
An AI assistant is worth it when there are many questions with few distinct answers.
If your customers ask hundreds of questions a month and those boil down to fifteen topics with clear answers, an assistant will do real work. If every question is a separate case requiring judgement, the assistant will sound confident and be wrong, and the mistake will carry your name.
Count before you decide. A month of enquiries, sorted into piles. The size of the biggest piles is the case for the assistant; the number of piles is the case against it.
The front door, revisited
The usual impulse is to put the chatbot on the landing page so it can "absorb" all enquiries. That is the place where it has the least context and the most ways to be wrong, and we have said so before.
We have since built one that sits on a clinic's public website and works. It is worth being precise about why, because the reason is not the model. It is that the assistant knows almost nothing on its own. Its prices come from the same records the price page renders, so a promotion switched on in the admin panel changes the page and the assistant in one move. Its clinical answers are an FAQ the lead doctor approved word for word, which it may quote and may not rephrase. It can check free appointment slots and open the booking form pre-filled, because those are tools it calls, not facts it remembers. And it has rules it cannot argue with: never claim what a price includes, put the phone number in the first sentence of any emergency answer, offer a human whenever unsure.
The other half is a gate. Before every release, a script runs a fixed set of real patient questions through the real prompt and the real tools, prints every answer, and flags any that was cut short. It has earned its keep twice. Once, a promotion toggled in the panel moved a price on the page while the assistant kept quoting the old one from a paragraph somebody had typed months earlier; the fix was to generate that paragraph from the data instead of maintaining it by hand. Another time, the answer to "I have a toothache, what do I do" was being truncated by the model's output budget, right before the phone number. Both would have been found by a patient otherwise.
So the front-door rule stands, with a correction: an assistant at the front door is a mistake when it improvises. It earns its place when it is a narrow, grounded interface to facts you already maintain, with a person one sentence away.
Internal uses are underrated
The most reliable return is often where no customer is looking: searching internal documentation, summarising long threads, filling in drafts from a template, classifying incoming enquiries before a person looks at them.
These tasks share one property: somebody checks the result before it reaches a customer. That changes the cost of a mistake at its foundations, and it is why internal uses make a good first step.
Our own receipt-scanning app is built on that property, even though it is customer-facing. The model reads the receipt; the person confirms the lines before they enter the budget, and the model learns from what they change. The check is part of the product, not an afterthought, and it is what makes an imperfect reading acceptable.
Four questions before you build
- Volume and shape. Many questions, few distinct answers? If not, fix the process and write the FAQ. The assistant would only sound confident.
- Its facts. Will it read your prices, hours, availability and policies from the live source, or from a paragraph someone typed once? If the source does not exist yet, build that first. The assistant is the last ten per cent.
- Who checks. Does a person see the answer before a customer does? If yes, start there; the mistakes are cheapest and the return fastest.
- Customer-facing, then. A narrow list of what it answers and a refusal for the rest, a hand-off with a phone number, a test set run before every release, and a line in your privacy policy.
What it costs to run
The bill is the question people forget to ask until the second month. Two decisions shape it more than the model's price list. Where the model runs: in our budgeting app the free plan runs a small model in the user's own browser, against the provider's free tier, so a free user costs nothing per scan; paid plans use a larger model on our server. And what gets cached: a live price lookup that a hundred households ask for in the same day is one search, kept for 24 hours, not a hundred.
Neither is clever. Both are the difference between a feature and a liability.
What to settle before you build
Before development it is worth having an answer to three questions: which questions the assistant will not take, what the handover to a human looks like, and what happens when it does not know. An assistant that says "I do not know, let me put you through to a colleague" is a better product than one that always has an answer.
And one thing that often gets missed: if the assistant processes user data, that belongs in your privacy policy. Not as a formality, as a requirement.
In short
Ask not "can we add AI" but "which repeated question costs us the most time". If the answer is specific, there is something to build, and the work is mostly in the facts it will read and the gate it has to pass, not in the chat window. If the answer is not specific, wait.
Have a question like that on repeat? Tell us about it.