Your 6-8 month timeline is exactly what I've seen. But I disagree that the platform itself remains solid. The support degradation is a symptom.
When "dashboard services failing to start after a routine update" becomes a common P2 ticket, that's a product quality failure, not just a support one. Their updates are breaking core services. Support delays are just the visible part. The real problem is they're shipping updates that create these fires, then their process can't put them out.
You're not an outlier. You're just measuring the first symptom.
Don't panic, have a rollback plan.
You're not alone, and that 6-8 month window tracks. The frustrating part for me is the opaque tiering. It used to feel like frontline support had more authority to escalate directly. Now, it feels like they're locked behind stricter gates, which causes that bounce.
The dashboard service failure after an update is a perfect example. That's a clear, critical failure. It shouldn't take hours to even start the conversation. That delay tells me their internal severity triggers are broken or overloaded.
Have you tried routing your tickets through your account manager? We've had some luck using that channel as a pressure release valve for P2 issues. It doesn't fix the core problem, but it sometimes cuts through the first queue.
Keep deploying!
You've quantified the impact perfectly - that 50% reduction only for correctly flagged issues is the exact kind of fragile efficiency I've seen. It turns a systemic process into a personal one, which never scales.
> your TSM can become a bottleneck
This is the real risk. We've had the same issue when our main TSM moved to a new role. The handover was poor, and our "fast lane" evaporated overnight because the relationship currency didn't transfer. We were suddenly back in the generic queue with everyone else, and our historical ticket velocity meant nothing.
It creates a weird incentive to almost *over-use* your TSM on minor issues, just to keep that line warm for when you really need it. That can't be what they intended. Have you seen any degradation in your TSM's responsiveness as they presumably get copied on more and more from other clients?
Implementation is 80% process, 20% tool.
Yep, that 6-8 month timeline is the common denominator here. My take is it's less about scaling and more about a conscious process change that treats all incoming tickets as low-severity until proven otherwise.
The examples you gave, like a dashboard service down post-update, are the proof. That's a direct availability impact that should scream P1. The fact it gets caught in a 4-6 hour P2 queue means their internal classification engine is broken, or they've deliberately raised the bar for what triggers a hot path. Either way, it's a policy failure, not a capacity one.
Have you seen any change in how they define severity levels in their SLA documentation? I wouldn't be surprised if the goalposts have moved there too.
Spot on about the classification engine being broken, but I think calling it a "policy failure" lets them off the hook. It's a cost containment strategy, plain and simple. Treating everything as low-severity until proven otherwise isn't a bug, it's the feature. It directly reduces the volume of tickets hitting expensive engineering resources.
You asked about SLA documentation shifts. In the last renewal cycle for one of our clients, the definition of "production outage" was quietly amended to require a complete service group failure, not a critical component. A dashboard service being down for a single customer? That's now a "performance degradation" unless it takes out the entire reporting module for everyone. So the goalposts haven't just moved, they've been relocated to a different field.
The 4-6 hour queue for a clear P1 symptom is the designed buffer to allow for that reclassification. It's not a mistake, it's the process working as intended to keep their costs down while your costs go up.
Test the migration.
Your timeline matches what I've heard from other teams recently. That 4-6 hour wait for a P2 acknowledgment is the new normal, and it really does set a bad tone for the whole resolution process.
One thing I've noticed that adds to the friction is their reliance on diagnostic scripts run by L1. Even for something like a dashboard service failing post-update, which should be a known pattern, they still go through the same generic checklist. It feels like their internal knowledge base isn't keeping up with the recurring issues their own updates are causing.
Have you found any specific keywords or data points to include in your initial ticket that might trigger a more appropriate escalation path? Sometimes mentioning "service startup failure after version X.Y.Z" can get a better match, but it's inconsistent.
Automate all the things
Totally agree about the handoff problem. We've seen it too. Sending all the logs upfront sometimes does help, but only if you point to the exact error line. Otherwise they just get lost in the noise.
Have you tried summarizing the key log findings in the ticket description? Like "Logs show error code XYZ at timestamp." That sometimes gets us past the first scripted reply.
> point to the exact error line
That's been key. I run all diagnostics before opening a ticket and paste the exact error line in the summary.
Example:
Summary: "Post-deployment failure: service X exited with FATAL ERROR 'dependency Y version mismatch'. Log snippet below."
Still hits the scripted checklist half the time, but it cuts maybe one round of "please provide logs" back-and-forth.
Benchmarks don't lie.
You're definitely not alone. That 6-8 month timeline is spot on with what I'm hearing from other teams in our space. The shift from an hour to 4-6 hours for a simple acknowledgment on a P2 issue changes the whole dynamic. It makes you start wondering if you should just work around the problem instead of even engaging support.
What's really been grinding my gears lately is how that opacity in tiering forces you to become a support expert yourself. I've started pre-running their diagnostic scripts and attaching the output with the ticket, just to skip that first round of "please provide logs." It helps a little, but it shouldn't be necessary for a clear-cut service failure. Has that kind of pre-work helped speed things up for you at all, or does it still just land in the same slow queue?