Goal: 

Differentiate the content in the Knowledge Base based on its purpose and the goal(s) of its audience.

My role:

As the content strategist for Resolution content, my role was to design new content types (known as “record types”) in the Salesforce Knowledge Base and prepare the requirements for their development and implementation.  

Deliverables:

• Principles, considerations, and the process for creating new record types, plus templates to use to ensure consistency through the expansion. 

• A Knowledge Base architecture workbook listing the key elements of each record type.

• A field dictionary to track API names, descriptions, field types, character limits, and which record types they appeared in.

• Use case analyses, technical requirements, and visual mockups for 5 new record types, plus initial preparations for 2 more. 

Before:

When the Salesforce Knowledge Base was set up for Customer Support, it had only 2 record types: one for internal procedures and one generically called “Knowledge Articles”. Over the years, the Knowledge Article record type came to contain many different types of content, not just content for resolving issues, because it was seen as the fastest way to publish information to the Help Portal. There were thousands of articles about errors and how to address them, but also information on upcoming events and how to register for them, or analyses of incidents, or ways to contact Support. 

All these articles had the same layout with “Description” and “Resolution” headings regardless of their content. This catch-all approach to the record type hampered our ability to find or filter for specific content, effectively report and gauge the quality of our articles, or accurately recommend articles at the right state of the customer journey.

After:

Two additional record types were developed and released for different purposes. I designed the “How-to” record type to contain step-by-step instructions customers (or Support engineers) could follow to complete a task. Its development coincided with the integration of two acquired companies’ articles into the Knowledge Base; both had a version of “how-to” articles, numbering in the thousands, which needed to be migrated. The second record type was for internal use by a team who wanted to sunset a custom-built, older knowledge repository that had become too difficult to maintain. 

I completed the use case analysis, design, and requirements for 3 other record types, which were awaiting prioritization for development as of this writing. I had also started research and designs for 2 others. 

To keep track of the similarities and differences between the different record types, I created a field dictionary to show which fields appeared where, plus their API names, descriptions, types, and character limits. One of my goals during the design phase was limiting the number of new or custom fields needed, to reduce the level of development effort. Instead, my aim was to create fields that could be used more than once across record types.

Knowledge management was already in place for the 2 existing record types, so we needed to scale it to the new ones, ensuring that operational best practices were followed and that the new users were enabled and brought into relevant communication channels and activities (such as the Knowledge Council). 

I documented the criteria and design principles for this work so that it could inform the development of new record types in the future. This includes the templates needed to ensure consistency through further expansion. 

Process:

The first step for designing each new record type was understanding why it needed to be distinct from those that existed already. What purpose would it serve, and what would be the goal(s) of its audience? Without clarity on these 2 questions, we didn’t have a solid case for expansion. Inventorying existing content, interviewing its creators, and understanding their current processes for publishing were key in answering these questions. Thus, I ran a ‘use case analysis’ on each new potential record type to understand its layout, whether its audience was internal or external, what languages it might need to be localized in, whether it needed to be attached to Support cases, and much more. 

Once the analysis was complete, I created a medium-fidelity visual mockup to accompany it. Both went through a few rounds of feedback and iteration with key stakeholders. When the requirements were finalized, I submitted them to the Business Technology team for development.  

Results:

As of this writing, there were more than 5,000 articles using the new “how-to” record type. Of those, about 4,200 were migrated from the acquired companies and validated for either internal or external use (on the Help Portal).

What I’d do differently:

• One of the biggest challenges throughout this project was balancing operational skillsets with strategic ones. There was already a team managing the day-to-day operations of the Knowledge Base, and they weren’t used to thinking of the articles in terms of content strategy. It was important to partner and collaborate continuously, and learn what approaches were most effective for them to see and understand the value of changing some things, while keeping other things the same and scaling them to audiences with differing needs.

• I really wish I could have continued this work and seen more of it through. Unfortunately, my team was impacted by several reorgs that meant we couldn’t continue to work together; my content strategy focus shifted away from Resolution content and Knowledge to internal documentation for Customer Success.