Start with questions your customers actually ask.
“Can you come on Saturday?” may look like a simple question. One teammate answers from last month’s schedule. Another remembers an exception. An AI-written reply might confidently turn both into a promise. The missing piece is a current answer that says what is known and what still needs checking.
Start with a small set of recurring questions from your normal customer work. Record the question in plain language and the point where it comes up: before an estimate, while choosing a time, or after a job is agreed. Remove identifying details from this shared question list.
A library can begin as a reviewed document. You do not need to build an assistant to make it useful. Its first job is to help the next person find an accurate answer and recognize when that answer does not apply.
Separate general answers from decisions about one request.
Some information can be reused, such as the details needed to prepare an estimate. Other answers depend on the customer’s request, current availability or a decision by an authorized person. Keep those differences explicit.
On a small screen, swipe or scroll sideways to read the full table.
| Question type | What belongs in the library? | What still needs checking? |
|---|---|---|
| A stable process | Which details the team needs before preparing an estimate. | Whether this request has unusual requirements or an exception. |
| A changing fact | Where the responsible person checks the current information. | Today’s schedule, availability or service coverage. |
| A customer-specific decision | The person authorized to decide and what information they need. | The actual approval for this customer’s scope, price or timing. |
| A question with no approved answer | An explicit “needs review” status and the next responsible person. | The underlying fact. A plausible sentence is not enough. |
For changing facts, an instruction to check the right source is often more useful than a copied value that quickly goes stale. Keep private customer agreements separate from general information the whole team can use.
Give every answer a source and an owner.
Download the blank answer-library worksheet (CSV). Start with a few questions that repeatedly slow the team down. Use one row per answer and keep a completed copy in your approved workspace.
On a small screen, swipe or scroll sideways to read the full table.
| Field | What it prevents |
|---|---|
| Question and customer stage | Using a post-booking answer when someone is only asking about availability. |
| Approved short answer | Each teammate inventing different wording or commitments. |
| Source, source date and scope | An old general policy overriding a current, specific agreement. |
| Review owner and next review trigger | An answer surviving a change to hours, process or service boundaries. |
| Exception or reason to ask a person | A general answer being treated as authorization for every situation. |
| Status and last verified date | A draft or superseded answer being mistaken for a ready-to-use one. |
“The team says so” is a weak source. Point to the actual approved process or responsible person’s decision. If two sources disagree, record the conflict and ask the owner to resolve it before treating either answer as current.
Make the exception visible in the answer.
Fictional example: A repair business sometimes has Saturday appointments, but the office must check the current schedule before confirming one. No date has been reserved for the customer.
An overconfident answer would be: “Yes, you’re booked for Saturday.” It turns a possibility into a reservation.
Saturday appointments may be possible. Please tell us which date you have in mind; the office will check availability before confirming a time.
That wording is appropriate only if this fictional business has actually agreed that process. The library entry should identify the scheduling source, who checks it and that a requested date is not a confirmed appointment. If the business stops offering Saturdays, the answer needs revision.
Try the answer against three cases: an ordinary request, a known exception and missing information. Ask a teammate unfamiliar with the entry to explain what they would do next. If they still infer permission to promise a date, improve the boundary rather than adding more reassuring language.
Use AI to help draft, then review the result.
If your team uses an approved AI tool, supply only the information it is permitted to handle. Ask it to organize the known facts, identify gaps and suggest clear wording. A short, anonymized example is enough to practice the method.
A useful instruction is: “Draft an answer using only these approved facts. Separate anything missing into questions for the review owner. Do not invent a price, availability, approval or commitment.” This instruction helps express the task; it does not guarantee the output will follow it.
Compare the draft with the sources yourself. Use the customer-reply review guide before any wording becomes an approved answer or a message. A reviewed reference document alone does not create a working customer-facing assistant.
Maintain the answers where the team will find them.
Keep drafts, current answers and retired versions clearly separated. When an answer changes, record why, update the place the team actually uses and identify any other copy that repeats the old fact. A new document does little good if everyone keeps using an outdated saved reply.
Review entries when a relevant process changes and when a real question exposes a gap. Record what the customer asked, why the current answer failed and who will resolve it. Do not publish every internal answer as a website FAQ: customer-specific agreements, private instructions and unresolved decisions have a different audience.
A useful library earns its size. Combine questions that need the same answer. Keep separate entries when the decision or exception is genuinely different. The result should help someone act with better information, without having to guess.