I've been a Netskope ZTNA user for about three years now, primarily to secure access for our on-call engineers to internal monitoring and incident management tools. The product itself has been solid for our use case, integrating cleanly with our existing IdP.
However, I've logged a noticeable and concerning trend in their support responsiveness. A year ago, opening a ticket for a configuration issue or a weird traffic log would typically get a first response within a few hours, often with a useful engineer who understood the context. Now, the initial automated acknowledgment comes quickly, but the first *meaningful* human engagement often takes **24-48 hours**.
For our night shift, this is a real problem. When we're troubleshooting an incident and hit a ZTNA roadblock, we can't afford to wait a day. We've had to build workarounds because we can't rely on timely support.
Specific examples from my tickets:
* **Feb 2023:** Ticket about mismatched SAML attributes. First human response with diagnostic steps: **3 hours**.
* **Nov 2023:** Ticket about a policy engine API timeout. First human response asking for basic logs we'd already provided: **28 hours**.
* **Last week:** Query about a new client app version compatibility. Still just an auto-acknowledgment after 18 hours.
I'm curious if others are seeing this. It feels like a classic case of a company scaling without scaling its support structure proportionally. For a product that's meant to be a critical security control, this degradation is worrying. Have you found any particular severity level or contact path that gets better results?
zzz
Sleep is for the weak
Agreed, but this is the playbook for any vendor scaling past startup phase. Their initial "few hours" response was likely loss-leader support to land accounts.
The real question is what's in your contract. Guaranteed response times are usually tied to severity levels and cost extra. If you're on a standard tier, expect this to keep degrading.
For night shift, you need a mitigation strategy they can't control.
* Documented rollback procedures for config changes.
* Failover to a secondary, simpler access method (IP allow list on a temporary bastion) for critical systems.
* Full packet capture ready to go for any support ticket. Forces their hand when you can prove it's their stack.
Show me the methodology.
The "loss-leader support" theory is convenient for the vendor, but it's a bit of a cop-out. Degrading a core service function after the sale is a reputational debt they're choosing to incur.
Your mitigation points are correct, but they're workarounds for a broken SLA. If the contractual response time for a P2 is "4 hours" and they're hitting 48, that's a breach, standard tier or not. The packet capture trick is good, but it shifts the burden of proof onto the customer. We shouldn't need a courtroom-level evidence pack to get a vendor to look at their own logs.
Has anyone actually clawed back a meaningful credit for these kinds of misses, or do the account managers just smooth it over with apologies?
- Nina
You're right that contract terms are the only real leverage, but I've found even guaranteed SLAs get fuzzy in practice. The "4 hour response" often means an auto-reply from a system, not an engineer reading the ticket.
The mitigation strategies are practical, but they create operational debt. Standing up a temporary bastion or maintaining rollback docs for every config change becomes its own support burden. It feels like we're building a parallel, redundant support org inside our team.
Has anyone had success using these workarounds as negotiation points with their account manager? Like showing the concrete extra hours your team is burning to compensate for their slow support, then asking for a service credit or upgraded tier? Sometimes making the hidden cost visible changes the conversation.
~jason