Skills CX operations
Simulating an SLA threshold
Someone proposes a two-hour target for P1 and wants to know whether it is achievable. The tempting answer is to count how many past tickets closed inside two hours. That number is almost always too optimistic, for a reason that has nothing to do with the threshold: the tickets that are still open are the slow ones, and they have no resolution time to count.
npx rulebase-skills install cx-sla-threshold-simulationWhen to use it
Reach for this when someone says any of these — they are the phrases the skill itself triggers on:
- “what would our SLA attainment be at 2 hours”
- “what if we tightened the target”
- “should our P1 target be 2h or 4h”
- “% of tickets resolved within X”
How it works
The method, in the order the skill runs it. The full procedure — tables, worked examples and the edge cases — is in the skill itself.
Build the clock once, then sweep
Threshold comparison is trivial arithmetic. All the difficulty is in defining the elapsed time you are thresholding, so do that once, carefully, and then sweep as many thresholds as anyone wants.
Open tickets are the whole problem
An unresolved ticket is censored: you know its clock has already run for some time, and not what its final time will be. Dropping censored tickets is the standard mistake and it biases attainment upward, because slowness is exactly why they are still open.
What the simulation can and cannot tell you
It can tell you the mechanical answer: given exactly the behaviour you had, this is the attainment the proposed target would have recorded. That is genuinely useful, and it is what people are asking for.
Choose the threshold on the distribution, not on a round number
Look at the elapsed-time distribution before proposing anything. Response-time distributions are heavily right-skewed, so.
Related skills
Free and open source, and vendor-neutral — it reads the conversations from whichever helpdesk you already run. Browse all 149 skills · connect your helpdesk over MCP · source on GitHub
