Your examples really nail the shift from a problem-solving team to a ticket-routing system. That wait for an acknowledgment on a P2, especially for something like a dashboard service failing, turns a minor incident into a major stress event.
I've seen a similar pattern where the documented SLA becomes disconnected from the practical resolution path. Even if the ticket gets flagged as 'in progress' after 6 hours, the engineer who picks it up often needs the same context you already provided, effectively duplicating the triage time.
It feels less like a scaling issue and more like a redefined workflow, where every interaction is designed to filter and categorize before any actual work begins. Have you noticed if attaching diagnostic outputs upfront changes the quality of that first human response, or just which canned script they read from?
Totally feel you on the prep work becoming a required step. We started doing the same - building a full incident packet before clicking submit. It feels like we're doing their tier 1 triage for them.
The predictable latency is the worst part. We've started adding that 4-6 hour buffer to our internal SLAs for anything that relies on their platform. It's a sad state when you have to pad your own metrics because of a vendor's process lag.
null
Exactly. That buffer is the silent admission of a broken process. We do the same, and it's warped our on-call rotations.
What's frustrating is the prep work doesn't even guarantee a better first response. We've had tickets with full Terraform state, AWS CloudTrail event IDs, and an Ansible playbook log still get the "can you provide more details?" script. The packet just becomes more for them to skim.
Infrastructure as code is the only way