Here at Swiftpage we use a support metholodgy called Knowledge-Centered Support (KCS). KCS was developed in the '90s by a group called the Consortium for Service Innovation (CSI). At its heart, it's all about efficiently capturing and (re)using the knowledge generated as a by-product of support interactions.
In the bad old days of Support, knowledge was tribal. Analysts would fix an issue, and that was the end of it. The knowledge wouldn't go any farther than their own head. Maybe they'd mention it to someone in passing, or maybe someone would hear that John knows a lot about a specific issue. Either way, the information wasn't freely available. If you wanted it you'd have to go talk to John, which would occupy you both.
Realizing that this was a waste, companies created knowledgebases and started populating them with articles. It's different at every company, but the general life cycle of an article might look something like this: Analyst discovers an issue and fixes it. They report that issue and the fix. A Product Specialist will try to replicate the issue and verify the fix. If they can, and the issue is deemed worthy an article will be created. This will normally be quite detailed. It'll have screenshots, possibly videos, cover all possible scenarios, and generally take a long time to create. It wouldn't be unusual for one of these articles to take a few hours of work from replication to finishing the article.
That's where most companies stop. It's not their fault, they just don't know any better.
When our analysts create an article, they do it immediately after a call is finished. It's created using the terms that the customer used to describe the issue, since other customers are likely to use those same terms rather than technospeak. The only thing this article will contain is the instructions and information that they gave the customer to fix the issue. If they weren't able to fix it, they still create the article so it can be updated later. It has no screenshots, no videos, no unnecessary details, and nothing that didn't happen in their interaction. These articles take about 5 minutes to write. Ideally, they're published immediately, so the information is available as soon as possible.
At this point, you might be asking "Wait a second, there's no technical review? How can I trust this?".
During the research that lead to the creation of KCS, the CSI realized that speed is key. 77% of customers would rather have information faster, even if it's not fully validated. 66% of customers said that they were willing to take responsibility for using incomplete information, even if there were mistakes. Customers want solutions more than they want perfection.
The result of this is a lot of new content being created. Prior to KCS, each of our analysts created about 1.5 articles per month. After adopting KCS, they've increased output to nearly 15 articles per month, each. This might sound like an overwhelming amount of content, but we understand that not every article is going to be a home run. Some might never get used by a single person. We expect this. This is why we keep the articles as short and simple as possible when they're created. We're playing the long game here, and banking on efficiency.
Any time an analyst views an article they have a responsibility to make any changes necessary to ensure accuracy. If someone discovers a new fix for a known issue, it's added to the article. If screenshots are necessary, they're added. Whatever is needed to solve the issue is added each time the article is used. Updating on an as-needed basis guarantees that we waste as little time as possible.
With KCS, everyone wins. The company saves money because analysts don't waste time, become proficient faster, and it enables one-to-many solves via the knowledgebase. Analysts win because they don't have to spend most of their day dealing with simple issues. Customers win because they have a good self-service option as well as a better guarantee of a quality solution if they choose to contact support.