Ready to compare
01Add one Level 1 agent
Level 1 staffing · 1 override
Tickets may be waiting because the general support team is too busy. This change increases the team from 4 agents to 5.
Scenario Lab · Support operations
Compare operating changes with the same simulated conditions.
Start with a support-operation baseline, compare two changes, then inspect the observed effect and supporting evidence.
Terminology help
- Current operation Technical term: baseline
- The operation used as the reference point.
- Proposed change Technical term: scenario
- A change tested against the current operation.
- Matched comparison Technical term: paired comparison
- Each change and the current operation use the same simulated conditions for a fairer comparison.
- Result to measure Technical term: objective
- The measure used to compare changes.
- Required condition Technical term: guardrail
- A result that must stay within a limit.
- Plausible range Technical term: confidence interval
- A range describing uncertainty around the estimated average result.
- How often it performed better Technical term: improvement probability
- The share of matched tests where a change performed better.
- Test different assumptions Technical term: sensitivity
- Evidence from changing one assumption across explicit tested values.
- Example run Technical term: representative playback
- One selected sampled run used to explain timing and flow; it does not represent every run.
The situation
Customers are waiting too long for support.
One possible cause is that the general support team is overloaded. Another is that new requests spend too long being reviewed and assigned.
OpsTwin tests both changes under the same simulated conditions.
01
Current operation
Current operation
A 100-ticket support workflow. The values below describe what is being tested.
- 100 customer requests
- One new request every 1.5 minutes on average
- 4 general support agents (Level 1)
- 2 specialist support agents (Level 2)
- 20% go to specialist support
- About 10% require additional work after review
- 60-minute resolution target
Result to measure: Average time to resolve a ticket
Matched tests: 50 — simulated operating days tested under the same conditions.
Review or edit assumptions
02
Two changes
What would you like to compare?
OpsTwin simulates the same operating conditions for both changes and compares their observed effects.
Ready to compare
02Faster triage
Triage processing · 1 override
Tickets may be delayed before reaching the correct team. This change reduces initial review and assignment time from 2 minutes to 1.5 minutes.
Edit scenario
03
Comparison settings
How the comparison will run
Any required conditions will be checked when the comparison runs.
Result to measure: Average time to resolve a ticket
Matched tests: 50 — simulated operating days tested under the same conditions.
Customize this comparison
Technical experiment settings
These settings control how the experiment is executed. The default values are suitable for the guided example.
- Base seed
- 20260716
- Confidence
- 95%
- Representative detail
- Sampled · 25 items
- Risk thresholds
- 80% SLA · baseline SLA target
Your result will appear here after the comparison.
See where the proposed change enters the workflow and where waiting or workload changed.
Process being simulated
Process
See the current process, proposed changes, and where queues build up.
- New customer requests
- Review and assign
- General support
- Specialist support
- Verify the response
- Completed
- New customer requests enter the review step.
- 80% are sent to the general support team.
- 20% are sent to the specialist support team.
- General support moves to Verify the response.
- Specialist support moves to Verify the response.
- After support, the response is checked. Most requests are completed.
- About 10% of tickets require additional work. Tickets selected for rework return to the specialist support team.
See how consistently the result appeared across matched simulated operating days.
Run the comparison first to inspect uncertainty evidence.
See which teams were busy, waiting, or constrained.
Run the comparison first to inspect team workload.
Change one input across explicit values to see whether the result remains similar.
Change one assumption at a time
Test different assumptions
Test how one assumption changes the result across selected values.
What happened
Run the explicit values to view the observed response.
Plain conclusionNot availableOnly explicit tested values are shown; the result does not establish the cause.Result checksNot availableHow strongly the result changedAvailable in technical sensitivity evidence.
| Value | Status | Mean |
|---|---|---|
| No sensitivity evidence yet. | ||
Show technical sensitivity evidence
Run the selected values to inspect technical sensitivity evidence.
Add only costs you know. OpsTwin will not invent missing values.
Costs you provide
Costs
Add costs you know alongside the result to measure. OpsTwin does not infer costs or make a recommendation.
Recurring costs are calculated for the simulated workload in each comparison run. They are not a real-world billing-period forecast.
Cost assumptions
Equivalent to EUR 60.00 per agent-hour
Equivalent to EUR 60.00 per agent-hour
Leave a field blank when the cost is unknown. OpsTwin will not treat a missing value as zero.
Cost of making the change
One-time cost remains separate unless periods are explicit.
Run with explicit assumptions to inspect recurring costs and operational trade-offs.
Inspect one selected simulated day to understand timing and flow. It does not represent every run.
Run a completed comparison first to inspect one selected run.
Inspect seeds, contracts, integrity checks, and raw returned evidence.
Run the comparison first to inspect technical evidence.