So much waste, so little strategy: The reality of enterprise customer content

For your customers to effectively use your products and services, it’s critical that your enabling content is fully integrated across content types. 

Enabling content is information that helps customers use a product successfully. Subcategories include:

• Technical and product content
  • Information about the product and its capabilities
  • Goal: help a customer use the product
• Learning content:
  • Information about how to use the product and its capabilities
  • Goal: increase customer knowledge about the product
• Support content
  • Information about specific use cases or bugs
  • Goal: solve a specific problem for the customer

As you can see, these are subtle distinctions. It’s often easier to focus on delivery mechanisms instead of content category or content purpose:

• Technical content 
  • Books, online help, reference content, websites with searchable content
• Learning content 
  • Classroom training, online training, e-learning, job aids
• Support content 
  • Knowledge base with articles

Your customers probably don’t care about these fine distinctions. They do care about getting things done, and all of the enabling content types are intended to support that effort.

Your customers probably don’t care about these fine distinctions. They do care about getting things done, and all of the enabling content types are intended to support that effort.

— Sarah O’Keefe

Inside your organization, you almost certainly have three (or more!) organizations that are producing technical, learning, and support content. Most likely, they each use a content authoring system that is optimized for their specific use case. And those content authoring systems work in isolation.

This is unacceptable. We estimate that there is about 50% overlap between technical and learning content (mostly step-by-step instructions) and about 25% overlap between technical content and support content (instructions for troubleshooting or avoiding common problems).

If you look at the type of information inside each content type, you can see the overlap. 

Why haven’t we solved this problem? We are wasting enormous amounts of time and money copying and recopying (or worse, re-creating) content from one silo to another.

The standard answer lies in focusing on the differences:

• “We need a simple Q&A format for support articles.”
• “We need SCORM output.”
• “Your content isn’t good enough for MY audience.”
• “Techcomm doesn’t provide for test questions.”
• “Learning content doesn’t cover the entire product.”
• “You’ll pry my favorite software tool from my cold.dead.hands.”

But look more closely at how deliverables are actually built. A technical content resource website usually includes:

• Tasks (how-to instructions)
• Concepts (background information to help customers understand the product)
• Reference (dictionary-style lookup; for example, a list of command-line options for software)
• Terms and definitions, like a glossary or pop-up definitions for specific keywords

A learning experience usually includes:

• Lessons that include tasks and concepts
• Assessments
• Term and definitions

A knowledge base usually includes:

• Tasks (how-to instructions)
• Troubleshooting for specific configurations or to address bugs

Why, then, do we have three copies of the shared tasks?

The answer lies in the company structure—your org chart. Techcomm, learning, and support departments nearly always report to different executives, and each executive is appropriately focused on their department’s priorities. Each department optimizes content operations for their own requirements and sharing across departments isn’t a priority.

This needs to change for two reasons:

1. Your customers want answers, and they don’t care about your internal organizational problems. Every time you give them conflicting information, you lose credibility. Common problems include contradictory information, inconsistent terminology, and lack of unified brand identity.
2. Creating good content is expensive. Creating almost-but-not-quite the same content two or three times is more expensive—and wasteful.

Enough ranting, what’s the solution?

I’m so glad you asked. We need to build out content operations so that we can identify shared content, write it once, and share it across the organization. This can be accomplished by single sourcing content in a repository in the form of components. Content objects such as instructions, definitions, and assessments can then be assembled from this single source of truth. 

Additionally, we must create shared infrastructure to deliver a unified customer experience; for example, enterprise taxonomy, localization, and design systems. 

Someday, one of our beloved software vendors will tackle this problem, but, for now, an enterprise content ops strategy requires us to glue together numerous point solutions. Talk to us if your organization is ready for the challenge.