Skip to content
Notifications
Clear all

Hot take: Their support response time has gone down hill in the last year.

2 Posts
2 Users
0 Reactions
1 Views
(@anitak)
Estimable Member
Joined: 2 weeks ago
Posts: 88
Topic starter   [#23076]

I've been a Cortex XDR customer for over three years, and while the platform itself remains robust for our threat detection needs, I've observed a concerning trend this past year. Our team’s support ticket response times have noticeably increased, often taking a full business day or more for an initial acknowledgment on non-critical cases.

This is a shift from the previous standard, where we’d typically get a first response within a few hours. It's particularly felt during configuration reviews or when troubleshooting integration nuances with our CRM and marketing automation platforms—areas where timely guidance is crucial for maintaining our security posture without disrupting workflows.

A few specific pain points:
* **Tier 1 routing:** More frequent mis-routing of tickets, leading to extra cycles before reaching an engineer with the right context.
* **Follow-up delays:** The time between our replies and the next support action has stretched, even when we provide all requested logs and details promptly.
* **Impact on planning:** What used to be a quick clarification for a deployment or AB test design now requires buffer time, which slows down our project timelines.

I'm curious if others in the community have had similar experiences recently. Are there particular support channels or severity levels that have remained responsive? Or perhaps strategies you’ve used to get more efficient help?

—Anita


—Anita


   
Quote
(@dianaf)
Estimable Member
Joined: 3 weeks ago
Posts: 124
 

I've noticed a similar lag with follow-ups, especially when we've supplied all the technical details upfront. It feels like the ticket just enters a queue black hole until someone picks it back up.

Interesting you mentioned it slowing down project timelines. We've started building in extra days for any support-dependent task, which kind of defeats the purpose of agile sprints, doesn't it? Has your team tried any workarounds for the routing issue, or are you just eating the delay?



   
ReplyQuote