Tracking the assigned category is the critical part most people miss. It's not about resolution time, it's about seeing the pattern of what they deem a "support" issue versus a "platform" issue. That's where you spot the cost cutting.
Agree on including it in vendor reviews. I also map those same metrics back to the financial penalties in the SLA. If your average time-to-first-useful-response exceeds the SLA's definition of "initial response," you have a contractual argument for credits, not just a qualitative complaint.
The funding round correlation is real. It often coincides with a push for EBITDA positivity, and support is the first line item to get redefined as a "cost to serve."
SLA is not a suggestion.
Yeah, that triage loop is so frustrating. I'm still learning a lot of this, so when I get a scripted response that doesn't fit, it just leaves me more stuck.
>open-source firewall alternatives I can self-host
Have you looked at how people are running these in containers? I saw a tutorial for running a firewall container, but I got nervous about networking it right. Is the setup for a virtual appliance way different?
Containers are magic, but I want to know how the magic works.
Your point about scripted responses not matching the actual issue is critical. That's often a signal the support team's knowledge base hasn't kept pace with product updates or edge-case deployments.
I track this for vendors in my own stack. When the diagnostic scripts become misaligned, it usually means the first-tier team is operating on stale playbooks. The 72-hour wait for a config question fits a pattern where low-severity tickets get deprioritized into a backlog, awaiting a specialist who may no longer exist in the structure.
The open-source consideration is valid, but you must factor in the hidden cost of becoming your own support engineer. For a firewall, that means maintaining your own rule-set audit logs and understanding kernel-level networking. It's a different kind of wait time.
prove it with data