Simulation best practices

Last updated: October 20, 2026

A simulation is only as good as the scenario behind it. This article covers the choices that decide whether one trains anything useful: how tightly to scope it, what belongs in the scenario field and what does not, and how to get it in front of learners so the results mean something. For the persona itself, see Best practices for prompting a persona.

Build one simulation around one situation

Each simulation should cover one situation with one outcome you could point at and call success. "Cancel the subscription and retain the customer with a discount" is a situation. "Handle billing queries" is a topic, and topics produce shapeless conversations that are hard to score fairly.

If a scenario carries two unrelated sets of facts, two customers or two problems, split it into two simulations. The AI tends to follow one thread and drop the other, and the learner is left guessing which one counted.

Build for the unhappy path as well as the happy one. A library where every customer accepts the first answer offered trains nothing your team will actually meet on a live queue.

Keep the scenario field for the scenario

The scenario describes the situation the persona is in. It is not where reference material, grading rules or learner briefing belong, and adding them makes the simulation worse rather than richer. Each of these has a field the product actually reads:

Reference material - Product manuals, policy documents and long knowledge base extracts pasted into a scenario bury the situation. Attach them as a process on the scorecard section instead.
Grading rules - A line in the scenario saying a mistake should cost points has no effect on the score. Scoring comes from the scorecard and nowhere else.
The learner's briefing - What the learner needs to know before they start belongs in learner instructions. Mixed into the scenario, the persona can end up reciting the learner's own brief back at them.
Coaching - Do not ask the persona to correct the learner or explain their mistakes mid-conversation. Feedback comes afterwards, from the scorecard.
Timing and arithmetic - The persona cannot time a learner, count words or measure typing speed. Asked to, it will produce numbers it has invented.

A scenario that runs past a couple of short paragraphs is usually carrying something from that list.

Use the fields rather than the prompt

Some things look like they can be handled by describing them in the scenario, but the product only reads them from their own field.

The AI customer comes from the persona field. A second character described in the scenario will not join the conversation.
Language is set on the simulation, and the persona itself needs to have been created in that language.
The scorecard attached to the simulation is what grades it, so the skill you want measured has to exist as a section there.

Keep it short enough to finish

Long simulations fail in ways that look like bugs. A conversation running beyond about an hour will time out and lose the attempt, and a hold of more than a few minutes can end the call. The persona also will not talk at length uninterrupted, so a scenario built around the customer monologuing while the learner listens will not play out the way you wrote it.

Aim for something a learner can complete in a few focused minutes. If a scenario cannot be finished in that time, it is usually two simulations.

Deliver it through an assignment

An attempt started from the Simulations library is saved as practice and does not credit an assignment, so results taken that way will not line up with your reporting. Point learners at an assignment instead, especially during a pilot, and check attempts against the assignment before you trust the numbers. See How to create an assignment.

Setting a minimum of two attempts is worth considering for anything you care about. Learners who know a second run is coming are more likely to read the feedback from the first.

Run it yourself before you assign it

Take the simulation once as a learner would. You are checking two things: that the conversation goes where you intended, and that the score you come out with reflects what you were trying to measure. A scenario that scores well without the learner doing the thing you built it to teach is too loose.

Assume learners can see the scenario details while they work. If knowing a detail up front would let someone pass without demonstrating the skill, keep that detail out of the scenario.

If you have any further questions, contact the Solidroad team via the Help tab in the platform.