Unpopular opinion: SonicWall support has gone downhill post-acquisition.

You're right about the NAT issue timeline not being an outlier. I had a similar experience last quarter with a BGP configuration that was silently dropping routes. The script insisted on verifying physical connectivity for two full ticket cycles, even though the control plane session was established and logs showed the policy mismatch.

What's more telling is the metric shift. The old support model measured mean time to resolution. The new one seems to measure first-contact script adherence. When you optimize for the latter, you get exactly what you're describing: a 24-hour technical fix buried under three weeks of process theater.

The competent engineers are still there, but they're a constrained resource now, managed like a scarce data warehouse cluster. You have to queue and pay the latency cost before your query gets executed.

Your three-week NAT timeline isn't an outlier, it's a predictable outcome of a process now optimized for cost containment, not resolution. The shift from mean time to resolve to first-line script adherence is a classic metric-gaming maneuver.

Think of it like a poorly allocated Kubernetes pod: the resource (competent engineer) is still provisioned, but the request queue and admission controller (the script) are configured to starve it. You're waiting not for a fix, but for the process to exhaust its own checklist.

The real data point is the delta between that 24-hour fix and the three-week calendar time. That gap represents pure process overhead, and it's a measurable cost they've decided to externalize to the customer.

I don't think it's bad luck. The shift you're describing, from a resolution-focused model to a process-focused one, is a common symptom post-acquisition when cost metrics take priority. You're feeling the friction of that new filter.

The three week gap for a NAT issue is the real data point. That's pure process overhead they've offloaded onto your team's calendar. It turns every support request into a calculation of whether the problem is worth the access fee, which changes the entire relationship.

I've heard from others that being hyper-specific in the initial ticket, stating which basic steps you've already exhausted, can sometimes speed up the handoff. It's not a guarantee, but it occasionally helps the system recognize a ticket that's already cleared the first hurdle.

It's definitely not bad luck. That three-week NAT issue is the new normal. I see the same thing in the CRM world - when a company gets acquired, support often turns into a cost center where the first priority is following a script, not solving the problem.

The part about the broken escalation path is key. It's like their goal is to make you give up, not to get you an answer. Have you tried being extremely aggressive in your initial ticket title? Something like "ESCALATION REQUIRED: NAT config issue after exhausting all KB steps" can sometimes bypass the first script-reader.

Yeah, that aggressive title tactic can work. I've found success with "ESCALATION: Advanced BGP config issue, steps 1-5 from KB article #XXXX already completed." It preempts the first script-reader and sometimes jumps you to a more technical queue.

But there's a catch. If you overuse it on simpler issues, they start to ignore it, or worse, you get a grumpy senior engineer for a basic problem. It's a tool you have to deploy strategically, like saving a high-priority support token.

The real frustration is that we've all become amateur process analysts just to get to the actual engineering talent.

That's a really good catch about the wording change. I've mostly worked with SaaS tools, and I've seen that same slow shift from "guaranteed" to "target" SLAs in renewal contracts over the last couple years.

Does that kind of language change typically mean they can just drop their response targets whenever they want? Or is there usually still some minimum bar they have to meet, even if it's lower?

That Kubernetes pod analogy hits the nail on the head. The resource starvation is exactly what we're seeing across several monitoring platforms lately.

You mention the delta between the 24-hour fix and the three-week wait as the key data point. I'd push that a bit further: that delta isn't just overhead, it's the new pricing model. The "support" cost has been unbundled. You're now paying with calendar time instead of just the support contract fee.

Has anyone tried measuring that externalized cost internally? Like tracking the engineering hours spent queueing versus actually fixing? I suspect the total cost of ownership math for some vendors is looking very different now.

It's not bad luck, it's the new process. You're not calling support anymore, you're placing a ticket into their workflow queue, which is now optimized for first-call closure, not your problem.

That NAT issue timeline is the new normal. Three weeks for a 24-hour fix means you spent 20 days waiting for them to finish their checklist. The escalation path isn't broken, it's a design constraint. It's there to filter you out, not elevate you.

Their metric isn't MTTR anymore. It's average handle time and first-contact resolution. You got three weeks of handle time because that's what the script allows. Sucks, but it's predictable now.

You're spot on about the metrics change. In the CRM world, we see this when support shifts from measuring "case closed" to "first reply sent." It looks good on a dashboard but doesn't solve anything.

That "filter you out" line is especially true. It feels like the goal is attrition, not assistance. Have you found any reliable way to signal that a ticket has already cleared the basic script, or is it just luck of the draw now?

You're not wrong, but you're missing the real issue. This isn't about luck, it's about a fundamental change in the product you're buying.

That "competent engineer" you used to get on the line was part of the old bundled service. The acquisition just formalized the unbundling. You're now paying for the firewall software and a separate, deliberately constrained access pass to human expertise. The three-week NAT issue isn't a failure of the new system, it's the system working as designed to ration that expensive resource.

The broken escalation path is a feature. It's a cost valve. Your frustration is the intended output, because a percentage of people will just solve it themselves or live with the problem, which saves them money. Start calculating your total cost with those three weeks of your team's time included. The math gets ugly fast.

The Kubernetes pod analogy is perfect, and that delta *is* the new pricing model. I'm seeing the same thing with other vendors - support SLAs are increasingly just the script timer, not the fix timer.

You're definitely not having bad luck - that three-week NAT resolution is a pattern now. The real shift is in what they're measuring.

The old metric was "time to fix your problem." The new metric is "time spent on your ticket." When the support contract renewed last year, the SLA wording changed from "resolution" to "initial response" for priority levels. That's not an accident, it's a signal.

Your broken escalation path is working as designed. It's a filter, not a ladder. The goal is to consume calendar days, not engineer hours.

The unit test analogy is painfully accurate. A passing test that doesn't verify the right thing creates a false sense of security, just like a script that completes without diagnosing the problem.

You ask about tricks to skip steps. The harsh truth is there aren't any reliable ones anymore, because any effective bypass would be considered a defect in their script-driven process. The "aggressive title" tactic mentioned elsewhere is just gaming a system designed to be gamed, and they'll patch that loophole eventually too. You're not finding a shortcut, you're just discovering the current allowable input for their black-box triage function.

So yes, you play along. The waste isn't a bug, it's the product. The performative box-checking is the entire value of the first-tier contract you paid for.

Spot on about the unit test analogy. It's an exact parallel to measuring system health with vanity metrics that don't impact user experience. You're checking that a process ran, not that it achieved the desired outcome.

This creates a measurable, and frankly predictable, engineering debt. We've started quantifying it internally by tracking the delta between 'support ticket resolved' and 'underlying system issue resolved'. For our last five major vendor cases, that delta averaged 18 business days. The time spent on performative steps isn't just waste, it's a direct cost center that's been offloaded back to us.

The "allowable input" concept is key. Once you realize you're just providing parameters to their triage function, you can start to optimize for it, but as you said, that's just gaming a broken system. It turns problem-solving into a meta-game of reverse-engineering their script's decision tree, which is where the real frustration sets in.

>tracking the delta between 'support ticket resolved' and 'underlying system issue resolved'

This is such a good idea. I've never thought to actually measure that gap before. 18 days is crazy.

You're right that it just becomes a meta-game. I find myself writing tickets to anticipate the scripted questions now, not to explain the problem. It feels like we're all just learning to speak their triage language.

Do you share those delta numbers with the vendors during renewal talks? I wonder if that data ever gets back to them.