Scenario-based training from a company policy

Ask anyone in accounts payable whether they should check new bank details before paying an invoice, and they will say yes. The real test comes on a Friday afternoon, with an urgent invoice from a regular supplier and an email saying the bank account has changed.

That gap between knowing a rule and applying it under pressure is what scenario-based training is for. In this example we take one section of a company policy, two pages on suspicious emails and payment requests, and turn it into a short course: a lesson with the rules, a four-question quiz and a scored scenario with seven decisions and three endings.

A quiz checks memory, a scenario checks behaviour

A quiz question asks "what does the policy say?". The learner recognises the right option among four, which is useful evidence that the rule was read and remembered.

A scenario asks "what do you do now?". The learner sees a situation, not a rule: an email, a deadline, a request that looks routine. The right answer has to come from judgement, and a wrong choice has consequences in the story. Policies are written for audits, but most of the real risk sits here: a correct rule that nobody applies when the request looks normal.

Which policies are worth a scenario

Not every policy needs scenario-based training. A scenario earns its place when three things are true:

• The rule has to be applied in a specific moment, usually under time pressure: a payment, a data request, a visitor at the door.
• The wrong action looks reasonable. Replying to the supplier to confirm new bank details feels careful. The policy says it is exactly the trap.
• The cost of a mistake is high, so you want to see how people decide in a realistic situation, not just a signature under the document.

Payment fraud, data protection, information security, health and safety and anti-bribery all fit this pattern. A travel expense table does not.

The example: one section of a security policy

Our source is chapter 4 of a fictional company's information security policy, about 660 words. Section 4.3 covers changes to supplier bank details, and its rules are clear:

1. Never confirm new bank details by replying to the email or by using any contact details in it, including a phone number or a "verification" link.
2. Call the supplier on the number already on file in the supplier master data.
3. Get a second approval from the Accounts Payable Lead before the first payment to a new account.
4. Treat urgency, such as "invoice due today", as a red flag, not as a reason to skip the checks.
5. Report the email with the Report phishing button and do not delete it.

If a rule cannot be broken by a plausible choice, it belongs in the lesson or the quiz, not in the scenario. These five can all be broken.

From policy rules to decision points

The scenario starts in the inbox: Friday, 2:40 pm, an email from Brightline Packaging, a regular supplier. The bank account has changed and invoice BP-4471 is due today. The first question is "What do you do first?", with three options:

• Treat the email as suspicious and check it against earlier correspondence.
• Reply to the email and ask them to confirm the new account.
• Update the bank details now, because Brightline is a regular supplier and the invoice is due today.

Only the first option scores a point. If the learner replies, the fraudster of course confirms. Paying at once skips verification because of a deadline, which the policy names as a red flag.

In the next scene the learner spots that the sender domain is brightline-packagings.example instead of brightline-packaging.example and has to choose how to verify: the number on file, the number in the email, or the linked verification page.

Three design choices make this work:

• Every wrong option is tempting. Nobody would pick "ignore the policy". People do pick "call the number in the email", because it feels like verification.
• Feedback quotes the policy. Under each answer, the learner reads which rule applies, in the policy's own words.
• Endings show consequences, not grades: "The money is gone", "Fraud stopped" and "Stopped, but not by the book", for a learner who blocked the payment but skipped a step.

Want to feel the difference yourself? Play a similar scenario from our template gallery: a call from fake IT support, where a caller asks you to approve a sign-in request. The preview is free.

Scoring: what your LMS learns from a scenario

A scenario can run in two modes. In consequences mode, the learner simply sees where each path leads. In scored mode, every good choice is worth a point, and the result is the percentage of good decisions on the path the learner actually took.

Scored mode records each learner's decisions in a realistic simulation. That is not proof of how someone will act in a real incident, but it tells you far more than a test of the rules. In a SCORM package, the LMS receives that percentage as the score and every decision marked correct or incorrect, so you see not only who finished, but at which step someone paid the fraudster in the simulation. How much of that an administrator can see depends on the LMS: see what your LMS will report.

One practical rule: in a course with several scored lessons, the course score comes from the most recently finished scored lesson. Put the scenario last, after the quiz, if you want its result to be the one your LMS reports.

How to create scenario-based training with AI in LMSable

The video above shows the whole example. In short:

1. Create a new course, describe the audience in the course brief and paste the policy section under Source material. Set Fidelity to Strictly from material, so the rules in the course come from your policy.
2. Copy the lessons prompt into your AI chat and import the answer: a lesson with the rules and a quiz.
3. Set the last lesson's type to Scenario, describe the situation in one or two sentences and run the generated prompt in your chat. It already contains your policy. Add one line, "Use scored mode": scenarios are unscored by default.
4. Paste the answer back, check which answers are worth a point and open the Graph view to see every path.
5. Preview the scenario as a learner, then publish the course as a SCORM package for your LMS, as HTML or as a link.

The detailed steps are in the Help Center: build a branching scenario, create a course from a brief and source material and export a SCORM package. If you want to start from a finished example instead, the course templates include several security scenarios you can preview. If you are choosing between H5P and SCORM for a scenario, see H5P Branching Scenario vs SCORM.

Before you paste an internal policy into any AI service, check your organisation's data protection rules and the data settings of your AI provider.

What AI does well here, and what it does not

AI handles the mechanical part well: it turns a list of rules into scenes, writes plausible options for each decision and links the feedback to the right paragraph. A first version takes minutes instead of an afternoon.

What AI does not know is how fraud attempts look in your company or which wrong choice your team tends to make. Review every scene with the policy owner: each scored answer must match the policy, and no wrong answer may be accidentally correct. LMSable can instruct your chat to work strictly from the material, but the review is still yours.

The result

Source: a two-page policy section that people were asked to read and sign.

What you can reuse is the method: pick a section where the wrong action looks reasonable, turn each rule into a decision with tempting alternatives, and let the feedback quote the policy.

For a longer document, such as a full procedure turned into a ten-lesson course, see How to turn an SOP into employee training.

Turn your own policy into a scenario

Have a policy that people sign but do not always follow? Paste one section into a new course, let your AI chat draft the scenario and publish it to your LMS.

Build your first scenario for free in our SCORM authoring tool. The Free plan includes one course with up to 20 lessons and SCORM 1.2 export.

FAQ

How long should a scenario be?

Five to ten decision scenes is enough for one policy section. In this example, seven scenes and three endings take a few minutes to play. Longer scenarios are better split into several lessons, one situation each.

Do I need a separate scenario for every rule?

No. One realistic situation usually touches several rules in sequence, as the supplier email here touches verification, second approval, urgency and reporting. Rules that cannot be tested by a choice belong in the lesson or the quiz.