Articulate Storyline / Branching scenario
Before Opening
A wrong part. An uncertain delivery.
A customer who needs a clear answer.
Take a support call from Lena, a café manager preparing to open on Monday. Investigate conflicting information, explain what is still uncertain, and agree on a next step she understands.
- Audience
- Customer-support representatives handling product and delivery questions.
- Performance objective
- Resolve a misunderstanding with verified facts, plain language, explicit permission and an owned follow-up.
- My role
- Learning design, script and visual direction, content review and iterative revision.
The performance problem
An estimate has become an expectation.
Lena ordered an FX-12, but an FX-21 arrived. An earlier email appears to promise delivery before opening. A reassuring answer can make matters worse if it skips verification or implies a commitment the representative cannot make.
I scoped the practice around the decisions within the representative’s control: establish the facts, explain uncertainty, repair a misunderstanding and agree an authorized follow-up. Product logistics form the context; the assessed behavior is the communication.
Alignment and practice
Make the conversation carry the learning.
Consequences before coaching
Scenario-based practice lets the learner choose a response and encounter Lena’s reaction before reviewing guidance. Distractors represent plausible shortcuts—rushing the request, repeating jargon or treating an estimate as a promise—so feedback addresses the reasoning behind the choice.
A chance to recover
Formative feedback supports a correction during the call. Recorded choices shape later repair prompts and the debrief. Clear, recovered and unresolved outcomes distinguish accurate handling from an effective repair and an unfinished handoff.
Facts within reach
The persistent case record and available job aid provide scaffolding: learners can consult evidence while deciding what to say. This keeps the task focused on applying information rather than remembering codes or policy wording.
Permission before action
A request for consent does not submit the stock check. Lena’s explicit agreement appears before a separate Submit action. This criterion-based decision makes authorization observable instead of inferring it from a generally positive conversation.
A consequential detail
Separate a status target from a promise.
After an authorized submission, 11:30 is a warehouse status target; an answer may still be pending. The representative owns the 11:45 callback whether or not the warehouse replies. Monday delivery stays unconfirmed. The debrief carries these distinctions through to the final plan.
This is the design rationale for tracking choice history and request state: an ending should reflect what the learner actually said and authorized. A generic success score would hide the error that needs attention.
Transfer and performance support
Carry the conversation model into the next call.
The companion Northline reference uses Verify / Explain / Agree / Own across a call checklist and worked language. The ending asks learners to rehearse a callback when the warehouse still has no answer, then compare their wording with the reference. This provides a transfer opportunity; it is not automatically scored.
Process and evidence
Review the decisions behind the build.
I moved between the script, a functional HTML prototype and published Storyline review to check whether the consequences, repairs and final status agreed. The prototype’s automated checks cover 36 decision sequences. The native course has been reviewed on representative clear, recovered and unresolved routes, including consent and restart. These are separate checks; native release testing is not exhaustive.
Design artifacts and evaluation plan
Analysis and design: The fictional brief defines the audience, task constraints and performance objective. The branching specification connects decisions to consequences, corrective feedback and end states. These are authored design assumptions, not findings from a client needs assessment.
Development: The prototype tests the route model; the Storyline build uses variables, conditional feedback and a persistent case record. Published review led to revisions to consent, callback wording and the Rise presentation.
Implementation and evaluation: Workplace rollout remains proposed. A support subject-matter expert would first validate the policy and language. In a pilot, learners would handle a fresh case, assessed against factual accuracy, explanation of uncertainty, authorization and ownership. Follow-up observation would examine use on real calls; no workplace impact is claimed.
Original design brief · PDF · Early build specification · PDF
These process artifacts document earlier design stages; the published sample and current case study show the reviewed behavior. The HTML prototype remains a separate, portable design artifact.
Fictional company and policy. No client approval, learner pilot or measured business results are claimed. The published course remains available for review while a further visual revision is prepared.