Want to write great technical documentation? Work in Support
…my manager proposed that I transfer to the Support team. My initial reaction was panic.
Working for a large-scale SaaS business means that my job as Technical Writer involves keeping up with gaps in the documentation, maintaining versions, coordinating release notes — the list goes on. The job is largely independent, and many days are spent with headphones on, typing out how-to guides and screen capping product interfaces.
This all changed about two years ago, when my manager proposed that I transfer to the Support team. My initial reaction was panic: with an already huge backlog of tasks to juggle, there was no way I could take on another role, like actively supporting clients. However, after copious reassurance that my role wouldn’t change, only my team, I made the jump.
This turned out to be one of the best decisions in my career.
After being in Support for merely two weeks I realized that I was home. After all, self-service documentation is the frontline of support. Research repeatedly shows that given the option, customers would rather solve issues on their own. In one study from Nuance Enterprise , 67% of respondents said they prefer self-service over speaking to a company representative. That means that the majority of customers will land on your documentation before they make that call or write that email asking for help. It’s no surprise that before long, a symbiotic relationship developed between me and the Support team. They provided me with feedback and ideas, and I in turn churned out documentation. This ultimately led to an overall reduction in redundant tickets, allowing the team to do their jobs more efficiently.
Even though you write documentation and they support customers, you are still part of one team who are essential to each other.
In hindsight, working in Support seems so obvious, but I was lucky enough to have my company facilitate the move. If your situation doesn’t allow you to work in support directly, you should still remain in contact with this essential part of the business as much as possible. All you need is a solid plan to make it happen.
Get the Support team on board
Remember: having a different role than the rest of the Support team doesn’t place you apart from them. Even though you write documentation and they support customers, you are still part of one team who are essential to each other. What surprised me most when I first entered Support was how many documentation ideas the team already had. They had been answering the same calls and replying to the same tickets over and over again. The better the documentation is, the fewer redundancies there are in tickets and calls coming in. Depending on the size of your enterprise, this means that Support may ultimately get fewer tickets, yes, but the tickets that do come in will contain challenging issues that actually require the team’s knowledge, extra time, and skills to answer. When they have meetings on support issues, you attend; when you have documentation issues, you communicate those with them. You can’t be a team unless you understand each other and the unique issues each of you face.
Find the solution that works best for the team. And don’t despair — if one solution does not work, move on to the next
Make communication simple
When you’re writing documentation full-time, you don’t have the bandwidth to answer calls or respond to tickets. You rely on the Support team to let you know which issues are coming in often enough to warrant a doc page or an entry in the FAQs. However, anyone with exposure to Support work will know that it is a busy job too — they need to help as many customers as they can in a single day while maintaining the highest satisfaction rating possible. So communicating documentation requests needs to be quick and efficient.
There are a lot of ways to facilitate this, but here are a few suggestions:
- Have the IT team set up a dedicated email account for the documentation.
- Create a Trello board to track documentation requests.
- Build a Slack command that assigns you the requests automatically.
- Set up a team Confluence page.
We went through several strategies before ultimately settling on building a Slack command to receive the requests, and creating a Trello board to track them. I knew this solution worked for us when tasks began coming in and getting updated organically.
Find the system that works best for the team. And don’t despair — if one solution isn’t a good fit, move on to the next.
Collaborate
When a member of your team assigns you a documentation issue, give them partial ownership of that issue. Even though you’re doing the writing, the person who requested the task should be the one to review your work to ensure that the information is accurate and there are no communication gaps. In Trello, this means that I add the requestor to the card so that they automatically get notified when I make changes. But if you’re using emails or even good old face-to-face communication, setting ownership can be as simple as sending them an update and asking for feedback before you publish your work. And once they finish helping you, show gratitude. Ensure your team knows how much the collaborative relationship is valuable for the self-service site. Little things — like sharing how much web traffic articles based on assigned issues have been getting — will help your team understand how impactful their contributions are, further encouraging the collaborative relationship to continue.
In the end, yes, inserting yourself as a unique role within a team will feel awkward at first; but the more you keep at it and work with the Support team, the more the benefits of the relationship will show. Eventually you get to a point where the distinction between Support and Writer doesn’t matter, because you’re simply a team working as one.
On my end, the positive impact has been measurable. Since I started in the Support department about two years ago, our view to ticket ratio (Zendesk refers to this metric as a self-service score) has become 16:1. What this means is that for every 16 unique views on our self-service site, only 1 customer opens a ticket. With 1 million interactions on our site each year, a ratio like that means that our documentation is saving support team a lot of time on potential redundancies. But don’t just take my word for it — try it for yourself and track your own metrics over time.
