Maybe I'm the only one who's noticed, but the quality of SonicWall support seems to have taken a nosedive since the acquisition by Francisco Partners. Used to be you could get a competent engineer on the line who actually understood the product.
Now? It's a script-reading exercise. Last ticket took three weeks to resolve a basic NAT issue that should have been a 24-hour fix. The escalation path feels broken. Anyone else seeing this, or am I just having bad luck?
trust but verify
I've heard similar concerns from other community members recently. Your point about the escalation path is something I've been looking into on my side. The transition period seems to have stretched longer than many expected, and it does impact the customer experience.
I've found that getting clarity on the exact support tier you're entitled to helps sometimes. It's not a fix, but it can manage expectations. Has your renewal come up since the acquisition? I'm curious if the support terms shifted.
Reviews build trust.
I've seen a few threads on this theme lately, so you're definitely not the only one. The shift to scripted responses is a common pain point.
Your three-week NAT issue example really hits home. It highlights how a broken escalation path can turn a routine fix into a major project. That's exactly the kind of thing that erodes trust.
I hope they can stabilize things soon. Have you had any luck finding workarounds, like leaning more on the community knowledge base in the meantime?
Keep it constructive.
Script-reading is putting it generously. Last time I called, it felt like they were just reading the public KB articles back to me, but slower. The real kicker is when you get that first-line person who clearly doesn't understand the difference between a policy-based NAT and a regular access rule. You can almost hear them clicking through the GUI, lost.
Your three-week NAT issue sounds about right. I had a similar mess with a VPN tunnel that wouldn't come up. The escalation path is a black hole now; they treat every ticket like a brand new problem, even if you have a case number from a month ago for the same firewall. It's not bad luck, it's the new system.
You're paying the same, or more, for what's essentially a community forum with a hold time.
prove it to me
>The escalation path is a black hole now; they treat every ticket like a brand new problem
This is the part that turns a support contract from an insurance policy into a pure cost center. You're not paying for expertise, you're funding a system designed to make you give up.
It's the same old private equity playbook: strip out the experienced, expensive staff, replace them with a low-cost script farm, and pray the revenue from locked-in customers outruns the churn. Sounds familiar to anyone who's watched a cloud vendor's premium support tier get hollowed out post-launch.
They know you won't switch firewalls over a few bad tickets. That's the calculation.
-- cost first
You're right that understanding your support tier can manage expectations, but that's kind of the core of the frustration now, isn't it? We're having to learn how to work around a degraded system instead of getting the service we're paying for.
On the renewal question, our last one did have subtly different wording around "target response times" versus the old "guaranteed" language. It felt like they were building in more wiggle room for exactly these kinds of delays. I'd be curious if others spotted that too.
ian
Your three-week NAT issue is exactly the kind of thing that worries me. I'm just starting to look at migrating some older on-prem stuff to the cloud, and hearing about broken escalation paths makes me nervous. If I can't get timely support for a known firewall, how do I plan a realistic timeline for a complex migration?
Was it hard to even get them to acknowledge it was an escalation-level problem?
One step at a time
Hard to get them to acknowledge anything as urgent now. Their tier system just filters you into longer queues.
You're right to be nervous about planning a migration. We're adding buffer we never needed before - doubling the estimated time for any task that might need support.
My last escalation took a week of daily calls just to get a "maybe" on moving the ticket up. Plan your project timelines accordingly.
Optimize or die.
You're not having bad luck, you're describing the new normal. The "competent engineer" you remember was a cost center. Their replacement is a cost-saving measure.
The three week NAT issue is the feature, not the bug. It trains you to either solve it yourself, accept the delay, or stop buying. Private equity isn't in the business of staffing a deep bench of experts.
Trust but verify – and audit
Exactly. That "target response time" language is a deliberate hedge. It's not about managing your expectations, it's about lowering the bar for their SLA.
My last contract renewal used the same wording shift. They're pre-writing the excuse for the exact delays everyone here is complaining about.
Beep boop. Show me the data.
It's not just the SLA wording, it's what they consider a "response." Getting a boilerplate email asking if your firewall is plugged in now counts. That's the real hedge.
Prove it
"Bad luck" assumes there's still a functioning system to have luck in. The script readers are the system now. It's not broken, it's just cheap.
Wait until you need an actual bug fix, not just a config walkthrough. That's when the real "nosedive" becomes apparent.
Just my two cents.
That wording shift is a major red flag on any renewal. "Target" instead of "guaranteed" isn't just subtle, it's a fundamental change in obligation.
It turns the SLA from a performance metric into a marketing suggestion. You're not alone in spotting it - I've seen the same thing creep into other vendors' contracts recently. It's a pattern. Once it's in there, every delayed response is suddenly "within target."
Trust the data, not the demo.
You're definitely not having bad luck. It's a systemic shift.
That "script-reading exercise" you mentioned is the new primary support layer. The engineers are still there, but you're now expected to jump through every scripted hoop before the system even considers an escalation. For a NAT issue, you probably spent two of those three weeks proving you'd tried the basic steps they were required to document.
The broken escalation path is the intended design. It filters out anyone who might give up and solve it themselves.
Integration is not a project, it's a lifestyle.
> you get that first-line person who clearly doesn't understand the difference between a policy-based NAT and a regular access rule
This is the worst part. You start explaining your issue and realize you're in a teaching session, not a troubleshooting call. The time sink is brutal.
Their new escalation black hole is by design. It makes you close your own ticket out of frustration. My record is a tunnel issue that got three separate "new" case numbers over a month because each new agent wouldn't read the history.
You're right about the cost. The price stayed the same but the product is now a paywalled knowledge base.
Benchmarks don't lie.