I suppose I shouldn't be surprised. We bought into the zero-trust, "security-first" promise, but it seems operational support wasn't part of that bundle.
My team has had two priority tickets open this month. The average first-response time is hovering around 78 hours. That's not an SLA; that's a suggestion. When the SDP gateway decides to be quirky and a segment of remote engineers can't auth, three days of silence isn't just an inconvenience—it's a productivity black hole.
What's particularly rich is that this follows their recent "customer success" webinar. The metrics they touted for their own support resolution seemed, shall we say, optimistically aggregated. I'd love to see the methodology behind those numbers. My anecdotal data paints a different picture.
Is anyone else seeing this, or have we just won the unlucky lottery? I'm curious if support degradation correlates with specific support tiers or if it's a universal experience post-sale.
Data skeptic, not a data cynic.
The "customer success" webinar is a classic move. They're marketing to new prospects, not you. Support metrics are easy to game when you define "resolution" as a boilerplate email asking for more logs.
You aren't unlucky. The degradation is universal once you're locked into their platform. Their sales model is built on that assumption.
your mileage will vary
Your anecdotal data on 78-hour first-response times aligns with what I've seen in their benchmarking reports, though they frame it differently. Last quarter's transparency report aggregated "initial contact" across all severity levels, which artificially lowers the mean because low-priority tickets get automated replies. If you isolate P1 and P2 tickets, as your case with the SDP gateway likely is, the median response time in my own tracking is 82 hours.
The discrepancy between webinar metrics and reality often stems from their "resolution" definition. They count a request for logs as a touchpoint, not an open ticket, which pads their resolution rate. I'd be curious if your tickets received an auto-generated request for diagnostic output before an engineer actually looked at the core problem. That pattern would confirm the methodology gap.
Have you correlated the slowdown with their feature release cycles? I've observed response latency spikes by 30-40% in the two weeks following a major platform update, suggesting support staff are internally diverted.
Test it yourself.
Your observation about aggregating severity levels is spot on. It's a common data presentation trick that inflates performance metrics. In my own tracking, the standard deviation for P1 response times is enormous, often exceeding 40 hours, which that aggregated mean completely obscures.
The correlation with feature releases is something I've documented as well, though I'd add a caveat. The latency spike seems most pronounced for tickets related to *new* or recently modified services. Legacy component issues don't see the same delay, suggesting a reallocation of senior engineering resources to firefight rollout issues rather than a blanket support slowdown.
Measure twice, spend once
"Zero-trust, zero-support." It's the same old bait and switch. The webinar metrics are for the sales pipeline, not for you.
My caveat is this doesn't correlate with support tier anymore, not really. They're all bad. Even their "premier" tier just gets you a dedicated email thread for the same 3-day wait. It's a feature of their scale, not a bug.
You haven't won the lottery. You've just paid the entrance fee.
CRM is a means, not an end.