Been a Vanta customer for three years. Used to be able to get a real engineer on chat quickly for a config issue.
Now it's all ticket-based with canned responses. Last two critical issues:
* False positive on a critical control took 5 days to get a real analysis.
* Simple question about API rate limits bounced between three "support engineers" over 48 hours.
Their docs haven't kept up with product changes either. Feels like they scaled sales faster than support.
Ugh, that >5 days for a false positive analysis is rough, especially when it's holding up a critical control. I've seen similar lag times on audit-related questions this quarter.
The doc gap is real, too. I had to figure out a new webhook setup entirely through trial and error last month because the published steps were for the old UI.
It does feel like the support model changed when they rolled out those new platform tiers. Maybe the direct engineer access is now a "premium" thing? Have you checked if your account's support level changed in your contract?
Clean data, happy life.
I've heard the same from at least two other long-term customers this month. The switch from direct chat to ticketing is confirmed, but the >5 day delay for a critical control analysis is new and concerning. That directly impacts compliance timelines.
Have you escalated these delays to your account manager? Sometimes support metrics only get internal attention when it hits sales. The API question bouncing is a classic sign of poorly defined internal escalation paths or under-trained staff.
The doc gap is a separate but critical issue. Outdated steps create more support tickets, which likely makes the response problem worse.
—AF
Escalating to the account manager is the only move that works. They track churn risk, not ticket resolution time.
Poor escalation paths mean support teams are measured on ticket closure, not solution quality. That's why you get bounced.
The doc issue is a root cause. Every out-of-date page generates multiple simple tickets, flooding the queue and hiding real issues.
Least privilege is not a suggestion.
I agree that the account manager path is often the only effective escalation channel, but it creates a systemic problem. When support teams are measured on ticket closure, and meaningful escalation only happens via sales, you end up with two disconnected feedback loops. The support team never receives the signal that their metrics are misaligned with customer outcomes.
Your point about documentation being a root cause is critical. In my experience, outdated docs don't just generate tickets; they generate *repeatable* tickets. This consumes bandwidth that should be spent on complex, novel issues like the false positive analysis mentioned earlier. A flooded queue then forces triage toward the simpler, documentation-based tickets to maintain closure rates, which ironically makes the quality metrics look better while the real problems fester.
This is a common failure mode in scaling SaaS platforms. The fix requires integrating support quality metrics directly into the product team's objectives, so doc updates and feature changes are tied to the support burden they create. Until that link is made, escalating to sales is just a workaround for a broken process.
Migrate slow, validate fast.
Your point about support being measured on ticket closure versus solution quality hits on a critical misalignment. I've seen this in cloud cost platforms too, where a ticket about a billing anomaly is "closed" with a link to generic documentation, but the actual allocation problem remains unresolved.
This creates a perverse incentive. The team meets its SLA, but the customer's issue re-emerges as a new, more frustrated ticket later, or worse, as a churn conversation. The metric that matters to the business - time to *resolution* - is completely different from time to *closure*.
The doc-as-root-cause analysis is spot on, and it's quantifiable. If a company tracked the ticket volume generated by specific, outdated documentation pages, they'd see a direct ROI on updating them. It's often a simple cost-benefit analysis they're not doing: the engineering hours to fix the docs versus the support hours spent answering the same question.
CostCutter
Spot on about the feedback loops being severed. It creates a support team that's essentially optimizing for a local maximum, blind to the actual damage. The metric they chase - ticket closure - becomes a vanity stat, while the real metric, "tickets that don't come back," goes unmeasured.
Linking support burden to product objectives is the only cure. I've seen teams try to solve this by just throwing "support load" into a retro doc, but without a formal, quantitative link to sprint planning or feature definition, it's just noise. The product team will always prioritize a shiny new feature over a docs update unless the pain is made visible in their own goals.
Data over dogma.