The Dashboard That Says 92%

They are measuring different clocks, and probably different denominators.

• Paused timers. A case parked on Waiting on Customer stops its milestone clock. It can sit a week and never breach. The external tool almost certainly measures wall-clock time.
• Denominator. Cases with no entitlement have no milestones and are invisible to any milestone-based percentage. At 1,200 cases a day, a 15-20% entitlement coverage gap is entirely plausible and would flatter the dashboard enormously. Report unentitled cases as their own line before anyone quotes a compliance number.
• Business hours. Milestones use the entitlement's business hours, which override the 24/7 org default. If the external tool uses 24/7 or a different holiday calendar, every figure differs.
• When the clock starts. Milestones attached by an entitlement process at creation start immediately. If a flow or an agent attaches the entitlement later, the timer starts late and hands the case free time retroactively.
• First response completion. Only the first outbound public comment completes it. Internal notes and logged calls do not, so agents who answer by phone can breach a milestone they actually met.

First check: entitlement coverage by channel. Then rebuild the headline number from CaseMilestone using TargetTime versus ElapsedTime in the correct business hours, and only after that compare to the dashboard.

Do the arithmetic first. 1,200 cases across 500 agents is about 2.4 cases per agent per day. Capacity is not the constraint; presence, skill match, and queue design are.

What is wrong

• A single queue broadcasts tier-2 and tier-3 work to tier-1 agents, who accept it and immediately transfer it. Each transfer adds handling time and distorts your metrics.
• Capacity of 3 applied uniformly ignores that a tier-3 case and a password reset are not the same unit of work.

Redesign

• Split queues by tier and severity, and add skills for product and language if the mix justifies it. Skills-based routing needs Service Resources and Omni-Channel skills configured first.
• Choose the routing model deliberately: Least Active spreads work evenly across a large pool; Most Available concentrates work on the least-loaded agent and can starve new hires; Least Amount of Work respects capacity weights. For 500 agents in a pool, Least Active is the usual default.
• Set queue routing priority so entitlement-critical cases are offered before general work, and use an Omni-Channel flow if routing depends on case fields.
• Size capacity per queue and weight voice far heavier than cases if agents handle both.

Operational trap: if capacity is set below real concurrent load, agents hit max capacity and work silently expires to the next agent, or fails to route at all. Monitor longest wait and agent status from day one.

Escalation rules are the wrong instrument here. They run on case age and last modification time, they are blind to milestone pauses and to entitlement business hours, and they can only reassign, notify, or run a small set of actions. On this org they would fire on cases that are legitimately waiting on the customer, generate alerts nobody reads, and re-escalate on every modification.

Use milestone actions. They fire off the milestone timer itself, honor pauses and the correct business hours, and can update fields, send email alerts, and post to Chatter. That is the same outcome with the correct clock.

If the VP wants warning before breach, create an additional milestone that completes at, say, 3 business hours against the 4-hour target, and hang the notification off that. That gives a proactive signal tied to the same timer the SLA is measured on.

Where escalation rules still earn their place: hygiene that isn't milestone-measured, such as cases with no owner or no activity in 24 hours. Keep them narrow-one per object per active rule set-so they don't compete with the milestone actions.