The 31% Breach Rate That Nobody Believes

Treat the 31% as a measurement problem until proven otherwise. Checks in order of cheapness and likelihood:

1. Does the milestone start where you think? Entitlement milestones start relative to case creation (or the configured start), not on assignment or first outbound reply. Confirm what counts as 'first response': a public agent reply, an internal note, an automated acknowledgement, or a macro-driven email. Ambiguity here alone can explain a large breach delta.
2. Business hours. Every region is measured against the North America calendar. An APAC case raised Friday evening local time burns hours it never had. Fix region-specific business hours and holidays first - cheapest change, biggest effect.
3. Pausing behaviour. If agents believe the clock stops in 'Waiting on Customer', verify how that is implemented and whether the milestone actually reaches a paused state. If nothing pauses it, agents are being measured on wall-clock time while they wait on the customer.
4. Entitlement selection. Cases with no entitlement or the wrong one get no milestones or the wrong ones. Report on cases where entitlement lookup failed to fire.
5. Report logic. Check whether the report filters on case created date or milestone completion date, and whether it counts milestones that were never started. Open cases with an unstarted milestone are not breaches.
6. Timezone and display settings in the report versus what the agent sees in the console.

Only after 1-5 are ruled out does this become a performance conversation - and because leads are adamant, you owe them the check before you say it.

Two different defects with one shared root cause: the email thread is being treated as the unit of work instead of the conversation.

Owner history

• Do not rely on the owner field to carry history. Enable field history on Owner and put Case History on the console layout so reassignments are visible.
• If follow-the-sun handoffs are routine, model them openly: regional queues, ownership changes driven by Omni-Channel, and case teams for the humans involved.
• If 'original assignee' matters for credit or escalation, store it in a custom field populated by flow on first assignment. The platform will not remember it for you, and reconstructing it later from history is painful.

Duplicates

• Enable duplicate rules on Case with a matching rule combining contact/email and subject similarity, so agents get a warning at creation. Use warnings rather than hard blocks: blocking case creation drops real customers.
• Fix threading at the source: match inbound email on thread and message identifiers before creating a case, and attach the email message to the existing case when it matches. One conversation, one case.
• Merging is destructive - merged-away cases are deleted and cannot be unmerged. So define the survivorship rule (oldest with the most history, or the one carrying the entitlement), make merging a supervisor action with a note, and use it as an exception rather than a workflow.
• Track merge rate weekly; if it stays above roughly 5%, the threading logic is still wrong, not the agents.

400 alerts a week concentrated on a few accounts is an alerting design problem: the rule is keyed on a condition a small set of accounts permanently satisfies.

Redesign around three questions - who must act, how fast, and what do they do?

• Do not use escalation rules as a second SLA. Milestones already measure time. Escalation should fire on a state that requires a decision: unassigned beyond X business hours, priority raised by the customer, milestone breached with no owner activity, or a VIP account with a reopened case.
• Qualify on severity, not account size. Add severity and business-hours awareness so the rule does not re-fire overnight or over a weekend, and enforce one escalation per case per level. Re-firing is what trains people to ignore alerts.
• Route to a queue, not an individual. An escalation landing in one manager's inbox is lost when they are on leave. Send it to the tier-2 queue, keep the original owner and notify them.
• Handle the concentration explicitly. If the same accounts generate most alerts, the fix is an account review or a named escalation path for those accounts, not more rules.
• Instrument the outcome: escalations raised vs accepted vs resolved, and time from escalation to first action. Target a volume at which every alert is actually read - that is the success criterion, not zero alerts.

Judgement call to state out loud: the 5% breach target is achievable through measurement and business-hours correction alone, so present escalation redesign as a quality-of-service change, not as the mechanism that hits the number.