A Pre-Incident Briefing for Support Staff on AI Features

Session one exists to stop the two most expensive misreadings of AI: attributing intent to the model and attributing reliability to it. Agents who believe the model is "lying" escalate differently than agents who understand it produced a plausible but unsupported number.

Open with the limits sheet (below) and read the right-hand column aloud. Then run two seeded scenarios.

Scenario A: "The model gave a customer a wrong refund amount, what do you say?" Let agents draft an answer in pairs for four minutes, then collect two drafts and mark them against the approved-wording rules from session three. The point is not that they get it right; it is that they discover the gap between an apology that owns the error and one that blames "the system."

Scenario B: "A customer asks whether they are talking to a person or an AI. What do you say?" This is a disclosure question dressed as a technical one. Rehearse a plain answer and a redirect if the customer becomes upset.

Close with a capability drill. Give each agent three real tickets from the past month and ask: for each one, would you trust a model draft, verify every number, or refuse to let a model touch it? Record the answers on a whiteboard. Disagreements are the curriculum.

Facilitators should follow the tabletop discipline of separating discussion from operational control, the principle Google's SRE guidance applies to incidents, as summarized in Webalert's status update templates: one person runs the session and keeps the notes while participants talk. Do not let the session turn into a tool demo.

Session two is the one with legal and privacy exposure behind it, and it should be treated as mandatory for any agent with inbox access.

Start with the question agents actually type into chat: "Can I paste this account number into the chat?" Then work through a three-bucket exercise. Put a stack of realistic ticket excerpts on the table and have agents sort each into: paste as-is, redact first, or never paste. Examples worth including: a partial account number, a full account number, a customer's email address, a screenshot of a billing page, a password reset link, and a full chat transcript containing a third party's details.

The supporting principle is permissions-aware design. Glean's overview of privacy concerns with customer data in AI argues that access control and audit trails should be built into AI workflows from the start rather than bolted on, and that limited data collection and retention policies reduce exposure. Agents do not need the full legal rationale, but they do need to know that anything pasted may leave the boundary of the system of record.

Then walk through where logs go. Draw the path on a whiteboard: prompt, model response, the tool or console that recorded it, the retention period, and who can retrieve it. If your team cannot draw that path, that is the finding of session two, and it belongs in the limits sheet as an open item with an owner.

Close with a redaction drill under time pressure. Give agents 90 seconds to rewrite a messy ticket into something safe to paste, then compare versions. Reward aggressive redaction, not elegance.

Wording is where support teams most often improvise and most often regret it. Gorgias's catalog of customer service phrases lists the ones to avoid, including "I apologize for any inconvenience," "that's our policy" and a flat "no, I can't do that." Those phrases feel safe to write and read as dismissive to a customer who has just been given a wrong number by a machine.

Session three should produce three short scripts, each under 60 words, agreed by the room and approved by whoever owns customer communications.

Apology script for a model error: name what happened, name the correction, name the next step, give a timestamp. Indeed's roundup of customer service email response samples recommends reading the query fully, being specific, offering a solution and thanking the customer, which maps cleanly onto a model-error apology.

Escalation script for anything touching money or identity: state what is being escalated, to whom, and when the customer will hear back. Keep the estimate conservative. Status page practice is instructive here: better to give a conservative estimate or none than one you cannot meet, per OpenStatus's status page best practices.

Refusal script for requests the model or the agent cannot fulfill: say what you cannot do, say what you can do instead, and stop. Helply's analysis of auto-reply templates makes the related point that one fallback channel beats three, because three options produce no decision. The same applies to refusals: offer one alternative.

Run the word-for-word test before adjourning. Each agent reads one script aloud to a partner who plays an angry customer. Scripts that sound robotic get rewritten on the spot. Atlassian's guidance on incident communication stresses that message templates and update cadence must be decided in advance, not improvised during an incident, and that a zero-tolerance communication plan should apply to anything involving security issues or data loss.

The limits sheet is a single page, one row per limit, each row carrying a source. Without the source column it becomes opinion and agents stop trusting it. Use a named owner and a review date per row.

Keep the sheet to eight rows or fewer. If a limit needs a paragraph, it belongs in the playbook, not on the sheet.

The value of a briefing comes from the questions, not the slides. Seed each session with four to six questions, give agents two minutes to answer in pairs, and then compare answers rather than announcing the official one.

Session one:

• The model gave a customer a wrong refund amount, what do you say?
• A customer says "you're a robot, aren't you?" What do you say?
• The model says a fee is waived. Do you honor it?
• The model gave two different answers to the same question. Which one is wrong?

Session two:

• Can I paste this account number into the chat?
• A customer sends a screenshot with their card on it. Can you forward it?
• Where does this conversation get stored, and who can read it?
• A colleague asks you to paste a transcript into a personal AI tool. What do you do?

Session three:

• A customer demands compensation for a model error. What do you say first?
• How do you end a conversation where you refused a request?
• What is the one sentence you will never say again after today?

The last question is the strongest close. It converts the session into a commitment and gives you a list of banned phrases for the next cohort.

Run sessions on a repeating cadence, not once. New agents need all three within their first two weeks. Existing agents should repeat session three at least once a quarter, because approved wording drifts.

Practical constraints to plan around:

• Cap sessions at 15 participants so everyone speaks.
• Schedule across shifts; a session only day staff can attend will not reach the people handling evening escalations.
• Record the seeded scenarios, not the slides, so new hires can replay them.
• Keep a one-page record per session: date, attendees, questions that exposed disagreement, and open items added to the limits sheet.

Measure three things: the number of disagreements surfaced per session (a session with zero disagreements was not seeded hard enough), the number of limits sheet rows with a verified source, and the time from first report of a model error to a corrected script in the library. If your agents are building features themselves or you are standardizing tooling across a support org, Quanta for Teams keeps a shared credit pool and a private skill library with a key per person, which makes the redaction and logging path easier to draw on the whiteboard in session two.

When the limits sheet keeps growing faster than your team can verify it, that is a signal to bring someone in rather than write faster. A free 30-minute discovery call with an AI expert is a reasonable place to sort out which limits are real and which are folklore.