3 ms·
How do you keep your SaaS FAQ accurate releases after releases?
In my two previous companies, we encountered what I would considerer a major pain-point: keeping our FAQ and knowledge base accurate as our release cadence accelerated to a release per day. Our doc became outdated. We created new articles for new features, but we lacked the resources to update existing content that was impacted by those changes. That was quite problematic because our product was available on iOS, Android, and the web, with small but still important differences across platforms. To make things even worste, we were based in the EU and supported three languages. The discrepancies between these languages became substantial, leading to increased support tickets.
My question is: Is this a common pain point, or were we in a unique situation? Is there a real pain point to build a business on?
- re-thc 2y ago> Is this a common pain point, or were we in a unique situation? Is there a real pain point to build a business on? The common pain point is why the daily releases? Forget your documentation - even customers can't keep up with this rate of change. Are you sure everything works? What version are we on again? Oh this is a known bug... oh wait we fixed it yesterday... actually it was delayed so you'll get it tomorrow. I've seen multiple releases in a day and no 1 knows what's going on. Even the developers have to keep pulling in changes and try it in a dev environment to confirm if the feature is even how it is.
- mtmail 2y agoBigger companies have launch checklists where documentation updates are listed. Those checklists can be as simple has an issue tracking, e.g. JIRA, template, Trello ticket or a Google Docs document. The rest is employee discipline (or having somebody dedicated assigned) I think. A better checklist won't magically get the updates on the page. You might even end up with yet another checklist item "check new system X and cross off all open items there".
- Vvvicus 2y agoSo I suppose that there is a business automating that?
- gregjor 2y agoIf the FAQ/knowledge base documentation has real value then you need to maintain it the same way you maintain and enhance the code. Ideally your product doesn't need separate documentation, and FAQs only have answers to general questions that don't change with every release. The product's UI should not require separate documentation or a knowledge base. At one place I worked we had this problem, in two languages, and people frequently adding to the knowledge base. It didn't seem to slow down support tickets, users asked questions they could have found in the docs. So we went through the FAQs/KB and brainstormed how we could eliminate each question by improving the software and the UI. No more articles about how to change a password or how to format a date, because the UI can show that clearly. The company should keep track of the most frequent support requests and deal with those in terms of product features and UI/usability, not by writing another FAQ few users will consult. I bought a new iPhone a couple of months ago. It came with almost no documentation, and what it did come with I didn't need. You want to shoot for what people call "intuitive," more correctly obvious, and remove unnecessary choices and options and dead ends from the product rather than explain to people how to avoid them or work around them.
- Vvvicus 2y agoI fully agree that the UI should be explicit enough not to need a KB but working with SMB there are A LOT OF basic processes that you need to write down…