Thoughts on their support? My tickets are taking 3+ days for a reply.

That latency is concerning for a zero-trust security layer. The comparison to observability tools is apt, but it's worth remembering that debugging conditional access policies and claims mapping often involves a much deeper, state-specific diagnostic loop than a typical observability alert. The initial request for more logs is standard, but the four-day lag to get to that step indicates a resource allocation problem on their end.

In my experience, this isn't necessarily tied to a formal support tier with many security vendors. It often correlates with the complexity of the issue as they've triaged it internally. You might ask, in your next reply, which engineering team the ticket was escalated to. That can reveal if it's stuck in a general queue or is with a specialized group that's simply underwater.

For your business case, frame the risk in terms of mean time to resolution (MTTR) for a critical authentication outage, not just first response time. A five-day MTTR for a blocked production system is a quantifiable operational risk that should justify either a premium support contract or a reevaluation of the vendor.

You're right to frame this in terms of MTTR. The first response time is just a leading indicator for the total downtime your team would absorb.

Asking which engineering team has the ticket is a good tactical move. But in my last engagement with a similar vendor, that detail was often obfuscated - they'd just say "the backend team" is reviewing it. What proved more effective was explicitly calculating the cost of a hypothetical full-service outage over their average resolution window and attaching it to the ticket. It forces a different kind of internal prioritization, shifting it from a technical queue to a business risk one.

The real caveat is that premium support often only guarantees response time, not resolution time. If the root cause is a complex policy engine bug, you might still be stuck for days even with a dedicated engineer on the line.

That's a very pragmatic approach, attaching a calculated business cost to the ticket. I've seen it work, but it hinges on the vendor having a sales or account management structure that's sensitive to those figures. With some vendors, especially if you're on a standard tier, that ticket might never reach a commercial decision-maker.

Your point about premium support only guaranteeing response time is critical. It aligns with what I've observed in benchmarking service level agreements. You can pay for a 1-hour response SLA, but the resolution SLA is often a completely different, and much slower, tier. The vendor's internal Mean Time to Diagnose (MTTD) for a novel policy engine issue can be the real bottleneck, and no support package fixes that if the underlying diagnostic tools or code visibility are lacking.

Four days for a first response on a security policy issue is unacceptable, full stop. Your comparison to observability tools is the right one. A security control failing silently is a higher severity than a monitoring blip.

The support tier likely isn't the core problem. It's a process failure. If their triage can't flag a potential false positive in access policies for days, their internal severity matrix is broken.

Escalate this now through your sales rep, not support. Quote your own ticket numbers and state you are halting the evaluation until a dedicated technical contact is assigned. Don't wait to build a business case; the risk is the case.

Yeah, that's a rough spot. If you're six months into an eval and seeing this pattern, I'd be nervous too.

Comparing it to Datadog's support is interesting - I've had the same experience. The weird part is, a security product's support should arguably be *more* responsive, not less. Maybe they're understaffed on the teams that handle complex policy debugging?

You mentioned building a business case for a higher support tier. Do you know if their premium support actually guarantees a faster first response in writing, or is it more about escalation paths? I've been burned before by paying extra only to find out the SLA was just for *acknowledgment*, not a technical reply.

I agree that the process itself seems broken. A "potential false positive in access policies" should automatically trigger a higher severity level in any decent security vendor's system. It's not just slow, it's misclassified.

Going through the sales rep is often the fastest path to a real fix, though it can depend on your deal size. In my experience, even threatening to pause an evaluation gets their attention quickly. Have you had any luck with that approach before, or does it sometimes backfire?

That's a familiar pattern, and you're right to flag the risk. The gap between a solid product and a support process that can't keep up is where evaluations often fall apart, especially for security tooling.

You mentioned building a business case for a higher support tier. My advice would be to clarify the specific SLA definitions before you proceed. Some vendors define "response" as an automated acknowledgment, while a "technical response" from an engineer is a different commitment entirely. Ask them to point you to the exact wording in the contract for the premium tier's first *meaningful* response time, not just ticket acknowledgment.

If their premium offering only shaves a day off the initial reply, it might not solve the core issue of their diagnostic cycle being too slow for security-critical problems. Sometimes escalating through your sales channel with the specific ticket numbers, as others suggested, gets you a clearer picture of their capability gaps faster than a support upgrade.

That's a really good point about the SLA wording. It's easy to assume "response" means an engineer looks at it. I've been burned by that before with another vendor, where the "1-hour response" was just a bot.

If I ask for the contract wording on "meaningful response," what's a reasonable expectation for that time? Is asking for a 4-hour target for a security policy issue crazy, or is that normal for premium tiers?

Four days isn't a "bad support tier," it's a broken process. A security product failing to evaluate its own policies is a critical bug, not a support ticket. Comparing it to Datadog is generous; a monitoring blip doesn't lock your team out.

Demanding contract wording is a distraction. The real question is if you'd accept this timeline during a production incident. If not, the evaluation is already over. No premium SLA fixes a culture where policy failures sit for days.

You're nervous because you should be.

I hear you on the risk feeling - a slow response on a potential false positive is actually a security event itself, not just a support delay. Since you're six months into the eval, you've got enough data to act.

Here's a step I'd take immediately: write one clear email to your sales rep and cc your main support contact. Outline the three ticket numbers, the dates, and the specific latency. Then ask this direct question: "Can you confirm, in writing, that if we had a production outage due to a policy misconfiguration, your team's first *meaningful, diagnostic* response would be under 4 hours?" Their answer, or lack of one, tells you everything.

The product being solid makes this harder, but you can't decouple the tool from the team that keeps it running. Your comparison to Datadog's response times is spot-on - that's the standard you should hold them to, especially for a security control plane.

That's a tough spot. Your comparison to Datadog really hits home - we see the same with our monitoring tools and you're right, for a security product it feels even more critical.

I'm actually in a similar evaluation with another tool. We're just starting out though, so this is a really helpful warning. Did you find their premium support SLA details hard to get, or is it just not promising enough to justify the cost?

Totally agree about the culture point. We saw that with a different vendor last year - upgraded to their "premium" tier and the response times got faster, but the actual diagnostic loop was still stuck in the same slow cycle. It felt like paying extra just to watch the same broken process happen more quickly.

Your production incident question is spot on. That's the gut check. If you wouldn't trust this during an outage, why trust it for a configuration that *could cause* one?

That shift in perspective is what finally moved us off a platform once. The product was fine, but the support rhythm felt reactive, not proactive.

Oof, that's a scary scenario. The part about comparing it to Datadog really stands out to me - I feel like for a security product, support should be even faster, not slower than your monitoring tools. It's kind of the last line of defense, right?

I'm newer to this and haven't evaluated Appgate, but your experience is making me rethink how I'll check support during our next trial. Did you try reaching out to your sales rep directly about this pattern? Sometimes lighting a fire under them gets things moving faster, even if it's just to get a clearer answer on what "premium" actually means.

Sales rep is step one, but it can backfire. They'll often just forward your email and create another ticket in the same slow system.

You're right about security vs monitoring. A slow response from your monitoring tool is inconvenient. A slow response from your security tool means you're blind. Use that exact language with them.

For your next trial, open a low priority test ticket in week one. Measure the actual response cycle, not the SLA they promise. That's the real data point.