Every product team has a mental model of how onboarding works. A new customer signs up, reads the docs, configures their account, and starts building. That mental model is almost always wrong. The proof lives in your support queue.
About a year into running ScaleMule, we noticed something uncomfortable: the same questions kept arriving, phrased differently by different people, but pointing at identical confusion. Not bugs. Not feature requests. Misunderstandings. Gaps between what we assumed was obvious and what was actually obvious.
That pattern became the forcing function for rewriting our documentation from scratch. Here's what we learned, and why you should treat your support queue as a live audit of every assumption your onboarding makes.
The most dangerous phrase in ops is "it's already documented." When a support question comes in and someone on the team can point to an existing doc page, there's a reflex to treat the ticket as a user problem. They didn't read it. They didn't search. They skipped a step.
Sometimes that's true. But when the same misunderstanding surfaces repeatedly from unrelated customers, the problem is yours. The information might exist on a page, but it doesn't exist in the right place, at the right moment, in the right shape.
We had this exact situation. Customers would complete initial setup and then stumble at a predictable next step. The relevant documentation existed. It was accurate. It was also buried three clicks deep, written for an audience that already understood the context, and titled with jargon a newcomer wouldn't search for.
"It's in the docs" was technically correct and operationally useless.
We didn't build anything elaborate to fix this. The approach was low-ceremony: periodically read through recent support conversations and group them by the confusion they represent, not by the feature they reference.
That distinction matters. Two tickets might mention different features but share the same root misunderstanding — both might stem from a customer not realizing that one configuration step needs to happen before another. Grouping by confusion rather than by feature reveals the real structure of your onboarding gaps.
We did this regularly. No special tooling. One person reading tickets, writing one-sentence summaries of the underlying confusion, and sorting those summaries into clusters. Within a few rounds, clear patterns emerged. A small number of conceptual gaps explained a large share of incoming questions.
The clusters became a priority list for documentation work.
Armed with those clusters, we rewrote docs with a different philosophy. Instead of organizing by feature taxonomy — the way engineers think about a product — we reorganized around the moments where confusion actually occurs.
Each high-frequency cluster got its own treatment. Sometimes that meant a new page. Sometimes it meant adding a single paragraph to an existing page, right at the decision point where customers got lost. Sometimes it meant changing a title so it matched the words a confused person would actually type into a search bar.
We also killed pages that existed only because someone once thought "we should document this." If a page had no connection to a real support pattern and wasn't load-bearing for another page, it was dead weight. Removing it made the remaining docs easier to navigate.
The goal was not comprehensive coverage. The goal was that a customer, at their moment of confusion, would find a clear answer before they decided to write a ticket.
After the rewrite, the share of support conversations tied to those original clusters dropped significantly. Not to zero — some confusion is irreducible, and new customers will always have questions. But the recurring, predictable questions that stemmed from documentation gaps shrank to a fraction of what they had been.
More interesting: the nature of incoming tickets shifted. Fewer "how do I do X" questions. More "I'm doing X and want to extend it to Y" questions. The queue moved from onboarding confusion toward genuine product feedback. That shift made support conversations more valuable for the product team, not just cheaper to handle.
The real takeaway isn't "rewrite your docs." It's that this clustering habit, done regularly, turns your support queue into a self-correcting system. Onboarding assumptions rot over time. Features change. New customer segments arrive with different mental models. A quarterly pass through recent tickets, grouped by underlying confusion, catches drift before it compounds.
Your support queue is not a cost center. It's a live signal telling you exactly where your product's story breaks down. The only question is whether you have a habit of listening.
If you take one thing from this: schedule a recurring block to read support conversations. Not to respond. To cluster. The patterns will be obvious once you look for them. The documentation changes they point to will be among the highest-leverage ops work you do all quarter.
Be the first to comment.
0 comments
Loading comments...