Fictional client — portfolio build · targets, not field results
AI-Assisted Customer Email: Verify Before You Send
Teams don't fail because they lack AI policy — they fail when a confident draft bypasses the 40 seconds of checking that would have caught it.
The Audience
Support agents using an AI draft-assistant for customer replies — plus their team lead, who runs the same lesson as a huddle with the included facilitator note.
Responsibilities
Lesson design · hallucination scenario writing · interaction logic (hotspot hunt, ladder, branching) · team guideline authoring · facilitator enablement — the moment-of-send behavior is the deliverable.
The Build
Branching scenario design · hotspot interaction · Verify-ladder framework · guideline writing with war-story citations · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted hallucination-failure email variants for the branching send decision; the Verify ladder, hotspot design and scoring were hand-built. Drafts were checked and rewritten — the lesson itself teaches checking AI output, so the kit practices what it preaches (disclosed).
LO1 · Apply
Spot fabricated clauses, wrong specifics and missing references in an AI-drafted customer email — including the two that look safe.
LO2 · Discriminate
Apply the four-rung Verify ladder before any AI-assisted message reaches a customer.
LO3 · Perform
Decide send vs. hold-and-fix on a confident draft and justify the call against the team guidelines.
By the end of this experience a learner can do the three things above — assessed by the hotspot hunt and Verify ladder scores in-build; L4 target is zero AI-invented-claim escalations. Every interaction in the build exists to create the evidence for one of them.
Every AI-literacy artifact reviewed before building this was either a policy PDF or a prompt-engineering demo. Neither touches the actual failure moment. In the anchor incident (ticket NW-4821):
The ticket reopened as an escalation. The agent wasn't careless — the draft read confident, warm, and professional. Confidence is not correctness.
1
invented policy clause — "Rate Protection Guarantee 4.2" exists nowhere
2
unverified figures — "€412 by Friday" broke on day 4
0
ticket references in the reply — Billing couldn't trace the promise
The problem was the client's. These were mine — the design and build constraints that shaped the solution.
Feel the failure first
Telling agents to check AI drafts changes nothing. The lesson had to let a lazy send produce a visible customer consequence before the checking behavior is taught.
Decoys that do not teach paranoia
The hotspot hunt needed safe passages — plausible text that is actually fine — or agents would learn to flag everything and trust nothing, which is its own failure.
One lesson, two settings
Self-paced for agents, huddle-led for team leads. The same scenes had to work alone at a desk and guided by a facilitator with a note.
An interactive lesson that makes the learner feel the failure first, then gives them the checking behavior: a 3-of-5 risk-hotspot hunt with safe decoys, the 4-rung Verify ladder, and a branching send decision where the lazy path produces a customer-consequence email.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
From the moment-of-send behavior backward — each stage links the working document produced at that step.
More design docs
Mapped from ticket NW-4821: the draft read confident, warm and professional — and reopened as an escalation. The map puts feeling the failure before teaching the check, because confidence is not correctness.
The foundations that shaped this design — mapped to the specific decisions made in the build:
Dual Process Theory
The four-rung Verify ladder trains System 2 (deliberate checks) over System 1 (automatic acceptance). Learners discover the cost of not checking AI drafts before learning the framework.
Scaffolding Theory
The prompt builder starts with guided steps (template selection then refinement then open creation). Scaffolds are gradually removed as learners gain confidence.
Cognitive Load Theory
One AI tool per lesson reduces extraneous load. The feel-the-failure arc makes the problem visible before instruction.
Kirkpatrick L1-L4
L1: >=4/5 clarity on AI guardrails. L2: >=80% correct prompt construction. L3: 85% AI-assisted tasks pass source verification. L4: 25% reduction in AI-hallucinated outputs post-training.
Pre-committed targets (agreed with stakeholders before build, not retrofitted):
Lesson rated useful in huddle debrief; ≥4/5
L1 · Reaction
Lesson rated useful in huddle debrief; ≥4/5
L2 · Learning
Hotspot hunt + ladder checked in-lesson; all 3 real risks found
L3 · Behavior
#ai-catch tagged reviews in live replies within 2 weeks
L4 · Results
Zero AI-invented-claim escalations in the quarter after rollout
The incidents shared one anatomy: a confident, polished AI draft that skipped the forty seconds of checking that would have caught the fabricated citation or the leaked clause. Policy training was not the gap — the same people who breached the policy had signed it. The proposal was a four-scene interactive lesson that walks the actual arc: feel a failure happen, hunt the risks in a real-shaped draft, learn the verification ladder, then make the send decision under deadline pressure.
An AI policy e-learning module considered · rejected
Fast to deploy and audit-friendly. Rejected because it produces exactly the artifact the incidents already disproved: signed awareness. Policy states the rules; it does not build the reflex of checking a confident draft — and confident drafts are the whole threat.
A restrictive 'don't use AI' campaign considered · rejected
Simple messaging. Rejected because it drives usage underground where no checking happens at all — the opposite of the goal — and forfeits the productivity gains the organization actually wants. The lesson teaches safe use, not abstinence.