What the assistant may say, and who decides

The objection to writing this down is that everybody already knows. They do not, and the proof is that when a wrong answer appears, the conversation immediately becomes about who was supposed to have caught it. That conversation is what the page prevents.

It also survives people. The person who set the assistant up will eventually hand it to somebody else, and everything not written down goes with them: which documents were deliberately excluded and why, which topics were ruled out after a discussion, what the refusal wording was carefully phrased to avoid. Their successor will reasonably assume those were oversights and fix them.

Keep it to a page. A long policy is a policy nobody reads, and this one has to be readable by somebody joining the team in a year. Five short sections, each answering one question, is the right size, and anything that does not fit is probably a procedure rather than a policy.

List the categories of thing the assistant may assert on its own, and be specific enough that somebody can apply it without asking. Published prices. Opening hours. Delivery timescales as published. The steps in a documented process. What is included in a named service.

The useful test to write into this section: could a new member of staff say this from a printed page in front of them, without checking anything and without judgement. If yes, the assistant can say it. If it requires looking something up in a system, or forming a view about a particular customer, it cannot, because the assistant can do neither.

Then name what is out even though it looks factual. Anything about a specific customer's account, order or history. Anything requiring a live lookup, since an assistant that cannot query a system must never appear to have done so. Anything that varies by case, where the published version is a typical figure rather than a commitment. This last category causes more real problems than the obvious exclusions, because the material genuinely contains a number and the number is genuinely published.

This is the escalation list, written out with a reason beside each entry. Requests for a person. Complaints. Legal threats. Anything medical if you are anywhere near health. Fraud reports. Bereavement. Distress. Plus whatever your specific trade adds, which is usually the most important part of the list and the part nobody outside your business could have written for you.

Record the reason next to each one, in a single line. Six months on somebody will look at an entry, see it firing on questions that could have been handled, and remove it as over-caution. The line explaining why it exists is what stops that, and writing it costs a sentence at the time.

Include the exact refusal wording in this section, not a description of it. The wording is a decision, it was probably argued over, and it is the thing most likely to be quietly rewritten by somebody tidying up settings. Pasting the actual text into the policy makes an unintended change visible.

Anything indexed becomes an answer given in your business's name. That means uploading a document is a publishing act, and it should have the same controls as publishing a page, which in most businesses means fewer people than currently have access to the console.

Name the people, by role. Then name who approves additions in the sensitive categories: anything touching price, legal terms, safety, or regulated claims. The approver does not need to be the uploader and often should not be, particularly for pricing, where the person keenest to publish a number is rarely the person accountable for it.

Write down what happens to internal documents. The most common way an assistant leaks something is that somebody uploads a handbook containing an internal note, a margin, a supplier name or a staff process, because the file was to hand and mostly relevant. A one line rule that internal documents are reviewed before indexing prevents nearly all of it, and no clever configuration does.

There has to be a route, and it has to be usable by whoever notices, which is usually a support agent mid-conversation with an annoyed customer. If reporting a wrong answer requires finding the right person and explaining the context, it will not happen, and you will learn about errors from complaints instead.

Specify four things: where a report goes, who is responsible for acting on it, what the expected turnaround is, and what happens in the meantime. That last one is the one that gets forgotten and it is a real decision: if the assistant is confidently giving out a wrong price, does somebody have the authority to remove the offending material immediately, before any discussion. Somebody should, and the policy should say who.

Record the fixes somewhere they accumulate. A short running list of what was wrong and what was changed becomes, within a few months, the most useful document you have about your own material, because the same pages fail repeatedly and the list is what makes the pattern visible.

Name one owner. Not a team, a person, because a policy owned by a team is owned by nobody and the review will not happen. The owner does not have to do the work, they have to notice when it has not been done.

Set a review date and a review trigger. The date is a backstop and the trigger is what actually matters: review this when you enter a new market, add a regulated product, change your support hours, or change who handles complaints. Each of those can invalidate a section, and none of them will land on the calendar date.

Put a date on the page itself, and put the page where the assistant's settings live rather than in a drive nobody opens. A policy that cannot be found from the console will not be read by the person about to change something in it.

One. What it may state as fact: the categories it may assert, the test for deciding a new one, and the explicit exclusions with reasons. Two. What it must refuse: the escalation list with a reason per entry, and the exact refusal and handover wording pasted in full.

Three. Who may change the material: named roles for uploading, named roles for approving anything price, legal, safety or claims related, and the rule for internal documents. Four. Wrong answers: where a report goes, who owns it, the turnaround, who may pull material immediately, and where fixes are logged.

Five. Ownership and review: the named owner, the review date, the list of events that trigger an early review, and the date this version was written. That is the whole thing. It fits on a page, it takes an hour to draft, and every argument you would otherwise have in six months is one of the five headings.