A badly written knowledgebase article is like the tainted clam in the linguine. It probably won’t kill you, but you aren’t going to feel very well after eating it. What did that bad clam cost you? Well, you wasted $24.95 on a meal, and no one wants to throw away perfectly good money. But that clam will cost more than your credit card statement can show: you’ll avoid that restaurant for a few months (or forever), and you’ll never eat another clam again.

To support organizations and customers alike, badly written knowledge base articles—bad clams—are costly, very costly. A company spends or loses money each time a person has to struggle to read bad KB content. And bad KB articles cost organizations something precious that’s not measured in dollars or cents: readers’ trust.

Case in point: A badly written knowledge base article

Before we touch on how much and what bad articles cost, let’s look at an example. This KB article comes from the Florida Department of Transportation. FDOT’s Project Management Section has a “District 4” knowledge base that, among other topics, provides self-service articles for people who use “Trns*port,” which is the software FDOT uses for “contract estimating, bid letting and award processes.” (Yes, the asterisk in the middle of Trns*port is correct!)

Here’s the KB article:

Why this is a badly written article

Overall, this bad KB article fails to answer the question implied in its title: “When should I request non-participating items to be loaded into Trns*port?” When it comes to self-service content, that’s a crime. Here are four other serious writing problems in this article:

1. It begins with a chatty “There is often confusion about…” introduction. That’s unnecessary. The only people who’ll read this article are ones who need help loading pay items. They know about the confusion. Get to the point instead of using a paragraph to explain what most people incorrectly believe.

2. It lacks informative headings. Headings help people scan KB articles. Headings are required, not optional. Though two of the paragraphs use “Example” headings, those headings aren’t helpful because they don’t say what the examples are of. The final paragraph should probably have a heading too because (as far as I can tell) it explains how the Engineer’s Estimate affects whether items will be entered as Participating or Non-Participating.

3. It confuses the issue. Is this article about when to request Non-Participating items be loaded into Trns*port or about how to load items as Participating or Non-Participating? The word “request” appears in the KB title but nowhere else.

4. It presents the name of the software two different ways. Should it be “Trns*port” or “Transport”? The inconsistency raises questions about whether this article has been proofread.

How much does a badly written KB article cost?

Unymira takes several figures into account when estimating how much it costs to create and maintain any KB article:

• Cost of time needed to create the article. If a medium-length KB article takes about 30 minutes to write, and the hourly editorial cost is about $30, it costs about $15 to create the article.
• Cost of time needed to update the article. Unymira estimates about 50% of the creation costs for update costs, so there is another $7.50.
• Average cost of an hour of an agent’s time. Unymira estimates yearly costs per agent are between $25K and $20K, so hourly cost is about $14.

So, as a rough estimate, let’s say the “Non-Participating Items” article cost FDOT $15 to create. I doubt it has been updated, so we won’t include any time for that task. If an agent’s time costs $14 per hour, we can confidently estimate that this KB article is costing an agent 5 minutes or $1.16 each time they try to use it. These costs would be acceptable if the article were clear enough to act on. Because it isn’t clear, this time = money spending is just thrown away.

HDI’s “Metric of the Month” article series (by Jeff Rumburg of MetricNet) gives us lots of tech support metrics to consider, and each one is affected by poorly written KB content.

• Ticket handle time, which is “…the average time that an agent spends on a service desk ticket, including talk time, chat time, wrap time, and after call or after chat work time…” Badly written KB articles undoubtedly extend ticket handle time, which increases costs.

• User self-service, which “…measures the percentage of incidents that are self-resolved by the user, without the assistance of a live agent.” Most companies that create customer-facing KBs do so to enable self-service. Badly written KB articles inhibit or prevent self-service. One badly written article does damage beyond itself because it creates distrust in the ease of self-service. The cost of distrust is high, indeed.

• Cost per ticket, which is “…the total monthly operating expense of a service desk divided by the monthly ticket volume.” In 2016, Rumburg put the average cost per ticket in North America at $15.56. Poor quality knowledge content can never improve (reduce) the average cost per ticket; it can only increase that cost.

• Tickets prevented, which support organizations calculate by first measuring “…tickets per user per month…” and then, for example, taking this measure one year later. If, in that year’s time, there are fewer tickets per user per month, we can “…multiply the reduction in tickets per user per month by the number of users supported…” Voila! Tickets prevented. High quality customer-facing KB content plays a huge role in preventing tickets. In fact, you could argue that the tickets prevented metric is proof of the value of great KB content.

What else does a badly written KB article cost?

Badly written knowledge articles have many “expensive” consequences, which we must recognize even if we haven’t calculated their dollar costs.

For support agents, badly written articles cost:

• Agents waste time trying to interpret the content, so they can provide an answer to a customer.
• Reusability. Well-written KB articles can be used as templates in email responses or portioned out in live chat conversations. Badly written articles can’t (or shouldn’t) be copied-and-pasted into anything else.
• Accuracy. When an article is hard to read, agents don’t read it carefully, and they’re likely to give customers incorrect information, which only increases contact volume.

For customers, badly written articles cost:

• When they encounter a KB article they can’t easily read, understand, and use, customers’ frustration causes them to generalize: “Well, this article was bad, so I bet the other articles are also bad.” Trust in the quality of the information in your knowledge base is difficult to regain once it’s lost.
• Willingness to use self-service options. Many customers are reluctant to use self-service options because they appreciate the concierge-quality help live agents provide or they’re anxious about their ability to follow the instructions provided. When they encounter a hard-to-understand KB article, their suspicions are confirmed. Yep, self-service is more work. Yep, it’s a good idea to phone the tech support team instead.

For the support organization, badly written articles cost:

• Successful AI-powered support. If you intend to automate support with a simple chatbot or a complex machine learning solution, you’ve got to provide clean, well-written knowledge. Can you imagine how the bot would cope with our “non-participating items” article as a source of knowledge? It couldn’t!
• Properly managed knowledge. When a good agent encounters a bad KB article, they may simply rewrite it and store the better version on their own computer in a little stash of content they need to answer customers’ questions. While an agent who creates better knowledge could be congratulated for taking initiative, an organization can’t function properly if there are un-reviewed knowledge stashes on who-knows-whose computers.
• Quicker onboarding. For a new employee, the knowledge base is a lifeline. When it’s full of high-quality, easy-to-read articles, the KB prevents “New Employee Malpractice.” But badly written articles confuse new hires—the very people who need help the most—and delay their independence.

When it comes to badly written knowledge base articles, some things are easy and others are, well, less easy. It’s easy for us to recognize a bad KB article when we see one. It’s less easy to calculate exactly what each badly written article costs us. But do we really need to know whether a badly written article is costing us $15 in an agent’s time, 35 minutes of a customer’s time, or $2.33 in lost revenue to decide to improve the article. No, we don’t. Let’s not use our efforts to calculate the cost of bad writing down to the last cent. Let’s spend our time creating great knowledge content.