KCS and Technical Writing

In a recent post, I covered various knowledge resources and docs-sites, including a brief discussion about knowledge bases. A common practice for building a knowledge base is Knowledge Centred Service (KCS). If you’re a technical writer, you’ve likely encountered it—and maybe felt uneasy. KCS involves service team members creating articles that look a lot like your documentation. This can feel redundant, or worse, a threat to your value as a technical writer.

My goal for this post is to explain how KCS and traditional technical writing (i.e., writing comprehensive guides for a product or service) differ and, in fact, powerfully supplement one another.

Warning: This is a deep dive! If you’re a leader or Technical Writer trying to figure out how to have product docs work alongside Knowledge Centered Service (KCS), this post is for you. Here is the TL;DR:

• The overlap is a myth: Traditional documentation and KCS articles are distinct magisteria (separate domains) that complement each other.
• Docs are proactive: Technical Writers create the foundational “shared language” (guides, reference) that users and support staff need to even discuss a product issue.
• KCS is reactive: The Solve Loop is a bottom-up process, driven by support teams fixing specific user failures. Docs should be linked and validated, just like KCS articles. Technical Writers shouldn’t be the authors for KCS articles or the bottleneck on publication.
• Strategic Value: Technical writers are well positioned to contribute to KCS in the evolve loop as a strategic partner. They can help define the process and templates for KCS, and use the performance data from the Evolve Loop to proactively improve the official product documentation.

What is KCS?

KCS is a practice for service teams. A service team responds to issues from customers (internal or external). This practice has been developed by the Consortium for Service Innovation, a non-profit coalition dedicated to excellence in customer engagement.

What is KCS meant to solve? Organizations without explicit frameworks for capturing and communicating knowledge struggle to scale. Tacit knowledge, held by key members of the community is tied to that individual. While that individual is a valuable resource, they can become swamped — they are only one person after all! Worse, if that individual leaves an organization, the organization suffers as a whole, since their knowledge goes with them. The goal is to engineer ways of working that transform implicit knowledge into explicit artifacts or resources (capture).

Additionally, even if you successfully capture knowledge, it then runs the risk of becoming stale, or out of date. So knowledge management frameworks typically involve some kind of process for validating or maintaining your knowledge. Stale or out of date resources need to be validated, updated, or removed.

The promise is that KCS lets teams answer questions quickly with the latest collective knowledge, optimize self-service for known issues, and drive data-driven improvements for products and services.

KCs proposes that service focused organizations structure their workflows around two loops for building and evolving knowledge resources:

1. The Solve Loop
2. The Evolve loop

I’ll briefly explain both, and talk about how you might interact with them as a technical writer. Note: I’m not certified, but I’ve had exposure to the methodology, and I’ve been considering working towards certification. You can view detailed resources on CSI’s library detailing KCS v6.

The Solve Loop

Here’s the key insight: customer support teams function based on knowledge. A customer experiences an issue with a product, and the support team is equipped with the knowledge to identify the cause and work towards a resolution. When they achieve that resolution, hopefully they have that knowledge in case a similar issue arises. In resolving the problem, the support team is building and validating their understanding of a product. KCS proposes that support teams leverage that moment for two specific knowledge management tasks: capture and validation.

Capture occurs if the team don’t have any existing knowledge resources that solve the issue. In this case, the support team does what support does best: investigate the issue and move towards a resolution. As they’re doing this, they create an article that identifies relevant background features, the source of the problem, and the steps they take to resolve the problem. After verifying that the article is complete and records the solution, it is published to the knowledge base, ready to be reused the next time a similar issue arises. This knowledge base can be internal or externally facing.

To facilitate capture, KCS suggests a basic content model of an article, and to use simple templates with a consistent structure. This helps simplify writing and reading articles. Articles are typically stored in a database and retrieved through search. Because content is generated on a per-issue basis, building a navigable information architecture isn’t a priority in KCS implementations. The point isn’t to build a resource that is easily traversed by a human in a browser, but to capture and retrieve knowledge. This is a pretty serious perspective shift from how technical writers approach content design — often by thinking about user needs and coverage for a range of topics.

Here’s an example of a KCS resolution article from Salesforce’s Help Center:

As a brief aside, some work with LLM-powered chatbots suggest that this kind of clear structure is beneficial for reuse via LLM as well. Continuing to use Salesforce as an example, their Agentforce chatbot is the primary way for users to discover these help articles.

A key point in KCS is that reuse is review. Validation is the process of confirming the quality of existing resources. A well functioning KCS team searches existing articles to see if the problem has a known solution. If there is an article containing the solution, they validate that the article is complete and correct. During the validation step, they may make minor improvements, and they link the article to the customers tickets. If the article is incorrect, then the article is updated in line with the same steps as in the Capture path. The process is one of continual improvement, which limits the need for costly comprehensive audits.

Here’s a flow chart detailing the process, including steps for more complex solutions or articles that need improvement. If the knowledge base is leveraged for self-service (customers resolving their own issues), an additional step can be added to validate that the article meets standards before being made available to customers:

It’s important to note that there’s no sense in which KCS is complete. Knowledge is constantly evolving and created in response to new needs. The methodology is fundamentally bottom-up and focused on continuous improvement of a growing collection of articles.

The Evolve Loop

The solve loop occurs at the event level, where knowledge is produced and used. The evolve loop is a collection of organizational practices meant to ensure the overall health of your knowledge practices and organizational buy-in to KCS. While it sounds like big picture thinking, the evolve loop also involves practices at the article, contributor, and management involvement levels.

The evolve loop is broken down into four key practices:

• Assessing content health
• Process integration
• Performance assessment
• Leadership and communication.

Assessing content health involves using techniques that might be relatable to you as a technical writer. It involves reviewing content to ensure that it meets the structure, and assessing the state of individual articles. It also involves things like defining content standards and ensuring that people are aware of these standards. As the solve loop is bottom-up it says nothing about when to retire articles, so as part of the evolve loop, you will want to set up processes for archiving old articles and cleaning up legacy data (if you’ve ever maintained an internal wiki, you’ll know how important this task is!).

Process integration is about aligning tools and behaviour to ensure that the solve loop is low friction. It involves ensuring that the ticketing tool or CRM and the knowledge management tools are closely aligned. Lowering friction is vital to the success of a KCS program: you need to focus on how issues are individuated and knowledge is retrieved and created in the flow of work. Ways for managers to ensure adherence to KCS methodology are also vital — while contribution will be varied across a team, it’s important to coach support team members as a whole and build skills. This includes building habits while working to retrieve information from your docs site and knowledge base.

I feel like this point is a more significant stumbling block for orgs than they tend to think! If teams are building both a docs site and a knowledge base, then cross-publishing, content duplication, and search are significant risks of failure when implementing KCS.

Performance assessment focuses on measuring contributions and the success of the program. It involves carefully defining goals, ensuring that there aren’t game-able incentives for contributors, and facilitating leadership. It also involves defining roles and ensuring that people who have demonstrated competency and awareness of the knowledge framework and standards are enabled to contribute or provide validation. Competency is key, some service representatives might need to demonstrate core knowledge framework competencies before they can fully contribute or validate content.

Leadership and communication is about making the process understood by the organization as a whole. People need to understand how the initiative relates to strategic goals and ways in which they can contribute or relate to the business as a whole. It involves developing and articulating a vision for the KCS process as a whole and ways of promoting and encouraging participation. The KCS practices surrounding leadership heavily discusses metrics, but I do think they take a holistic view noting that it carries throughout the org. Strong KCS leadership involves building collaboration with over teams.

Both loops are continuous processes, driving the knowledge culture at an organization. The solve loop generates content, and the evolve loop reinforces and improves the content and practices as a whole.

How does it relate to technical writing?

Lets come back to that original complaint:

So all of my support staff are now going to be writing on top of all of their ordinary duties, while over on the product or engineering team, we have a perfectly good technical writer. This all seems to be going very wrong! My support team is writing rather than solving problems and the technical writer output isn’t solving customer problems.

Or alternately, from a more strategic perspective, it might look like the technical writer is producing significantly less content than the KCS team. Building and maintaining two platforms that look very similar makes the team that is less directly tied to revenue look more expensive or less productive. And the unfortunate truth is that support has a much easier time tying their initiatives to churn, CSAT, and deflection rates, since this is data about customers.

There’s a couple of points to say about this kind of confusion, which I want to end my post on:

1. Technical writers have skills to contribute to the KCS ecosystem, but need to be brought in carefully. They are ill-suited to author articles. And there are opportunity costs and multiple models for contribution.
2. Docs and knowledge base articles (as construed by KCS) are distinct, but supplemental worlds. Docs are proactive and foundational, while KCS is reactive and contextual. And these are both resources people need!

Technical writers can contribute to KCS

Doing KCS is a lift — it’s difficult and ongoing, requires organizational buy-in, a lot of training, and external factors need to align. In many ways, the processes, practices, and standards it suggests are aspirational for a company, the north star that guides support operations.

The mistake is to think that the technical writer should be authoring at the level of the KCS article. Technical writers aren’t engaged in the same interactions that drive the solve loop. They do, however, have expertise in the kind of writing that KCS aspires to, and in fact, a technical writer can be a valuable asset as part of the assessment and editing flow in the solve loop.

There is, however, a concern with this model: this can diminish both technical writer velocity and KCS velocity by introducing a bottleneck on publication. There are often more support agents than technical writers and technical writers are already busy keeping pace with your engineering team’s output.

My suggestion for this kind of workflow is to view the technical writer as a coach, rather than as a check or valve — they should champion writing standards to the contributing team and they are experts in automated tools should be used to help ensure the quality of content in KCS articles.

The other potential route for involvement is enlisting their help in content modeling and KCS design. They can help define the structure of your article types, and provide guidance on how to add categories and other kinds of metadata to your knowledge base, ensuring that these things align with your broader product guides and resources. Technical writers are uniquely positioned as a high-value add when it comes to defining and explaining the product and bringing them into the evolve loop can improve the ecosystem as a whole.

Still, I think leaders looking to involve technical writers in their KCS flows should be cautious. KCS is demand driven, and technical writers highest-value time should not be spent as a reactive editor. The tactical route for involvement is enlisting their help in content modeling and coaching. A stronger use is as a strategic partner, helping shape the architecture of your knowledge articles, and benefitting from the evidence that a KCS system can provide.

Different content for different purposes

The complaint I started with stems from a simple confusion: we tend to refer to any written output of business units as documentation. But product/engineering embedded technical writers are doing something fundamentally different from KCS. To borrow a term from philosophy of science, product documentation and KCS articles are distinct magisteria.

Stephen J Gould’s idea of non-overlapping magisteria (NOMA) is that religion and science are directed at different questions, with different standards for evaluating correctness. Science is directed at answering questions about how the world works, while religion is directed at answering questions about morality, meaning, and how we should live. The methods of science aren’t suited to answering those questions, and the methods of religion aren’t suited for answering questions about how the physical world works. While NOMA itself is a philosophical concept often debated, the core idea—that different domains (magisteria) have fundamentally different questions and methodologies—is a powerful lens to apply to technical writing and KCS.

Product documentation (the proactive and foundational magisterium) is forward-looking — they define the intended operation, tell users what the product does, how to use a feature correctly, and provide reference for technical details. They create a shared language. KCS articles (the reactive magisterium) are bottom-up, and created after a failure. They tell the user why something broke, and how to fix that specific contextual scenario. One defines the map, the other fixes the potholes.

As anyone who has built something knows, users tend to surprise you. Things will break in ways that you can’t anticipate — or rely on configurations outside of what product managers, QA teams, and technical writers can anticipate. The knowledge built by support teams is a valuable guide to what happens after the unexpected happens.

More importantly, KCS is a reactive posture. A central challenge for KCS is adapting to changes or new products. It’s approach allows a team to rapidly scale a knowledge base, but it relies on customers and support sharing a common ground for communication.

Technical writers should be positioned to be proactive. Technical writers create the material for building a shared language between internal staff and users. There needs to be some kind of common ground between the customer and the support team to identify and resolve issues. Users acquire that language from the product, the documentation, and their onboarding.

KCS extends that base of knowledge to more complicated scenarios where the system encounters potential failures. Support staff, working from KCS, will go from their knowledge articles to the docs when there are gaps in their knowledge, extending and transforming that foundation into new knowledge. If they’ve internalized use-as-review, then they’ll be encouraged to create tickets and supplement the docs with their own feedback, just like they identify bugs in the core product.

This division of labor is precisely why the two supplement each other. KCS articles, with their high volume and explicit ties to support tickets, generate powerful data. If a thousand tickets are being solved by a specific KCS article on a core feature, it tells the technical writer one of three things:

1. The official documentation for that feature is missing context
2. The official documentation is not findable
3. The product has a defect that needs a dedicated guide

The data transforms the technical writer’s work from guessing what users need to evidence-based documentation planning. The solve and evolve loops are sources of data for informing your practice. The core idea is that technical writers are strategic partners who can benefit from data, but help guide the standards and improve the KCS knowledge base in the evolve loop. The more senior a technical writer is, the better positioned they are to help with conversations regarding metadata, retrieval, and content planning to ensure that knowledge base is healthy and up-to-date.

Three contribution models

Hopefully this has convinced you that technical writing and KCS aren’t in conflict, and when done right, are complementary approaches to providing self-service resources. I think technical writers and be involved in KCS in several ways that benefit the program.

Here is a table summarizing each of the three approaches:

While I tend to prefer the third model, I think there are value-adds that technical writers can provide in each. It only becomes a concern if we think that KCS can supplant the proactive, forward looking role that good docs provide.

Concluding thoughts

Like I mentioned, I was exposed to KCS through my work. Technical writers and support teams should be closely aligned, and I’ve benefited from KCS content directly. I think it’s a powerful framework, and it gets to the core of something about service-based work that should inform how teams think about building, maintaining, and transferring knowledge.

It’s easy to view it as something in conflict with or replacing docs entirely. But I hope I’ve demonstrated some of the ways that technical writers can contribute to a KCS ecosystem through it’s processes, the ways they can benefit from KCS, and the fundamental value that technical writers have for a product.

The reality is that we have tight budgets, varying incentives, and lots of demanding customers. Transformation and practice is hard, but worthwhile. Adopting KCS isn’t about giving up proactively written guides and reference material, it’s about building a culture that values knowledge sharing and use. In this light, companies need to address questions about governance and architecture. The questions are part of KCS, but technical writers are well suited to contribute to answering these questions.

It can be a difficult road building that kind of culture at a company. I think that technical writers as content strategists can be helpful champions, co-architects, and beneficiaries from KCS. I think there’s a deeper question of content architecture that I’ve hinted at. Tooling (like docs-as-code or a CCMS) gives technical writers a powerful authoring environment, but using those effectively is a core competency of technical writers, not support staff. Enterprise knowledge management solutions give support teams CMS/databases that are easily linked to customer tickets, but the bifurcated systems here create problems (analytics, search, etc.).

A unified content pool is the dream, but how do you balance the competing needs? Building and designing these systems is tricky to begin with, and made even more urgent as retrieval augmented generation (RAG) and LLMs depend entirely on structured, authoritative content pools for accurate retrieval. KCS struggles with changes due to its reactive posture, and I think technical writers can help with propagation. Involving technical writers in the evolve loop is part of the answer. But these are thoughts for future posts.

Here’s the takeaway for leaders and technical writers: KCS is not a replacement for documentation; it’s an opportunity for evidence-based strategy. Strategically minded technical writers are well suited to move beyond serving as an editor to leverage KCS data. Helping to build a knowledge ecosystem that serves both the product and the customer better than either system could alone.

Note: Thanks for making it through this deep dive! If you found this strategic breakdown valuable and want to support more content like this, consider buying me a coffee. I’m currently between positions, and I appreciate the support.