AI chatbot & automation
A chatbot that knows when to stop
A useful assistant on a website answers the handful of questions people ask over and over, in the visitor’s own words, at eleven at night — and hands over to a person the moment it is out of its depth. A bad one invents a policy you do not have. The difference is scope, retrieval and a handover rule, and that is most of what this service is.
- Answers from
- Your content only
- Escalation
- A human handover rule, always
- Logging
- Every transcript, reviewed
- Starting at
- $1,600
The problem
Most website chatbots make things worse
Two failure modes, both common. The first is the scripted widget: a decision tree with six buttons, none of which is the thing the visitor wanted, and a dead end at the bottom. People learn to close it on sight.
The second is newer and more expensive. A general-purpose model is pointed at your website, answers confidently from whatever it has absorbed, and eventually describes a refund window, a lead time or a price that is not yours. A written answer on your own site reads as a commitment: in 2024 a Canadian tribunal held an airline to a bereavement-fare policy its own chatbot had described to a customer.
The fix is not a better model. It is a narrower job — answer from your content, show where the answer came from, say “I do not know” without embarrassment, and put a person in front of anything consequential.
Where an assistant genuinely helps
- The same ten questions arrive every week and someone answers each one by hand
- Your service detail is good but nobody can find the right page
- Enquiries arrive outside business hours and go cold by morning
- A person asks the same qualifying questions on every call before it is worth having
- People leave the pricing and service pages without ever asking anything
- There is a support inbox with a real backlog and no appetite to hire for it
What is included
What we actually build
An assistant is a small amount of model and a large amount of plumbing, scope and testing. Most of this list is the plumbing.
A retrieval layer over your content
- Your pages, documents and FAQs indexed as the only source the assistant may answer from
- Content chunked so answers come back with their context intact
- A source link with every answer, so a visitor can verify it
- A re-index that runs when content changes, rather than a snapshot that silently goes stale
- Anything out of date excluded on purpose rather than by accident
Scope and refusal rules
- A written list of what the assistant answers and what it declines
- Refusals that offer the next step instead of a dead end
- Pricing, legal, medical, contractual and complaint topics routed to a person by rule
- No negotiating, no commitments, no invented policy — instructed and then tested
- A fixed answer for “am I talking to a human”, because people ask
Human handover
- A visible route to a person on every screen, not buried after three failed attempts
- Handover that carries the transcript, so nobody has to repeat themselves
- Routing to email, a form or your inbox tool depending on the hour
- Honest expectations shown: when a reply will come, and from where
- An out-of-hours path that captures the enquiry properly instead of promising an instant answer
Front end and accessibility
- A real dialog: keyboard operable, labelled, announced to screen readers, with focus returned on close
- Loaded after the page is interactive, with space reserved so nothing shifts
- Visible focus states and a close control that genuinely closes it
- A mobile layout that does not cover the content or the call button
- A page that still works normally when the service behind the widget is down
Logging and review
- Every conversation stored and searchable, with a retention period you choose
- A weekly read of what people actually asked, not what we assumed they would ask
- Unanswered and escalated questions turned into fixes on the website itself
- Flagged answers reviewed by a person rather than closed automatically
- A monthly summary: volume, handover rate, and the top unmet questions
Privacy and data handling
- A privacy notice covering the assistant specifically, in plain language
- Personal data minimised in prompts, with a documented retention and deletion path
- Clear disclosure that the visitor is talking to an automated assistant
- Provider account and API keys in your name, with a spend limit set
- A written record of which provider processes the data, and where
The honest limits
What an assistant on your site cannot do
Every item here is a constraint we design around rather than a problem waiting for a better model. If a vendor tells you otherwise, ask which of these they claim to have solved.
It cannot know anything you have not written down
Retrieval answers from your content. If the lead time, the exclusion or the exception lives in somebody’s head or in an email thread, the assistant does not have it and must not guess at it. The first stretch of a project like this is usually content work, not model work.
- The question list exposes the gaps in your own documentation
- Undocumented topics stay on the refusal list until they are written
- Writing those answers properly improves the site whether or not the assistant ships
It will be wrong sometimes, so design for being wrong
Grounding answers in your own content reduces fabrication substantially. It does not eliminate it, and a confident wrong answer about a price or a policy is the most expensive failure available here. So the consequential topics never reach the model at all.
- Pricing, contractual and legal questions routed to a person by rule
- A source link on every answer, so a visitor can check it
- A standing instruction to decline rather than infer
- Transcripts reviewed, and a way for a visitor to flag an answer
It cannot replace your support team
It can take the repetitive top of the queue — hours, scope, process, which page explains this, where is my thing. Judgement, apology, negotiation and anything where the customer is already upset need a person, and routing those to a bot damages the relationship faster than a slow reply does.
- Handover offered early, not after three failed attempts
- Signals of frustration escalate rather than retry
- Complaints always go to a human, first time
- No automated apology for something nobody has investigated yet
Attributing value is harder than the demo suggests
The measures that hold up are conversation volume, handover rate, the proportion of questions answered from your own content, and out-of-hours enquiries captured. Attributing revenue to an assistant is mostly guesswork, and we would rather report four things we can count than one we cannot.
- Handover rate read as a quality signal, not as a failure count
- The unanswered-question list as the main improvement input
- Out-of-hours enquiries captured, counted plainly
- No revenue attribution we cannot evidence
A chat widget has real costs on your page
Third-party widgets are a common cause of layout shift, delayed interactivity and keyboard traps. We hold the assistant to the same performance and accessibility budget as the rest of the site, which sometimes means building the widget rather than embedding somebody else’s.
- Loaded after the page is interactive, with reserved space so nothing jumps
- Tested as a dialog for keyboard and screen-reader use, including focus return
- No blocking script in the critical path
- Measured against the same Lighthouse ≥ 95 target as every page we ship
It is a system you now own
There is a provider account, an API key, a spend limit, a retention policy and a privacy notice. Models are deprecated and replaced on the provider’s schedule rather than yours, and a prompt that behaved well on one version needs re-testing on the next.
- Provider account and keys in your name, with a spend cap
- A documented retention and deletion policy
- A re-test checklist for when the underlying model changes
- A switch that removes the widget without needing a deployment
Our process
How we narrow it down
The work is mostly subtraction. A narrow assistant that is right beats a broad one that is merely plausible.
Understand needs
Read the last few hundred questions
Your inbox, your chat history, your call notes. What people actually ask, in their words, with rough frequencies. That list decides whether this is worth building at all, and it doubles as the test set later.
You get: A ranked question list and a build or do-not-build recommendation
Strategize
Draw the boundary
Which questions the assistant answers, which it hands over, and what it says when it does not know. We write the refusals before the answers, because the refusals are the part that protects you.
You get: Written scope, refusal rules and handover design
Create & build
Build it, then try to break it
Retrieval over your content, the widget, the handover path — then adversarial testing: contradictory questions, pressure for a discount, prompt-injection attempts, and the things an annoyed customer types in capitals.
You get: A tested assistant, plus the failure log from testing
Optimize & grow
Read the transcripts, fix the website
The most valuable output is usually not the automation. It is the list of questions your website failed to answer, which we then fix on the pages themselves so fewer people need to ask at all.
You get: Monthly transcript review and the resulting content fixes
Honest scoping
When a chatbot helps — and when it annoys
Worth building if
- A clear set of repeated questions exists and you can show them to us
- Your content is good enough to answer from; retrieval cannot invent what you never wrote
- Somebody will read the transcripts monthly and act on them
- You are comfortable with an assistant that says “I do not know” and passes over
- Enquiry volume outside office hours is real and currently wasted
Not worth it if
- Enquiry volume is low. A visible phone number and a fast reply beat an assistant at small scale
- You want it to replace support staff. It reduces repetitive load; it does not absorb a team’s judgement
- The answers depend on account context you are not willing to connect — generic replies will frustrate people
- The questions are genuinely all different, which means there is nothing to automate
- You want it to sell, negotiate or commit to anything. That is a liability, not a feature
One more thing. We have talked more clients out of this service than any other on this site. Where the honest answer is a clearer contact page, fewer form fields and a stated response time, that is what we will quote for.
Questions
Before you ask us
The things people ask about AI Chatbot & Automation before they get in touch. If yours is not here, ask directly — you will get a straight answer rather than a brochure.
Ask a questionWill it make things up?
It can, which is exactly why it is built not to. Answers come from a retrieval layer over your own content with source links attached, the instructions tell it to decline rather than infer, and the topics where a wrong answer costs real money — pricing, contracts, anything legal or medical — are routed to a person by rule instead of being answered. We also test adversarially before launch and read transcripts after. Nobody can promise zero wrong answers; what we can do is make the wrong ones cheap.
Can it replace a support person?
No. It reduces repetitive volume — hours, scope, process, where to find something — which can be a large share of an inbox. What it cannot do is exercise judgement, apologise credibly, negotiate, or handle a customer who is already unhappy. Those get handed over, early. An assistant sold as a headcount replacement is being sold dishonestly.
Which model or provider do you use?
Whichever fits the task, the budget and your data requirements, in an account held in your name so you are not renting access through us. The architecture matters more than the model: retrieval over your content, a narrow scope, a handover rule and logging. Those survive the underlying model being replaced, which it will be.
What happens to the conversations and the data?
Transcripts are stored where you choose, with a retention period you set and a documented deletion path. We minimise personal data in prompts, disclose plainly that the visitor is talking to an automated assistant, and add a privacy notice covering it specifically. Which provider processes the data, and where, is written down rather than assumed.
Will it slow down my site?
Not if it is built properly, and this is a genuine risk with off-the-shelf widgets. The assistant loads after the page is interactive, with space reserved so nothing shifts, and no blocking script in the critical path. It is held to the same budget as everything else we ship — Lighthouse ≥ 95 — and tested as a dialog for keyboard and screen-reader use.
What does it cost to build and to run?
A build starts at $1,600. On top of that there are provider usage costs, which depend on conversation volume and are paid through your own account with a spend cap set, plus an optional monthly retainer if you want us reading the transcripts and feeding the gaps back into the site. All three numbers go in the proposal rather than arriving later.
Please note. Automated assistants are a fast-moving area and the rules around them are still settling: disclosure expectations and the treatment of what an assistant says on your behalf vary by jurisdiction and are changing. We build to disclose plainly and to keep consequential topics with a human, but we are not lawyers — anything with regulatory exposure should be reviewed by yours.
Send us the ten questions you answer most
Paste in the questions your team answers over and over. We will tell you which an assistant should handle, which should simply become a better page on your website, and whether the whole thing is worth building yet.