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.”
A launch-week enablement kit instead of a webinar: one searchable KB with a gap radar, a practice queue of nine tickets from three audiences (search first, route through triage, escalate only with everything attached), and a demo rehearsal for CSAs that is scored on what they promise the customer.
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 · KB and gap loop · practice queue and triage tree · demo rehearsal · launch cadence and proposed KPIs · localisation checklist.
The Build
HTML/CSS/JS artifacts · one shared ticket file for 2D and 3D · scoring design · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted KB-article stubs and variants of ticket and tour wording; the needs analysis, the queue design, the triage tree, the scoring and the KPI proposals were designed by me. All output edited and checked; use disclosed.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
Launch-week practice queue
Nine tickets from Support, Sales CSAs and partners: search the KB, route through triage, escalate with everything attached
3D streams into one knowledge base
Nine tickets flow from three streams into a KB reservoir. Pick the article (it slides off the shelf) or log a gap, route the ticket through the triage gates, and watch it leave to tier-1 or up the escalation tower. Leaks grow where an audience is failed.
Searchable KB Bundle & Gap Radar
Five articles and the launch FAQ with multi-word search and a gap radar that logs zero-result searches.
Why conventional training failed the operational reality
CargoDesk (fictional) ships Rate Guard in 12 days. Leadership's request: "a training session before launch." The constraints in the brief rule that out:
The question behind the request: what lets each audience answer its own Rate Guard questions the day it ships, and tells us within a week which audience it is failing?
Core diagnostic finding
In this fictional launch, a training session would reach the people who attend once. The questions arrive later, mid-task and from three audiences with different needs. What matters is whether each audience finds the answer, routes the rest correctly, and whether a question that appears twice gets an article.
Three audiences, one kit
Illustrative premise: Support shifts — synchronous training can never cover everyone once
Design Constraint → Build Rule: Support, Sales CSAs and 60+ reseller orgs work differently. One KB serves all three, so the practice queue mixes all three streams and the debrief splits the results per audience.
Mirroring the triage
Illustrative premise: countries, 4 languages across partners — live delivery impossible at scale
Design Constraint → Build Rule: The triage tree follows the order an agent checks the record (window, plan, flag) so it can be used on real tickets. It is a plausible procedure for this fictional product, not one checked against a real company’s tickets.
A tour that survives demos
Illustrative premise: of the previous launch’s tickets came from five recurring questions (premise, not data): predictable questions can be answered before they are asked
Design Constraint → Build Rule: The tour ends in a scored rehearsal: send is gated until the quote is armed, and the three customer questions check exactly the promises the product does not keep.
Search first, route the rest, write the article the second time
Performance problem
CargoDesk (fictional) launches Rate Guard in 12 days. After the previous launch, tickets piled up at tier-2 with avoidable escalations and incomplete hand-offs, and partner questions went unanswered for days (premise of this case).
Learners and context
Support tier-1/2 (about 40 agents, 24/6 shifts), Sales CSAs (about 25, demo to customers) and 60+ reseller organisations who onboard themselves in four languages. Short, repeatable practice; the queue takes about 15 minutes.
Is training the answer? Not on its own
- A guard on the revision screen. “Editing ends Rate Guard protection; re-arm before sending” on the quote revision screen prevents the most common false bug report.
- Required fields on escalation. If the ticketing form demands the quote or workspace ID, a screenshot and an impact line, escalations stop bouncing; reminding agents is weaker.
- Partner languages. The KB is English. DE / NL / FR FAQ and tour captions, and someone who reads the gap log in those languages, are content and staffing decisions.
Alignment: every objective has practice, evidence, feedback and a route back to the job
| Objective | Practice | Assessment | Feedback | Transfer |
|---|---|---|---|---|
| LO1 Find the answer in the KB before escalating | Every ticket in the queue starts with a search; the KB page itself with a gap radar | 1 point per ticket for the right article, or for logging a gap when none exists | The expected article named after filing | KB link required in the resolution macro (recommended) |
| LO2 Route through triage and escalate only with everything attached | Nine tickets through the triage tree; three need someone else | 2 points for the route, 1 for escalation discipline; needless escalations and missed escalations counted; one critical ticket | Reason per ticket; per-audience leaks in the debrief | Required fields on the escalation form (recommended) |
| LO3 Demo the arming flow without over-promising | Tour of the quote screen, then arm, send and answer three customer questions | Demo check /4 (armed before send + three answers) | What each wrong answer promises that the product does not | Rehearsal before the first customer demo |
Evidence register: what is real, what is invented
- Fictional premise CargoDesk B.V., Rate Guard, the nine tickets, every customer and reseller name, and the audience sizes.
- Illustrative premise “About two-thirds of the previous launch’s tickets came from five recurring questions” (shown earlier as “68%” and as historic data). It motivates the FAQ; it is not data.
- Design decision The triage tree, the scoring (36, pass 30, at most one needless escalation, no missed escalation) and the demo check. The tree is plausible, not a real company’s procedure.
- Not measured Adoption, ticket share and audit targets. Earlier versions stated “≥75% adoption”, “≥90% audit score” and “≥85% armed quotes” as pre-committed; they are now proposals in the adoption plan and the evaluation below.
Measurable Performance Objectives
Three objectives, each practised and scored in the kit. The earlier troubleshoot widget had no tickets, so LO2 had no practice; the queue now provides it.
Find the KB article that answers a Rate Guard question, or log a gap when none does, before escalating.
Evidence in the build: KB point on each of nine tickets; the gap radar in the KB bundle.
Route a ticket through the triage questions to the right resolution, and escalate only with the ID, a screenshot and one sentence of impact.
Evidence in the build: route and discipline points; needless and missed escalations; the critical settlement ticket.
Arm a quote before sending it and answer customers’ questions on window, revision and coverage without promising what the product does not do.
Evidence in the build: demo check /4 in the in-app tour.
Why This Modality Won (Trade-Off Analysis)
Before committing to the final architecture, we evaluated and rejected lower-transfer alternatives against the workplace constraints:
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.
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.
A launch-week enablement kit instead of a webinar: one searchable KB with a gap radar, a practice queue of nine tickets from three audiences (search first, route through triage, escalate only with everything attached), and a demo rehearsal for CSAs that is scored on what they promise the customer.
Why a queue
Practice in the shape of the job
Tickets arrive one at a time, mixed across audiences, with the deciding facts in the record rather than in the customer’s words. The queue keeps that shape, so the habit practised is the habit used.
Why a gap loop
The second time is the signal
A question with no article should be logged, not improvised. The white-label ticket appears twice; logging it on Tuesday drafts the article that answers Friday. The cost of skipping it is visible in the same session.
Why 3D here
Leaks per stream
Three streams feed one KB. Needless escalations and repeat questions grow a puddle beside the stream they came from, so the audience the KB is failing is visible before any dashboard exists.
Production Sequence & Traceable Artifacts
The stages below show how the artifacts depend on each other. In this fictional case one designer produced all of them.
What would tell us it worked
A proposed plan. Nothing below has been measured.
| Question | Measure / instrument | When | What we would do with the answer |
|---|---|---|---|
| Can agents work the queue? | Queue score, needless and missed escalations per agent (first and second run) | Launch week, each agent once | If the critical ticket is often closed, add a second settlement case and a banner in the real invoice view |
| Is the KB answering each audience? | Zero-result searches and repeat questions per audience per week (gap radar) | Weekly from T-0 | Draft an article for any question that appears twice; prioritise the stream with the most leaks |
| Do escalations arrive complete? | Share of tier-2 escalations returned for missing IDs or evidence | Weeks 1–4 against the 30 days before launch | If it does not fall, make the fields required in the form (a tool change, not training) |
| Do CSAs demo safely? | Demo check before the first customer demo; armed share of CSA-sent quotes | Weeks 1–4 | Targets to agree with the launch owner before T-0 (no baseline exists in this case) |
Instructional Design Takeaway
“Why this form wins: the problem is capability at unpredictable moments across a huge distributed audience, so the solution is practice in the shape of the job, a KB that grows from its own gaps, and a demo rehearsal that checks what CSAs promise.”
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 is a launch-week kit: a searchable knowledge base with a gap radar, a nine-ticket practice queue on the triage tree, and a scored demo rehearsal, with proposed KPIs per audience.
Transparent Portfolio Scope
Honest limitation: a fictional product with a hand-built UI mock and a plausible, not real, triage procedure. English master; the partner tickets carry an English gloss. Attribution of any ticket change to the kit would be directional without a staggered rollout.