Map questions to approved answers.
List the repeat questions within the proposed scope. For each one, identify the source, the owner and the acceptable answer. Include the qualifications that change the answer: service area, project type, customer status or an exception that needs a person. Mark missing answers explicitly.
Use real question wording where it is available without exposing private customer details. An internal document title may bear little resemblance to the way a prospective customer asks for help. The mapping should connect both forms of language.
Resolve disagreements before indexing them.
Check whether the website, sales documents and internal notes give different answers. A model should not be asked to decide which commercial promise is current. Establish the authoritative source and remove or clearly supersede conflicting material. Keep draft and historical documents outside the approved set.
- A named owner for each important service explanation.
- A clear status: approved, draft, outdated or excluded.
- A review trigger when the service or policy changes.
- An escalation answer when approved information is missing.
Separate public answers from restricted information.
Decide what the assistant may reveal and which sources it may use. Do not upload a mixed collection simply because the files are accessible to the project team. Start with public or deliberately approved non-sensitive material for a demonstration. Live access to customer-specific information requires a separate design and access review.
Document which questions must never be answered from inference. These might include unapproved commitments, individual account details or advice outside the service. The boundary needs to appear in the test cases as well as the configuration.
Make updates part of normal operations.
Name the person who can correct an answer and the person who checks the correction in the assistant. A source update is not complete until the relevant customer questions have been retested. Keep a small record of the change, the reason and the result.
For the first pilot, select a manageable source set with clear ownership. If essential answers are missing or nobody can maintain them, fix that problem before expanding the assistant. A narrow, trustworthy journey is a better starting point than broad coverage nobody can defend.
Questions before you start
Questions before you start
Can we use our public website as the first source?
Yes, for a bounded demonstration if it contains the relevant information. Public content can still be incomplete or contradictory, so it needs a focused review.
Do we need to rewrite every document?
Usually not for a narrow first journey. Prioritise the sources needed to answer its questions and establish clear ownership for those sources.
How often should we review the content?
Use service changes and observed answer failures as triggers, alongside a review cadence appropriate to the business. A fixed date alone will not catch an urgent change.