Present the results
Your client is not buying a simulation. They are making a decision. Give them the answer, show why you trust it and be plain about what it rests on.
Lead with the recommendation
Open with the choice you were asked to help with and what you recommend. Save the model for later. A strong first line sounds like this:
That example uses the results from Your first model, where the worst two-desk replication was still better than the best one-desk replication.
A simple structure
| Section | What to cover |
|---|---|
| The decision | The choice, what better looks like, who decides. Use the words you agreed at the start. |
| The recommendation | What to do, in a sentence |
| Why we trust the model | How the Baseline compared with real numbers |
| The options | What you tested, side by side, on the agreed measures |
| The tradeoff | What each step of investment buys |
| Assumptions and risks | What the answer rests on, and what would change it |
| Next steps | What to do Monday, and how you'll check it worked |
Choose what to show
| You want to show | Use |
|---|---|
| The headline against the Baseline | Results, Overview |
| Where the problem sits, on a picture they recognize | Results, Diagram. It shows results on your own process diagram. |
| The bottleneck and why | Results, Flow Analytics |
| What each option buys | View tradeoff |
| Specific charts for a report | Results, Dashboard, with + Add a card |
| The process in motion | Results, Animation |
| The numbers for your own analysis | Download on a scenario |
Use Show time in: on the Results screen to put durations in the unit your client thinks in. Minutes make sense for a clinic, and days for a job shop.
Use animation well
Animation does more than any table to build belief in a meeting. People recognize their own process and start pointing at the screen. Use it to explain, not to prove. A convincing picture of a wrong model is still wrong.
A scenario only has animation if you recorded it. Tick Include animation when you run it, or use Re-run with animation on the Animation tab. Do this before the meeting.
A good pair: play the Baseline for a minute so people see the queue build, then play the recommended scenario. Nobody needs a chart to understand the difference.
Be honest about uncertainty
- Give ranges where they matter. "Between 40 and 50 minutes" is more useful than "44.37 minutes", and easier to defend.
- Separate what you measured from what you assumed. Bring your input log. Name the two or three assumptions that matter most.
- Say what the model leaves out. Staff morale, patient satisfaction, the cost of disruption. Keep any measure you couldn't simulate on the slide, marked as outside the model.
- Talk about comparisons. A model is usually stronger on the difference between options than on any single absolute number.
- Don't oversell. Say "the model suggests" where that's what you know. An inconclusive finding, stated plainly, is a good result.
Questions you'll get
| They ask | Have this ready |
|---|---|
| How do you know the model is right? | Your table of targets against model results, and who reviewed the Baseline |
| Where did that number come from? | Your input log, with a source and label for each input |
| What if demand grows? | Ideally a scenario you already ran. If not, offer to run it and come back. |
| Why not just do the cheaper option? | The tradeoff chart, showing what that option does and doesn't buy |
| This doesn't match my experience. | Listen first. They may have found a gap. Offer to check it and re-run. |
After the decision
- Agree how you'll check the real result. Write down the prediction and the measure, and compare them after the change goes live.
- Hand over the record. The decision, inputs, assumptions, targets, scenarios and findings.
- Keep the model. Once the change is live, update the Baseline to match it. Your next question starts from there.