Back in May 2019, I published an article in the Society for Technical Communication’s ‘Intercom’ magazine: “Content Strategy in Action: How Documentation Can Enable Sales.” I’m finally getting around to posting a copy here on my blog. I intended to do this years ago, but lost track of the exclusive rights period. It only occurred to me again when reading discussions about the value of tech comm in the Write the Docs Slack community (which you should consider joining if you’re a tech writer!).
Introduction
In all of the discussions that have occurred over the years about content strategy and the value of technical writers in the workplace, one theme that frequently emerges is how technical writers can apply their writing and organization skills to enable sales.
For example, in 1995, Janice Redish published an article in Technical Communication listing “more sales” and “more proposals won” as two ways that technical writers can show their worth to organizations (29). More recently in 2017, Emily January Petersen wrote about how technical writers should claim credit when their documentation is referenced by sales teams and managers to answer questions (218). And at the STC Summit in May 2018, Bernard Aschwanden delivered a talk about how it is becoming more common for marketing and technical communication teams to integrate their deliverables in order to bolster sales and customer satisfaction.
In each of these examples, two core questions are raised about the value of technical writers: How exactly can the content that technical writers produce enable sales? What are some deliberate content strategies technical writers can employ to achieve such enablement?
How Documentation Can Enable Sales
Most if not all companies that sell software (or any kind of complex technology product) face a basic challenge: to sell what a product actually does, while resisting the urge to exaggerate or over promise in order to win a major deal.
Indeed, discrepancies between what is promised in a sales pitch and how a product really works can result in serious friction in a client relationship and possibly undermine future deals. Such disconnects can also lead to steep expenses if the company must repair broken trust or devote precious resources to building custom solutions to compensate for a product’s limitations—situations that might have been avoided by more clearly documenting the product in the first place.
I witnessed the consequences of such disconnects in my own workplace several times. Product managers would come to the technical writers and say, “The sales team is selling product capabilities that we do not have or that are not fully mature, and they send us the same questions over and over again about what product can and cannot do. Can you help us better educate them on the product’s features, requirements, and limitations?”
As we investigated this issue, we found that there were in fact many internal audiences who could benefit from a centralized, approved documentation resource that could answer questions stemming from the sales process. Specifically, we learned that we could better equip the following internal audiences:
- Sales Operations Analysts: Individuals who work with sales teams to proactively identify opportunities, research competitors, and train new hires. These individuals must regularly verify their understanding of the product as they assess product-to-market fit.
- Solutions Architects: Individuals who must assess how the product can meet a client’s unique technical requirements, and who must therefore know the product’s capabilities, shortcomings, and configuration options.
- Proposal Writers: Individuals who must write detailed, sales-oriented descriptions of the product’s capabilities and who must verify that their descriptions are valid and up-to-date.
- Sales and Marketing: Individuals not only deliver regular sales pitches, but who study industry trends and look ahead to decide how best to promote the product’s unique value.
Of course, not every organization has this many distinct roles dedicated to generating revenue. In small organizations, a single person may fill multiple sales roles, and the technical writer may wear the hat of the proposal writer. Whatever the case, as technical writers we are well-positioned to support these audiences because we are usually much closer than they are to the inner workings of the product. We are also trained to research, create, and deliver content in a way that internal audiences can quickly find and understand.
To unpack this observation, let’s examine how technical writers can leverage their skills to enable sales in the following key areas: research and collaboration, writing and design, and ongoing maintenance.
In the interest of space, I will focus on how technical writers can create internal documentation to support internal audiences involved in the sales process. Consumer-facing technical writing artifacts (such as user guides and video tutorials) can also support sales by piquing customers’ interest and strengthening existingcustomer relationships. Bernard Aschwanden’s presentation (referenced above) offers some useful ideas on the subject. For another good resource, I recommend Strategic Marcomm and Techcomm Integration, a white paper published by Adobe.
Enabling Sales through Research and Collaboration
How can technical writers can apply their research and collaboration skills to help sales teams sell a product with boldness and confidence? There are many answers, but one strategy we used at my company was to begin by creating a knowledge map: an annotated matrix that my team built as a spreadsheet after speaking to various teams about their information priorities.
On the left axis of the matrix, we listed categories of information that we thought each team needed. Along the top axis, we added a column for each team. We then scheduled a series of meetings with team representatives and gave them a chance to rank each category, and to add custom categories we hadn’t included. (You can learn more about the process we followed in an online video presentation by Rebecca Glassman Sheridan, “Cultivating Content: Designing Wiki Solutions That Scale.”)
As a result of the knowledge mapping exercise, we verified categories of knowledge that we already knew teams across the company needed, such as feature descriptions, demos, and release notes. Additionally, we uncovered categories that were representative of the kinds of questions that clients would ask during the sales process. (Naturally, these categories will vary depending on your industry, product, and so on.)
- Requirements: What does the client need to have or do for the product to work successfully? In our case, the requirements included certain types of historical energy data from utilities.
- Limitations: What can the product not do? Are there any common misconceptions or known issues for sales teams to be aware of? As an example, we needed to explain why the web version of a feature might display different data than the printed version.
- Configuration: What product- and feature-level configurations are available to clients (if any)? If my desired configuration is not available, can I request a special customization?
- Design Rationale: Why did we design the product or feature as it is currently designed, and why did we choose against alternative options? Do we have data to show why our design is the best option?
By capturing and ranking these categories, we could identify what information was already in our consumer-facing documentation, and what was lacking. We also had the foundation we needed to design the metadata and structure for an internal product knowledge base.
Enabling Sales through Writing and Organization
Once you identify the core information needs of sales teams, you can decide if your existing documentation can meet those needs or if a new resource is required. In our case, we realized that although our internal and consumer-facing documents already covered some of the information, we would have to develop a new internal resource to meet a wider array of requirements. And we would need to write and deliver this resource in a way that would be easy to find, use, and maintain.
There are several ways to do this, and the choice you make will be constrained by resource availability, technology, and the like. We decided to create a central, authoritative knowledge base in our corporate wiki. This worked for us very well because there was already a robust collaborative wiki in use by teams across the company. Our wiki also had certain desirable features, such as commenting sections, search engines, version control, and simultaneous editing.
Of course, embarking on the effort to design and write a knowledge base, whether it resides within an existing corporate wiki or elsewhere, assumes that you have the time to do it—time in addition to the work you already do as a technical writer. You may need to make a business case to hire an additional writer. Our team was fortunate enough to have business leaders who saw the value that our knowledge base would provide to sales teams, and they approved our request for another resource.
Whether a new resource is needed or a shift in one’s every-day priorities, the next step is for technical writers to do what they do so well: design a structure based on the target audience’s needs. For example, below is the standard high-level structure of a product guide in our knowledge base that incorporated our research.
- Overview
- Global Requirements and Limitations
- Customer Experience
- Feature 1
- Feature 2
- Feature 3
- Feature n
- Demos and Internal Access
- Customer Support
- Configuration
- Calculations
For each major topic in this outline, we designed a standard structure and template. For example, if a user were to view a feature description, they would find a consistent breakdown of metadata and subsections in which knowledge is organized around the following categories:
- Feature Name
- Overview
- Requirements
- Limitations
- User Experience
- Sub-Element 1
- Sub-Element 2
- Sub-Element 3
- Sub-Element n
- Common Variations
- Configurations
- Calculations
The screenshot below shows a sample of how this outline translated into an actual wiki page.
There are a few important notes to make here. First, to keep the content as consistent as possible across contributors, we applied best practices in content strategy to define patterns and rules for what kind of information to write and how to present it. This was essential for achieving a unified voice and level of quality.
Second, we designed our internal resource to act more like a conceptual reference than a task-based manual. This is because we needed to arm sales and other internal teams with answers to questions about the full range of product capabilities, not to help them accomplish specific user tasks.
Third, by designing research-based standard categories of knowing and putting them in a central location, we developed an authoritative brand that was distinct from the rest of the wiki. This brand assured users that the knowledge they were viewing was reliable. Prior to the knowledge base, product information was scattered across different wiki spaces and systems of record, and was highly variable in quality, leading people to doubt its veracity—a problem which resulted in a lot of emails to product managers and engineers. Having a centralized, high-quality knowledge base went a long way in mitigating that issue.
Enabling Sales through Ongoing Maintenance
As every technical writer is aware, technology—and especially software—is subject to change, and the documentation you write must keep pace with those changes. In the context of sales enablement, sales teams need to be sure that the product knowledge they have is accurate and up-to-date.
Technical writers have many tools in their toolbox to provide such assurance. In addition to the standard content maintenance practices (such attending product planning sessions, updating content to reflect new features, and soliciting end user feedback), our team employed one other strategy that became an essential element in enabling sales: setting up a channel for asking ad-hoc product questions.
The channel, which we dubbed “Ask Product,” started off as a ticketing system where users could submit a ticket with a question whose answer could not be found in the knowledge base. Members of our team would then act like librarians who would either find an answer or connect the reporter of the ticket with the right subject matter expert. The system has worked well over the years, since sales teams often encounter unique client scenarios that the standardized documentation set may not address.
Conclusion
By researching the needs of sales teams and providing them with reliable product knowledge and answers to ad-hoc questions, technical writers can add deep business value to their organizations. Indeed, we experienced firsthand how a sales-friendly knowledge base fits well with research conducted by Michael Hughes about how technical writers do not simply transfer but create knowledge for consumption by users with varying information needs. We have also seen how this approach allows technical writers to facilitate knowledge flow across the organization, as discussed by Tom Johnson in a series of essays on his blog about a technical writer’s value.
Last but not least, supporting marketing and sales teams demands that technical writers leverage their core competency in simplifying complexity—another major theme discussed in Tom Johnson’s essay series. It is not enough create a searchable, user-friendly wiki; the content itself must be clear enough to answer a range of questions from across the organization. In that sense, simplifying complexity will always remain one of the most useful ways that technical writers can enables sales in the workplace.
Richard Rabil, Jr. 