Two days of tickets, one at a time
Pick a ticket. The left side is the record. The right side is what would fire, using only what is known when the ticket arrives.
What an owner sees, and what happens if they don't answer
A mock of the chat message, driven by the same clock logic the tests cover. The timings are illustrative. In the real rollout each receiving team sets its own target.
The obvious paging rule pages for a password reset
Four tickets in the sample are organisation-level outages. Compare how three rules treat them. A false page costs more than it looks, because muted pagers are how this company got here.
Read this as a sanity check, not validation. The recommended rule was designed by reading these same tickets, and there are only four outages. Tier here comes from the notes, so it can't test false pages: T-4817 avoids a page only because its note names no enterprise. With real Salesforce tiers an enterprise password reset would match, so production also needs a field that separates "my password" from "our organisation is locked out". The ticket category stands in for an issue-type field that doesn't exist yet, and org tier assumes the Salesforce sync works. Email senders can't fill in that field, so email needs an agent's P1 macro by day and a subject-keyword trigger after hours. Customer message text isn't in the data, so the keyword trigger is untested.
Could a rotation carry this?
The sample can't give a page rate, so these are assumptions to change. Week 1 replaces them with real numbers from the full export.
On call means one person holding the pager for the whole week, so everyone in the rotation takes this load on their week.