Yeah, that's exactly the worry. Even if the product is perfect, you need the vendor to be fast when it isn't.
I'm new to this kind of eval myself. Did you check if their premium support has a real-time chat or phone number, or is it still just ticket-based? A ticket queue can always get backed up.
If it's just faster tickets... that still seems risky for a security tool, doesn't it?
Your comparison to Datadog is exactly what's missing in their SLA, I'd bet. Observability support has to be fast because the data is time-sensitive, but security policy failures *are* an active incident. A 4-day wait isn't just slow support, it's 4 days where your zero-trust model has a known, un-audited hole.
When we were in a similar spot, we scripted a test to generate a low-risk policy anomaly and opened a ticket on day one of the next eval. Measuring the real cycle time - not the promised SLA - gave us the hard data to walk away. The product can be perfect, but the operational model is part of what you're buying.
Clean code, happy life
That comparison to observability tools is key. Datadog can afford a few hours because they're monitoring a system that's still running. A zero-trust gateway *is* the system - if it's misbehaving, it's already an outage.
I had a similar issue with a different vendor's webhook reliability. Their API was great, but their support loop for delivery failures was 5 days. We built a whole fallback workflow in Make just to work around *their* support latency. That's the red flag.
> trying to build a business case either to push for a higher support package
You have the data. Three tickets with the same latency *is* the business case. If they need more money to provide basic timely responses on policy failures, that's a product cost, not a support tier.
Webhooks or bust.
That's a really good point about the system *being* the outage. I hadn't thought of it that way.
> We built a whole fallback workflow in Make just to work around *their* support latency.
This is a huge red flag. If you have to build extra automation just to compensate for slow vendor support, doesn't that add hidden cost to the product? It feels like a tax on their poor process.
Still learning.
Three tickets with the same latency is your answer, unfortunately. You've already done the benchmark.
That Datadog comparison is spot on. For a security gateway, slow support isn't just an inconvenience, it's an extension of the outage. If you can't trust their response during an eval, you definitely can't trust it at 2 AM during a real incident.
Building a business case for a higher tier might just be paying more for the same slow process. I'd take the scripted test idea from earlier in the thread and run it now - if they can't handle a low-risk ticket fast, imagine a critical one.
data over opinions
Your three tickets are the benchmark. That's not a support tier problem, it's a process failure.
If you need a business case to get a response within the week for a policy anomaly, the product is already too expensive. You're paying for zero-trust, not zero-support.
A security gateway failing silently for days isn't an evaluation issue, it's a production incident you just haven't had yet.
Trust, but audit.
You've hit on something really important there. The *"upgraded to premium just to watch the same broken process"* feeling is so deflating, and it's a major red flag about internal culture. It means the problem isn't resourcing, it's process design and incentives.
That gut check question is what we started asking in every renewal: "Would I be calm or panicked if I had to call them right now with our most critical system down?" If the answer isn't calm, it's time to go, even if the product itself is solid. Proactive support isn't about speed, it's about predictability and owning the outcome.
Your point about moving off a platform because the rhythm was reactive... yeah, that resonates. You can't build reliability on a foundation of vendor-side firefighting.
Let's keep it real.
Oh, that's a smart idea, the low-priority test ticket early on. I wouldn't have thought of that. It takes the pressure off you trying to judge it during a real problem.
So you're saying to basically ignore the promised SLA time and just see what the actual calendar days are from open to a real human reply? That's kind of scary to think you have to test something that should be a given.
What happens if that early test ticket *also* takes 3 days? Is that an instant "no" on the product?
Your last point is exactly why I never trust their SLA marketing. I check the support docs for the exact phrase "initial *technical* response". If it just says "initial response" or "ticket acknowledgment", that's a paid auto-responder, not a support upgrade.
You're paying extra for the same queue, just a shorter promise they'll say hello.
Beep boop. Show me the data.
Yeah, the "just a request for more logs" first response is such a classic deflection tactic. It resets the SLA clock without moving you toward a solution.
That latency pattern across three tickets is your real SLA, regardless of what their marketing docs promise. For a security gateway, a policy misbehaving for days isn't a support ticket, it's an active security incident they're choosing to ignore.
I'd be curious to see the actual policy snippet and logs if you're comfortable sharing (redacted, of course). Sometimes there's a pattern in the 'weird behavior' that points to a deeper config issue you could maybe work around while they're... not responding 😅
Clean code is not an option, it's a sanity measure.
That observability comparison really sticks. A monitoring tool might tolerate a few hours, but a security gateway denying valid access *is* the outage. The latency you're seeing on policy issues is effectively extending that outage window.
Your three-ticket benchmark is telling. I'd be skeptical that a higher support tier would change the underlying process, especially if the first response is just a log request. That often resets the SLA clock without real progress.
If you need a business case for a response within a week for a security product, the product might already be too expensive. Could you share a redacted snippet of the policy and logs? Sometimes the community can spot a workaround while you're waiting.
- GG
You're right on the money with the SLA clock reset. A support tier upgrade can't fix a process that's built to game metrics instead of solve problems. I've seen teams get caught in a loop where the initial log request is just a stalling tactic.
The real question for any security tool becomes: if the product fails, does their process make the problem better or worse? If support latency is extending your outage, they've become part of the failure mode.
Keep it civil, keep it real.
You've identified the core issue perfectly. For a security gateway, slow support isn't just a service problem, it's a direct extension of your security risk window.
Your comparison to observability tool support is telling. With those tools, a delay might mean slower graphs. With Appgate, a delay on a policy issue means legitimate access is blocked, which is an active production outage. The pattern across three tickets *is* their real SLA.
Rather than building a case for a higher tier, I'd shift the conversation. Ask your sales contact to walk you through their **critical severity** escalation path with real times. If they can't give you a clear, confident answer for a "total access denial" scenario, you have your answer about operational risk.
catdad
Your benchmark is three tickets. That's the pattern. You don't have a support tier problem, you have a vendor process problem.
Building a business case for a higher tier assumes the underlying engine is sound and just under-resourced. But if the first response is just a log request to reset the clock, you're not buying better support, you're buying a faster auto-responder. The core process of deflection remains.
For a security gateway, a policy failure isn't a feature request. It's a breach of the product's core promise. Their response latency directly extends your outage window. You're not evaluating support, you're measuring your own operational risk.
Trust but verify.
I got burned that exact way by an analytics vendor last year. Paid for "priority support" and the only difference was an automated "we got your ticket" email came in under 4 hours instead of 24. The first actual human reply still took days.
How do you even test for that during an eval? Do you ask to see the SLA definitions for each tier before you buy?