Support Teams and Technical Writers: A Powerful Partnership
When I was kicked in the leg during a soccer match a while back, I didn’t think much of it. But it began to swell and, a few days later, my leg had swollen up incredibly. I looked like exactly one-quarter of Popeye.
I limped in to see a doctor, and after she took a look and did some tests, she asked me to sit down. Then she turned to her computer and, in full view of me, began Googling my symptoms.
I was surprisingly disconcerted! My mental model of doctors was pretty naive, informed by everything from Doogie Howser to House. Somehow I still expected doctors to just know the answer without ever needing to check reference materials.
Of course that’s a completely unreasonable idea, and as a customer service professional, I should know that. Very often I read a customer’s question and have no clue what the answer should be. My skill is in knowing where and how to find the answer, and in knowing how to communicate that back to the customer in a way that will make sense to them.
For customer service professionals, a reliable, accurate, and well-organized knowledge base is an incredible gift. It helps save customers’ time, reduces duplicated effort, and creates consistency across the whole team.
Too often, though, the enormous effort of building and maintaining that knowledge base is left with over-worked and under-resourced technical writers who may not even work directly with the customers they are trying to help.
How can we as customer service professionals build closer relationships with our technical writers, contribute more effectively to our knowledge bases, and ultimately help deliver better customer service?
Recently I gave a talk to technical writers at Write the Docs Melbourne on how they can help their customer service colleagues improve their documentation, and in this article I want to share those ideas with you.
Why are knowledge bases often so . . . mediocre?
1. No dedicated knowledge base authors
Customer support people tend to get hired early in most growing SaaS companies. Even the most customer-centric founders realize quickly that they could fill their entire days directly helping customers and not leave time to improve their product or work on their business. Technical writers are usually much further down the list, because you can get by with your founders, engineers, and support staff chipping in with essential documentation. And even if it isn’t great, you still have a support team to help customers one-on-one.
Often by the time tech writers are brought in, the knowledge base is less a reflection of current reality than a “Museum of the Previously True(ish)” — halls full of inaccurate instructions, incorrect labels, and confusing screenshots of interfaces long since removed.
2. Software undergoes constant change
In the SaaS world, your help documents can be up to date when you arrive at work and then wildly wrong by lunchtime after a design update is released. The rate of change is particularly tricky for agile software teams, where the product can barrel forward without support or technical writers necessarily being included.
3. The tyranny of the urgent
We all know that maintaining and improving your existing knowledge base is important, but it is rarely as urgent as documenting newly released work, so maintenance tends to fall to the bottom of the list.
As support teams, we can intellectually understand that pressure and acknowledge that technical writers have a really tough job to do. Yet for support teams, those help documents are so important to understanding how the product is intended to work, what features are supposed to be called, what is an expected behavior, and what is an accidental outcome.
So we are desperate to find ways to help more customers help themselves through high-quality self-service options like guides, videos and training. To do that, we need to be better assistants to our documentarian colleagues.
A spectrum of collaboration between support and technical writers
The relationship between product teams, technical writers, and customer support teams can be great, but they can also be pretty dysfunctional. In the ideal world, the product team effectively shares information with the support and technical writers about upcoming product changes, and the two customer-facing teams communicate closely to continually improve and extend the documentation.
When the support-technical writer relationship is broken, technical writers are isolated from customer feedback, and the support team loses trust in the documents, instead creating their own internal knowledge hoards. The customers are left out of the loop, with an inaccurate or unclear knowledge base and inconsistent replies from the customer service team.
What can we do to create a more effective relationship? Here are some practical tips to choose from.
5 ways support teams can help improve software documentation
I spoke to three software companies about the challenges they face in documenting their products and how they have been able to involve their support teams in those documentation efforts.
Many thanks to the following people for their help:
Carlee Potter, Head Technical Writer at Campaign Monitor
Michelle Wyngard, Support at You Need a Budget (YNAB)
David Domagalski, Technical Writer at Survey Gizmo
1. Reduce friction
Customer support staff rarely have contiguous blocks of time to spend. Encourage support teams to to maintain or suggest knowledge base improvements by making it as easy as possible.
For example:
Campaign Monitor has an internal UserVoice account which support teams can use to really quickly vote up existing improvement requests or add new ones. It’s one place to submit them that everyone can see.
SurveyGizmo added a simple checkbox to the bottom of their help desk form. If a support agent checks that box, their proposed answer to the customer is sent directly to the technical writers, who turn it into a published document for all future customers to benefit from.
Give your team a tag they can add to a conversation, like “needs-documenting,” so they can very quickly flag an area for writers to prioritize.
2. Choose a champion
Not every support agent will make a great documentarian. Identify the people in your team who show interest and skill, and carve out some time for them to be an apprentice to the technical writers.
At SurveyGizmo, David Domagalski was a support agent who was eventually moved into a full-time technical writing role. His knowledge of support is invaluable to both his writing and his efforts to work more closely with the support team.
3. Create shared goals
Technical writers can be of great assistance to support teams. That might include bringing support into product meetings, keeping them informed of known issues, or making changes based on their feedback.
Support teams can help elevate technical writers by reporting on the impact of their work in reducing incoming support, and by feeding useful information from customers back into the writing process.
By working together as a larger team, you will have more organizational power and influence, to the benefit of your customers. At Campaign Monitor, the support and technical writing teams keep a “Kill That Question” list. It’s a prioritized list of recurring customer complaints that can only be truly eliminated through improvements to the product.
The list links customer conversations and existing documentation with an explanation of the underlying issue and a proposal for how to address it. The technical writers refer to that list when they become aware of work that touches those areas of the product.
4. Build mutual trust
Busy customer service teams won’t spend their time sending in documentation requests or updates if they don’t think anything will really happen. Find ways to let your team know their effort is paying off.
For example:
At YNAB, every piece of knowledge base content is indexed in an internal Notion wiki. Any support agent can visit that list and see who owns the content in question, what stage it is in, and when it should be updated. If work is stuck, it’s very clear who is responsible and what the next step is.
At Campaign Monitor, Potter and her technical writing colleague send a monthly email newsletter to the support team. It calls out by name the people who have helped them improve documentation, and it lists out what’s changed and what has been added. It is very clear that support time spent making improvements is well rewarded.
5. Be pragmatic
It’s rare in support to have even a few solid hours to sit down and write a new document. If you set the “contributing to documentation” bar too high, the team will become demoralised.
Look for opportunities to get useful work done. Do you offer “out of queue” time for your team that could be used for writing help guides? Is there a Ship-It Day type project you could run around documentation?
Stronger relationships for better customer service
Customer service and support teams are the natural allies of technical writers. Both teams have the same underlying goal: helping customers do whatever it is they need to get done.
Like Voltron (or possibly Captain Planet, depending on your age), support and technical writers are much more powerful working closely together than working separately.
Why not send your technical writer colleagues a message today, and see how you can help them to help your customers?