The 4-Hour Promise That Keeps Sliding

The clock depends on a field the channel does not populate at insert.

• At insert, account is empty on phone cases, so the Gold start condition is false and the Gold SLA does not attach. The standard 8-hour definition's condition (everything not Gold) is true, so it attaches immediately and starts timing.
• When the agent later sets the account, the Gold definition's condition becomes true and it may attach as well - either starting from the update, or retroactively from case creation if retroactive start is enabled. Either way you now have two competing SLAs on one case, and the number the report reads first is often the standard one.

Confirm by reading task_sla records on a sample of phone cases:

• Which definitions attached, at what time, and in what stage.
• Whether the standard definition has any cancel condition that fires when Gold attaches (usually not).
• Whether retroactive start is on for the Gold definition.

Spot-checking the timeline hides this because the standard SLA looks healthy - it is simply the wrong SLA.

Principle: never make SLA selection depend on a field a channel leaves empty at insert.

1. Make the account a creation-time input on every channel.
   • Portal: already collected.
   • API: make account ID a required payload field; reject with 400 and a clear message if missing.
   • Phone: a short creation playbook or case-type-driven form that captures account and requester before the case is inserted, rather than letting the agent save and fill in later.
2. Where a deferred fill-in is unavoidable, set retroactive start on the Gold definition so the start time reflects case creation, and add a cancel condition on the standard definition that fires when a Gold definition attaches - so you do not carry two clocks.
3. Prefer entitlement-driven SLA selection where contracts exist: the entitlement resolved from the account determines which SLA applies, which removes the hard-coded tier comparison from the SLA condition.
4. Regression test all three channels before release: one Gold case per channel, verify a single 4-hour task_sla with a start time equal to case creation.

The response clock measures time to first agent response. Pausing it hides the failure it exists to catch.

• If a case waits three days in Awaiting Info before an agent first replies, the customer experienced a three-day response. A paused timer reports a 40-minute response and the team looks compliant.
• Awaiting Info is a legitimate pause for the resolution SLA - the customer is the blocker on closure. It is not legitimate for response.

What to do:

• Remove the pause condition from the response SLA definition; keep it on resolution.
• Re-baseline: recompute last month's response attainment without the pause, expect the 38% figure to rise, and communicate the new number before anyone is measured on it.
• Report response attainment per SLA definition and per account tier, not an aggregate across definitions, so a mis-attached standard SLA shows up as a data anomaly rather than being averaged away.