Unpopular opinion: Their support tier system means you get slow responses unless you're huge.

Yeah, this matches what I've heard from other teams. The tiered system is pretty standard, but it stings when you're mid-size and a real issue is blocked.

Have you found any workarounds, like escalating through your account manager for critical tickets? I'm curious if that actually helps or if you just hit a wall.

Escalating through your account manager is a dead end. They're sales, not support. Their only leverage is the threat of non-renewal, which doesn't move the needle on a daily ticket.

Your real workaround is in your contract. Negotiate specific SLAs for severity-one issues before you sign, regardless of your tier. If you didn't do that, you've accepted the queue.

You're right about account managers being sales, but I've found they can sometimes grease the wheels if you've got a decent relationship. It's not about them solving the ticket, it's about them pinging the support manager on Slack to ask for a status check. That's gotten a ticket moved up the queue for me a couple times.

But your contract point is the real fix. It's hard to negotiate that later, especially if you're mid-size. You've got to push for it during the procurement hustle, even if it feels like you're being difficult. A clause for "initial human response within X hours for severity 1" is what you're after. If they refuse, that tells you a lot about their priorities.

Without that clause, yeah, you're in the queue with the rest of us. 😅

Exactly. The premium for fast support is just rolled into the higher tiers. It's a feature, not a bug.

> budget for the higher support tier from the start - it's not optional if you need reliability

This is the key. You have to price that uplift into your total cost of ownership from day one. If you don't, you're accepting the risk. The "standard" plan is effectively a best-efforts queue.

We treat it like an insurance premium. If your service is critical, you pay for the faster response. It stinks, but that's the model.

Agree it's an insurance premium. The part most teams miss is quantifying the cost of that queue. A 24-hour delay on a severity-one security finding isn't just an inconvenience, it's an exposure window you have to price in. Your effective cost is the license plus the risk.

We model it by estimating mean time to resolution across tiers from historical tickets, then multiplying by the hourly cost of an outage or security incident. It usually makes the support tier uplift look cheap.

The pattern you've laid out isn't just a Prisma Cloud problem, it's the entire industry's open secret. That 24-48 hour window for a critical security finding you mentioned is precisely why I refuse to let any vendor's default SLAs slide into a contract unchallenged.

The new angle you're missing is that even when you get the "initial human response" clause negotiated, the vendor often fulfills it with a template email that says "we're looking into this." Congratulations, your SLA is technically met while your production issue burns. The real metric they guard jealously is *engineer-to-ticket assignment*, not a support drone acknowledging receipt.

So your advice to get it in writing is necessary, but woefully insufficient. You need the contractual teeth to define "response" as "meaningful technical engagement," and you'll find that's where the real pushback starts, because it costs them actual engineering headcount.

You're dead on about needing to define "standard" before you sign. I've seen teams get that initial response clause, only to have it met with a template "we've received your ticket" email.

The trick is to define "meaningful engagement" in your contract. Push for language that specifies a first contact from someone with the technical ability to troubleshoot, not just an acknowledgment. It's harder to get, but it's the only thing that moves the needle.

Your point about "meaningful engagement" is absolutely critical, and it's where most procurement teams get outmaneuvered. The vendor's boilerplate will always define "response" as an acknowledgment. The battle is over the definition of "technical resource."

I've had to push for an addendum that specifies the initial contact must be from an engineer whose title is within a specific band (e.g., "Support Engineer II" or above) and that the contact must contain a diagnostic question or a request for specific data beyond the initial submission. Without that, you're right, the SLA is a paper shield.

Even then, you have to audit it. We had to cite a breach of contract once because the "engineer" assigned was from a completely unrelated product line and their first question was answered in our initial ticket description.

You're spot on about the "technical resource" definition being the battleground. Pushing for a specific title band is a smart, concrete move.

A caveat from our experience, the vendor might counter with "operational flexibility" arguments. They'll say tying it to titles restricts their ability to assign their best person, even if their title is different. Be ready to define the required skill set or product certification instead.

That contract breach example is key. Without that audit and enforcement, the specific language is just words. Did you find a recurring penalty for repeated breaches was the only thing that got their attention?