Short answer. Build an AI assistant when people ask the same questions repeatedly, the answers already exist in documents you control, errors can be caught and corrected, and the time saved outweighs running costs. If any of these is missing, fix that first or start smaller.
- Repeated questions and good documents are the foundation
- Decide where the data lives before choosing a model
- Start with one narrow use and measure it
Four tests to run first
An AI assistant is useful when it answers questions from your own material. Before spending anything, run four checks.
Is the same question asked again and again? Look at your inbox, your phone log and your staff chat. If the same ten questions take up hours each week, an assistant has something to do. If every question is unique, it does not.
Do the answers already exist in writing? An assistant that retrieves from your documents is only as good as those documents. Policies, manuals, price lists and past replies work well. If the knowledge lives in one person's head, write it down first.
Can you catch mistakes? Language models can state wrong things confidently. Decide who reviews a sample of answers, how a user flags a bad one, and what happens when the assistant does not know. A good one says so and hands over to a person.
Does the saving beat the cost? Add up build time, hosting, model usage and upkeep. Compare it with the staff hours saved or the enquiries answered faster.
If you pass all four, you have a real case.
Where the data should live
Many businesses hold information they cannot send to a third party: client files, health or legal records, internal pricing. This shapes the design more than anything else.
There are broadly two options. You can call a major AI provider's service, which gives strong models with little setup, under that provider's data terms that you should read. Or you can run an open-weight model on your own servers, which keeps documents inside your own environment at the cost of managing the hardware and accepting that the model may be less capable.
Either can use retrieval, where the assistant first searches your documents for relevant passages and answers from those. Retrieval keeps answers grounded in your material and makes it possible to show the source of each answer.
Decide this early, with whoever is responsible for privacy in your organisation. It is much harder to change after launch.
Keep the first version narrow
The assistants that work well start small. Choose one audience, such as customers asking about services, or staff looking up internal procedures. Choose one body of documents. Define what it should refuse to answer.
Then launch to a small group and read the conversations. You will find gaps in your documents, questions you did not expect and wording that confuses it. Fix those, measure how many questions it resolved without a person, and only then widen it.
Connect it to the tools your team already uses rather than adding a new place to look. Connectors that let an assistant read from a calendar, a CRM or a document store are often more valuable than a cleverer model.
When not to build one
Hold off if your documents are out of date or contradict each other, if the volume of questions is low, or if a better FAQ page would do the job. A well-written FAQ also helps people find you through search and AI answers, which a private chatbot does not.
Skip it, too, if nobody will own it after launch. An assistant needs someone to update the documents and review the results.
If you are not sure, a short readiness review can answer the question before you commit. Book a strategy call and we will talk it through, or try the free AEO check to see how your public pages answer questions today.