Producing documentation inside a Support team¶
Advantages of working as a tech writer and support agent¶
Working in support and documentation simultaneously comes with some advantages. As a documentarian, you receive direct user feedback through support, which helps you anticipate everyday use-cases. If you notice a mistake or that something is missing from the current documentation, you can ensure it’s changed yourself, without having to pass the task to another department. As a supporter, if you have also documented the product yourself, you have a deeper knowledge of where to point people, and since you have already used the product, it becomes easier to explain it to users.
Here are some tips for different cases:
- you are a support agent who wants to start writing technical documentation
- you are a tech writer who wants to start in support
- you are a tech writer who wants to work in your own defined role within support
Tips for support agents wanting to start writing technical documentation¶
As a supporter, starting to write documentation can be challenging, although the two are related. In support, a user asks a question about a specific topic, which you then explain. In documentation, however, you have to come up with topics yourself and anticipate questions before they are asked. In addition to that, you also need to figure out who your expected audience is and make an assumption about their prior knowledge, whereas in support you get an idea of the user’s level of knowledge from their question. When writing documentation, you may have to cater to multiple audiences in the same article, or even split it up into multiple articles for beginners and more advanced users.
Feedback: in documentation, your work is often reviewed by a colleague, and you review their work as well, whereas in support, you usually interact with the user more directly. On the one hand, this can feel like being supervised by your colleagues or supervising them, but on the other hand, it provides a kind of safety net, preventing you from putting out wrong information by yourself.
Tips for tech writers wanting to start in support¶
Are you a tech writer looking to start out in a support role? Great choice! The two disciplines complement one another excellently, with both requiring good customer-facing communication skills and specialist product knowledge.
However, when you are starting out, you’ll find that there are several challenges to tackle on the road to becoming a support superstar. Let’s explore the most important ones.
Knowledge of features that you haven’t documented: perhaps the best way of learning a product’s features is by documenting them. But what if your customers start asking about features that somebody else documented?
This may happen more than you’d think – especially if you haven’t been working at an organization for long, or if you’ve only recently started to write about a certain tool.
My advice: don’t be discouraged or alarmed if you get questions you can’t answer. To learn more about the software, reach out your colleagues, study old support tickets, and, of course, don’t forget to read the docs!
No review process: as a doc writer, the chances are that your work gets edited and proofread by a colleague before publishing. However, when answering most support requests, your input won’t be checked by a colleague.
So, how can you deal with this safety net being removed? Firstly, recognize that it’s fine not to know something – never give an answer you’re not 100% sure about just for the sake of saving face. If you don’t know, it’s always a good idea to ask another agent for their input, or escalate the ticket to the next support level for support.
Tips for tech writers who want to work in their own role within support¶
If you work for a large-scale SaaS business, being a tech writer involves keeping up with gaps in the documentation, maintaining versions, coordinating release notes, and so on.
Often this means that you have a huge backlog of tasks to juggle, and you cannot take on another role, like supporting client. However, this does not mean that you should lose your contact with this essential part of the business. Working as a technical writer within a support team is a great way to keep up with customer issues while maintain the documentation. All you need is a solid plan to make it happen.
Consider these tips:
- Get the team on board
- Simplify communication
- Collaborate
Get the team on board¶
It is important to remember that when you work in a separate role within a team, it does not separate you from the team. Even though you write, and they provide support, you still make up one team and are essential to each other. The better the documentation is, the fewer redundancies there are in tickets and calls coming in. This means that support will get less tickets, yes, but those tickets will contain challenging issues that really require their time and skills. This is a rewarding, symbiotic relationship. When they have meeting about issues, attend them. When you have doc issues, communicate about them with support. You can thrive as a team when you understand each other and the unique issues that each of you faces.
Simplify communication¶
When you are writing documentation full-time, you have little to no time to answer calls or respond to tickets. You are relying on your team to let you know about any issues that resurface enough to create a doc page or FAQ. However, they are busy too. Anyone with exposure to support work will know that it is a tough job that requires helping as many customers as you can in a single day while maintaining the highest satisfaction rating possible. The support team needs to be able to send you their issues quickly and efficiently.
There are several ways to do this:
- Create a dedicated email account for doc tasks where they can send issues.
- Create a Slack command that assigns you the task automatically.
- Use a team Trello board.
Find a solution that works best for your team, and don’t despair. If one solution does not work, move on to the next.
Collaborate¶
When a member of your team assigns you a doc issue, give them partial ownership of that issue. Even though you are writing the doc, they should be the one to review it to ensure that you are answering the issue correctly and there are no gaps. And once they do that, show gratitude. Ensure your team knows how much the collaborative relationship is valuable to the documentation. Small things, like showing how many hits an article that was created from an assigned issue gets per month will help your team understand how valuable their contributions are, and it will encourage even more contributions.
Even though being in a unique role within a team may feel awkward to you at first, the more you keep at it and work with your team, the more the benefits of the relationship will begin to shine. Eventually you will get to a point where the distinction between support and technical writer do not matter, because you are a team working as one.
