An AI website assistant needs a clear brief before it needs a personality. For a service business, its value depends on whether it helps visitors understand the right information and reach the right person. A friendly answer that invents a price, overstates availability or sends an unsuitable enquiry to the wrong team can create extra work.
Begin with the customer task. Perhaps visitors need to check whether a service covers their area, understand what to prepare for a consultation or find the appropriate enquiry route. These are more useful starting points than a broad ambition to let a chatbot answer everything about the company.
A good brief defines the permitted subjects, authoritative information, uncertainty rules, handover process and tests. It also identifies who maintains the assistant after launch. The following process helps turn a general AI idea into a bounded, reviewable website feature.
Choose a small set of useful visitor tasks
Review questions from enquiries, website research and customer service. Select tasks that have reliable answers and occur often enough to justify support. Keep the initial scope manageable, so the team can inspect how the assistant behaves across realistic variations.
Write the desired outcome for each task. For a consultation preparation question, the outcome might be that the visitor understands which documents are useful, knows that missing documents do not prevent an initial conversation and can find the correct booking route.
Distinguish an information task from a transaction. Explaining how to request a quote is different from issuing one. Showing a link to a booking page is different from making a booking or changing a customer's appointment. Each additional operation brings different integration and verification requirements.
Record excluded tasks explicitly. A public service assistant may be unable to discuss individual customer accounts, negotiate terms or confirm an engineer's current availability. These boundaries should appear in the brief and be enforced in the implementation, rather than left to a vague instruction to be careful.
Create an approved knowledge set
Identify the source for every important answer: service descriptions, geographic coverage, preparation guidance, published terms and approved contact routes. Give each source an owner and a review trigger. Do not assume that every old page or internal document is suitable for public answers.
Resolve contradictions before connecting the information. If the website says an initial consultation is free, but a document describes a charge, the assistant cannot repair that business ambiguity reliably. Agree the correct position and update the sources so staff and visitors receive consistent information.
Keep public knowledge separate from private operational information. A public website source and authenticated enterprise content have different access arrangements. Check the actual source type, authentication and retrieval controls in the chosen platform. Our knowledge access and RAG guide provides the related checks.
Ask the implementation team to demonstrate exactly which sources the assistant can retrieve and what an anonymous visitor can access. Supplying approved material can improve grounding, but it does not guarantee that every generated answer will be correct. Verification remains part of the operating process.
Specify how the assistant handles uncertainty
Define what happens when no supported answer exists. The assistant should acknowledge the information gap and offer an appropriate next step. For example, it might explain that the website does not confirm availability for a particular date and direct the visitor to the scheduling team.
Permit limited clarification when it helps choose an answer. Asking whether the visitor wants a new website or support for an existing one may be useful. Asking for extensive personal information before supplying a public service description adds friction and can exceed the feature's purpose.
Keep assumptions visible. A visitor asking about “maintenance” might mean routine website care, fixing an urgent fault or managing hosting. The assistant can offer these interpretations or ask a short question. It should not silently select one and present a confident answer to a different need.
Agree how source links appear. A concise explanation with a relevant link lets visitors inspect the full details and continue their journey. Check that links resolve to the intended public page. An impressive answer with an invented destination is still a failed interaction.
Design a handover that works outside the demo
Choose handover routes according to the question and the service team's actual availability. A sales question, an existing-customer problem and an urgent operational issue may require different routes. The assistant should not imply that a live person is available immediately when the business only offers an enquiry form.
Specify what context reaches the receiving team and how the visitor reviews it. A short summary can reduce repetition, but it must represent the visitor's request accurately. Give the visitor an opportunity to correct important details before the information becomes an enquiry.
Test the receiving process, not just the on-screen message. Confirm which inbox or system receives the request, who owns it, what confirmation the visitor sees and what happens if delivery fails. “I have passed this to the team” should correspond to a verified operation.
Keep a conventional contact route available. Some visitors will prefer email, telephone or a standard form; others may find the assistant unsuitable for their task. Ensure these options remain understandable on mobile and accessible without completing an AI conversation.
Agree the behaviour and the language
Define the tone through examples. A professional service business might want short, direct answers in British English, plain explanations of technical terms and a calm acknowledgement of uncertainty. “Be helpful and friendly” is too broad to tell a reviewer what good performance looks like.
Provide examples of acceptable and unacceptable claims. The assistant can say that a service page explains the typical project process. It should not promise a fixed completion date unless the system has a reliable, authorised way to establish that commitment for the particular enquiry.
Keep response length appropriate to the task. A coverage question may need a short answer; a preparation question may benefit from a small checklist. The assistant should help visitors reach useful information without reproducing an entire article inside a narrow chat panel.
Include language and accessibility requirements in testing. Check keyboard operation, focus behaviour, readable messages and the ability to close or reopen the feature. If additional languages are supported, review their actual answers rather than assuming that the quality is identical across translations.
Build a test set before launch
Create cases from genuine customer questions, rewritten without identifying details. Include normal wording, spelling mistakes, ambiguous phrases and questions containing incorrect assumptions. The test set should exercise the feature's boundaries as well as its most comfortable examples.
For each case, record the expected outcome rather than insisting on one exact sentence. A correct response to an unsupported price question might acknowledge the limitation and link to the quotation route. Review whether the response does that accurately and avoids making a commitment.
Include contradictory-source and missing-source cases in an appropriate test environment. Check whether the assistant invents an answer when a page is unavailable or treats quoted instructions in a document as new authority. Ask the implementation team how source and action boundaries are enforced.
Have service experts review the outputs alongside the project team. Score factual accuracy, relevance, source quality, appropriate handover and task completion. A fluent answer can fail any of these checks, so presentation should be assessed separately from correctness.
Define ownership, maintenance and success
Name the person responsible for knowledge changes, test review and operational issues. Set review triggers for new services, revised coverage, changed prices and updated contact processes. Retest the affected questions when a source or configuration changes.
Monitor useful outcomes such as supported questions answered correctly, successful contact handovers and recurring gaps that need a source update. Conversation counts alone do not show value. A long exchange may indicate interest, confusion or a task the assistant cannot finish.
Budget for ongoing checks and a straightforward way to disable the feature if necessary. Giraffe Digital's digital strategy service considers tools within the wider customer journey. A well-briefed assistant should support that journey through reliable information, clear limits and practical human follow-up.
Frequently asked questions
How should we specify how the assistant handles uncertainty?
Define what happens when no supported answer exists. The assistant should acknowledge the information gap and offer an appropriate next step. For example, it might explain that the website does not confirm availability for a particular date and direct the visitor to the scheduling team. Permit limited clarification when it helps choose an answer. Asking whether the visitor wants a new website or support for an existing one may be useful. Asking for extensive personal information before supplying a public service description adds friction and can exceed the feature's purpose. Keep assumptions visible. A visitor asking about "maintenance" might mean routine website care, fixing an urgent fault or managing hosting. The assistant can offer these interpretations or ask a short question.
How should we design a handover that works outside the demo?
Choose handover routes according to the question and the service team's actual availability. A sales question, an existing-customer problem and an urgent operational issue may require different routes. The assistant should not imply that a live person is available immediately when the business only offers an enquiry form. Specify what context reaches the receiving team and how the visitor reviews it. A short summary can reduce repetition, but it must represent the visitor's request accurately. Give the visitor an opportunity to correct important details before the information becomes an enquiry. Test the receiving process, not just the on-screen message. Confirm which inbox or system receives the request, who owns it, what confirmation the visitor sees and what happens if delivery fails. "I have passed this to the team" should correspond to a verified operation.
How should we agree the behaviour and the language?
Define the tone through examples. A professional service business might want short, direct answers in British English, plain explanations of technical terms and a calm acknowledgement of uncertainty. "Be helpful and friendly" is too broad to tell a reviewer what good performance looks like. Provide examples of acceptable and unacceptable claims. The assistant can say that a service page explains the typical project process. It should not promise a fixed completion date unless the system has a reliable, authorised way to establish that commitment for the particular enquiry. Keep response length appropriate to the task. A coverage question may need a short answer; a preparation question may benefit from a small checklist. The assistant should help visitors reach useful information without reproducing an entire article inside a narrow chat panel.
