AI assistants and chatbots
An assistant that answers from your data, not from guesses.
Retrieval over your own catalogue, docs or policies, with handoff to a human and a record of what was said. Deployed into the storefront, the help centre or a messaging channel.
Project pricing
From $2,000
That covers one assistant on one channel, answering from a single source of truth, with handoff to a human. More channels, order lookups and a multilingual corpus run to $8,500.
Send the brief and get a number back.
Describe the projectThe bot answers confidently and it is wrong
The assistant was installed to take load off support. It answers instantly, which is the problem: it invents a returns window that does not exist, quotes a price that changed in spring, and promises delivery to a country you do not ship to. Support now handles the original tickets plus the ones the bot created. Meanwhile nobody can see what it actually said, because there is no transcript worth reading, and nobody can tell it to stop talking about a topic, because it was never given a source of truth in the first place.
What gets built
Answers grounded in your own material
The catalogue, the policies, the help articles, indexed and kept in sync. The assistant answers from retrieved passages and cites them, so an answer can be checked rather than believed.
A scope it actually respects
Out of scope questions get a short honest answer and a route to a human, instead of a fluent guess. What counts as out of scope is a list you approve, not a mood of the model.
Handoff and a record
A path to a person with the conversation attached, so the customer does not repeat themselves. Every conversation stored and searchable, so you can read what the assistant said last week and fix the source rather than the wording.
Why it is built this way
Grounding is a business control, not a technique
An assistant that answers from retrieved documents can be corrected by editing a document. One that answers from the model can only be corrected by argument. The first is a support process; the second is a permanent risk.
Escalation is a feature, not a failure
The value is in the questions the assistant closes, not in the ones it refuses to let go. A quick, clean handoff on the hard ten percent is what keeps customers trusting the easy ninety.
How it runs
A read of what customers actually ask, taken from your existing tickets rather than imagined, and split into what an assistant should answer, what it should hand over, and what it must never touch.
The source of truth assembled: which documents, which catalogue fields, who owns them and how they get updated. Nothing is answered from material nobody maintains.
The assistant built with retrieval, citation and a scope list, and tested against the real questions from the first step before anyone sees it.
Deployment on one channel first, with the handoff wired to where your team already works, and a transcript view they can search.
Two weeks of reading transcripts together, then a round of corrections at the source. This is where the accuracy comes from, and it is planned rather than hoped for.
Background
Why most store assistants disappoint
The failure is usually the corpus, not the model
Assistants go wrong on stale returns policies, prices that changed, and shipping rules that live in somebody's head. The model is doing exactly what it was asked with the material it was given, and no amount of prompt work fixes a document nobody has updated since launch.
Citations turn a black box into a process
When an answer points at the passage it came from, a wrong answer becomes a ticket against a document. Support can fix it in minutes, without a developer, and the fix holds for every future conversation.
Scope is what customers actually judge
People forgive an assistant that says it does not know and fetches a human. They do not forgive one that sounds certain and costs them a delivery. Deciding in advance what it will not discuss is the single cheapest quality improvement available.
Transcripts are the roadmap
The questions customers ask an assistant are a cleaner signal than a survey: unprompted, in their own words, at the moment of intent. Reading a fortnight of them usually rewrites the plan for the site as much as for the bot.
Related services
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
Assistants, asked and answered
It can, which is why it is built to answer only from retrieved material and to say plainly when it has nothing. The remaining risk is a correct-sounding answer drawn from an outdated document, and that is handled by owning the documents rather than by tuning the model.
Yes, through your own API, with identity checked first and the tool limited to what that customer may see. It is the part to get right slowly: an assistant that can read order data can also leak it if the scoping is careless.
Whichever one your customers already use most, usually the storefront or the help centre. One channel done properly beats three half-wired, and the second is cheap once the retrieval layer exists.
As many as your source material covers. The limit is not the model, it is whether the policies and the catalogue exist in that language; otherwise the assistant translates on the fly and quietly loses the details that matter.
Per conversation, and it is measured during the build rather than estimated after. Retrieval keeps prompts small, caching handles the repeated questions, and a daily cap stops a bad script or a bot from turning traffic into a bill.