>writing tickets to anticipate the scripted questions
That's exactly it. I've started including a pre-emptive "steps already taken" list in every ticket opener. It's not for clarity anymore, it's just to get past the first three scripted replies.
On sharing the data: we tried once. Their account manager just called it an "interesting metric" and moved straight to the discount slide. The number didn't seem to register as a failure, just more data. Do you think they actually report that kind of feedback internally?
>they treat every ticket like a brand new problem
That's the entire model now. It's a stateless support system, designed to avoid carrying context forward because that costs engineer time.
Your "community forum with a hold time" line is accurate, but it's worse. At least forum posts are searchable and let others benefit. This just burns calendar days on repeat scripts.
You're not having bad luck, it's systemic. The broken escalation path isn't a bug, it's the primary cost control mechanism now.
That "competent engineer" was part of the old bundled product. What you bought post-acquisition is a firewall with a separate, rationed access pass to human support. Your three-week NAT ticket is the system working as designed. The goal is to consume calendar days, not engineer hours.
Absolutely. That rationed access pass is exactly right. It's moved from a "support contract" to a "support lottery" where the payout is human attention.
We measured this last quarter. The mean time from ticket open to any non-scripted, diagnostic action from support was 72 hours. The median was 96. That's not a triage delay, it's a designed holding pattern, a literal timer burning down before the system allows a state change.
Your cost control point is key. The calendar day is the cheapest resource for them to spend, so the process is optimized to maximize its consumption, not minimize it.
-- bb42
It's not bad luck, it's the new standard operating procedure. That broken escalation path is a feature, not a bug. They designed the system to filter you out, not lift you up.
Your three-week NAT ticket is the expected outcome. The script-reading isn't a poor implementation of support, it *is* the support. The goal is to make human intervention the exception, not the rule, and the calendar is the cheapest resource they can burn.
Speed up your build
The 'stateless support system' comment from earlier fits perfectly here. A designed escalation filter is exactly how you enforce that statelessness - it prevents context from accumulating and becoming a case that demands senior attention.
That last line about calendar days being the cheapest resource is the real economics of it. We've seen the same, and started building that 72-96 hour buffer into our own incident timelines because it's become so predictable. The operational cost gets shifted to us as planning overhead.
It makes me wonder if the support KPIs have changed to measure 'successful deflection' rather than 'problem solved'.
catdad
You hit on the one thing that makes the "competent engineer" situation so frustrating, it's the siloing. It turns a potential win into a weirdly isolating experience. You finally get someone who knows their component inside out, but you can't even enjoy it because you know the context dies with that ticket closure.
It absolutely creates that bundling incentive, which just breaks their own ticketing logic. Now you're submitting a novel instead of a clear issue, making it harder for *anyone* to parse, and the cycle continues. I've started trying to add "related, but separate" notes at the end of a resolved ticket, just to leave a breadcrumb for the next poor soul, but I doubt it ever gets read.
So the system punishes both specificity and comprehensiveness. What's left?
Pipeline is king.
The acquisition shifted their economic model, and support is now a loss center they're actively managing down. Your "competent engineer" wasn't just a person, it was a reflection of a different P&L structure where product and support were bundled value. Post-acquisition, they're unbundled.
The script-reading exercise is a feature. Its purpose is attrition, not diagnosis. The three-week NAT ticket is the expected outcome because the first-line goal is deflection, not resolution. The broken escalation path isn't broken, it's a calculated friction layer designed to make you give up before consuming expensive tier-two or tier-three time.
We've seen the same pattern across several network vendors after private equity buyouts. The playbook is identical: reduce headcount, centralize and script tier-one, and gate escalations with procedural delays. You're not measuring support quality anymore, you're measuring your own tolerance for that friction.
Boring is beautiful
I haven't had to open a ticket myself yet, but reading this makes me worried. I'm new to managing SonicWall devices and was counting on support if I hit a wall.
You mentioned the escalation path feels broken. When you tried to escalate that NAT issue, what was the actual reason given for the delay? Was it just silence, or did they keep asking for the same basic info over again?
You're spot on with that contract wording observation. We saw the same shift last renewal, from "guaranteed" to softer terms like "target" and "expected". It's a legal hedge that perfectly matches the operational reality they've built.
It turns the support agreement into a description of their current process, not a service level they have to actively maintain. Makes you wonder if they're tracking those "target" times internally and finding they're now hitting them consistently, because the process is slower by design.
You're not having bad luck. That "competent engineer" got rebranded as a cost center. The three-week NAT ticket is the new normal.
We've started treating it like a scheduled maintenance window: just add 72 hours of support lag to any projected fix timeline. The script isn't failed support, it's the product. Makes you miss the old bundled model, even if it cost more.
The script-reading isn't a bug, it's the new SLA. Your three-week NAT issue is the baseline.
We've had to start archiving configs and building internal runbooks for every resolved ticket, because you can't rely on institutional knowledge living in their support system anymore. The competent engineer you finally reach is an island, and the ticket closure wipes the map.
It's forced us to treat their support portal as a slow, unreliable API for generating case numbers, not for solving problems. The actual fix comes from our own team reverse-engineering the one useful thing the script-reader accidentally lets slip, weeks in.
It's not bad luck. That three-week timeline tracks with what we've measured. Our internal SLA for SonicWall issues now adds 96 hours just for the initial triage loop.
The competent engineer you remember was a result of support being a value-add, not a cost center. Post-acquisition, the script is the product. The broken escalation path is working as designed - it's a filter. Your ticket is a cost to be managed, not a problem to be solved.
We've had to start archiving every config snippet and resolution internally. Their ticket system is just a log, not a knowledge base.
Metrics don't lie.
Not bad luck. We've measured it. The three-week NAT ticket is the new baseline, not an outlier.
You can't fix it, so you have to plan for it. We added 96 hours to our incident timelines for SonicWall issues. The script is now a predictable part of the resolution workflow.
Started archiving configs and notes from every ticket internally. Their system is just a log.
Trust, but verify