Fictional client — portfolio build · targets, not field results
Launch-Day Enablement: Support, Sales and 60+ Partners
The feature ships in 12 days. Support, Sales and 60+ partner orgs must all be capable on day one.
The Audience
Support tier-1/2 (~40 agents), Sales CSAs (~25) who demo customer-facing, and 60+ partner reseller orgs onboarding self-service across 9 countries and 4 languages.
Responsibilities
Needs analysis · asset design (KB, widget, tour) · launch-cadence planning · KPI dashboard · localization checklist — the enablement arc from stakeholder research to day-30 review.
The Build
HTML/CSS/JS interactive artifacts · KB search with gap radar · decision-tree design · KPI framework · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted KB-article stubs and tour-copy variants; the needs analysis, audience-to-artifact matching and the KPI framework were authored by me. All output edited, verified and disclosed.
LO1 · Apply
Find the right enablement asset for a Rate Guard question in under a minute using KB search.
LO2 · Discriminate
Route a live Rate Guard symptom through the triage tree to the correct resolution branch without an unnecessary escalation.
LO3 · Perform
Deliver the arming flow well enough to demo it to a customer — the same demo the in-app tour rehearses.
By the end of this experience a learner can do the three things above — assessed by CSA demo spot-audits and the armed-quote rate (L2/L3). Every interaction in the build exists to create the evidence for one of them.
CargoDesk ships Rate Guard in 12 days. Leadership's request: "training session before launch." But the constraints found talking to team leads kill that plan:
The real question: what launch-week system makes every audience independently capable the day the feature ships — and keeps them capable through month three?
24/6
Support shifts — synchronous training can never cover everyone once
9
countries, 4 languages across partners — live delivery impossible at scale
68%
of previous feature's tickets came from five recurring questions — predictable content beats reactive training
The problem was the client's. These were mine — the design and build constraints that shaped the solution.
Three audiences, one kit
Support, Sales CSAs and 60+ reseller orgs work differently. One searchable KB had to serve all three without quietly becoming three KBs — the gap radar exists to prove it doesn't.
Mirroring the triage
The Support decision-tree had to mirror the real triage flow, including its shortcuts, or agents would route around it by day two. Every branch was checked against actual ticket handling.
A tour that survives demos
The CSA in-app tour is rehearsed for customer-facing demos: every click had to be demo-safe and honest about the product — no staged screens that the release would contradict.
A launch-ready enablement kit, not a meeting: one searchable KB for everyone, a triage-mirroring decision-tree widget for Support, a rehearsed in-app tour for CSA demos — each artifact matched to how its audience actually works.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
From stakeholder research to a launch-ready enablement kit — the stages below are the actual production sequence.
More design docs
Mapped from the real question behind 'a training session before launch': what launch-week system makes every audience independently capable on day one — and keeps them capable through month three. A session can't; artifacts matched to each audience can.
The instructional-design foundations that informed this build:
Action Mapping (Clark)
Every behavior the kit produces is traced back to a business goal and a specific practice activity. See the linked action map for the full chain.
Cognitive Load Theory
The Three.js scene reduces extraneous load by visualising abstract systems. Learners focus on the decision, not the interface.
Situated Cognition
The environment matches the real context. Practice happens where the skill will be performed.
Kirkpatrick L1-L4
Evaluation designed for all four levels: reaction, learning, behavior, results. See the linked evaluation plan.
Pre-committed targets (agreed with stakeholders before build, not retrofitted):
Asset helpfulness in launch-week pulse; ≥4/5 per audience
L1 · Reaction
Asset helpfulness in launch-week pulse; ≥4/5 per audience
L2 · Learning
CSA demo spot-audits ≥90% completion score
L3 · Behavior
Armed-quote rate on CSA-sent quotes ≥85%; KB self-serve share up
L4 · Results
≥75% account adoption in 30 days; RG tickets ≤15% and falling
Launch was in 12 days, and 'run a training webinar' was the standing answer. But the audience was not one team — it was Support, Sales, and 60+ partner organizations across timezones and spoken languages, all needing capability on day one and reference-able support forever after. The proposal was a self-serve enablement kit: a searchable knowledge base, a decision-tree troubleshooter, and an in-app guided tour — capability that arrives when each learner needs it and stays after launch day.
The launch webinar considered · rejected
Familiar and easy to schedule. Rejected because it is one-shot: a partner who joins in week six gets nothing, recording-watching collapses to near zero, and timezone/language barriers guarantee partial coverage of 60+ orgs. A webinar trains the audience that shows up.
A launch PDF emailed to all partners considered · rejected
Fast to produce. Rejected because rate-limit questions arrive mid-task, in the product — a PDF is unread exactly when the question exists, and offers no path from symptom to resolution.