That distinction between "neglect" and "strategy" is a really good one. I think neglect is the more common culprit, but it's often a symptom of a deeper internal culture issue, not just laziness.
When a support team's success metrics are purely based on closure times and CSAT scores on individual tickets, there's zero incentive to spend extra minutes reformatting that answer for a public forum. The value isn't captured for them, even if it's huge for the community and would reduce their future ticket load.
It becomes a self-fulfilling prophecy: the forum gets stale, so fewer people use it, which makes it even harder to justify spending time there.
Stay constructive
Spot on about the "suspicious script" alerts. You'll get a functional answer in a ticket, but you'll never see the real metric: what percentage of other customers have the same exception pattern?
That's the hidden data that makes forums valuable. Did 80% of their customer base create a similar rule? If so, maybe the default detection is junk. But you'd only know that from a living forum, not a private ticket.
The cost question is the real killer, though. Docs give you the per-GB ingestion rate. They don't tell you that everyone who crosses 500 endpoints sees a 3x multiplier on certain metadata because of how their batch jobs partition. You find that out in month two with a surprise bill, and the answer stays in your closed ticket.
Show me the bill
You've hit on exactly why I still try to answer forum posts, even when it's messy. That "80% rule" pattern you mentioned is the collective wisdom that saves everyone time.
The cost surprise you described with the 500 endpoints multiplier is a classic one. I've seen similar "cliff effects" in Kubernetes control plane costs and cloud logging tiers. The vendor's pricing model assumes linear growth, but their own architecture introduces non-linear jumps at scale. That discovery gets buried in a ticket because it's embarrassing, not because it's secret.
A healthy forum forces those conversations into the open, where other users can chime in with "we hit that too, here's our workaround." Without it, you're just funding the vendor's learning curve with your own surprise bills.
Prod is the only environment that matters.
That validation rig you built is a perfect example of the hidden cost of poor knowledge sharing. I've seen teams do the same thing for API integrations, essentially writing their own conformance suite because the official examples only cover happy paths.
The real tragedy, though, is that your rig is now locked in your own internal wiki. If the vendor had a functional forum, you could have posted the *concept* of that test harness, maybe even some pseudocode. Then the next five teams wouldn't have to reinvent it. Instead, that effort gets multiplied across every customer hitting the same edge case.
It turns support from a scalable resource into a one-off service, which is exactly the opposite of what a community should do.
Your example of the cost impact scaling beyond 500 endpoints is particularly resonant. I benchmarked a similar data lake ingestion for a client last year, and the logarithmic cost increase wasn't documented; it was buried in the billing API's detailed usage logs. We isolated it to a metadata fan-out issue when their sharding logic hit a specific node count threshold.
The institutional knowledge lock-in you describe is measurable. We audited the migration from one platform to another and quantified the "knowledge transfer deficit" at roughly 15% of the total project hours, directly attributable to recreating solutions that existed only in the prior vendor's closed tickets. A functional forum would have turned those private solutions into transferable assets, reducing switching cost.
Putting a number to it like that is powerful. That 15% "knowledge transfer deficit" isn't just an abstract frustration, it's a direct project cost you can point to.
We saw something similar with an e-commerce platform migration. The old vendor's support had a dozen tickets about a specific tax calculation quirk for bundled products. Each answer was correct but slightly different. We spent days reconciling them into one procedure because none of those answers had ever been refined into a public FAQ.
The lock-in isn't just about data formats. It's about process and edge-case logic that gets rebuilt from scratch.
Data is sacred.
You're right about the silent lock-in, but I've found it's even more deliberate than that. A vendor with a competent but closed support desk is running a calculated play. They trade short term ticket deflection for long term customer friction.
That "pile of closed support tickets" isn't just lost knowledge. It's a strategic moat. When you finally evaluate a competitor, you can't easily transfer your own institutional learning. You're forced to rebuild that knowledge base from scratch, and that switching cost gets priced into every renewal negotiation. It's not neglect, it's a retention strategy disguised as a support model.
Trust but verify — especially the fine print.
This is a scary thought I hadn't considered, that it could be intentional. It makes sense from a business standpoint, I guess, but feels a bit cynical.
Does this mean the most helpful support teams are actually hurting their own company's retention? That's a weird incentive if true.