I’ve spent a large chunk of time this week building a case for hiring a technical support person. This has been a difficult, time-consuming process, and I’ve been thinking about how I’ve done this sort of thing before, and why it’s difficult now.
Tech writing vs. tech support
I’ve hired technical writers in the past, and now I need to make the case for an additional tech support agent. Although both roles tend to be reactive, a tech support role is primarily to triage, solve, and respond to tickets from users. (“Tickets” include bug reports, usage questions, password reset requests, or questions that get forwarded to the sales team.) A request for support resources is typically based on ticket volume, and a chart showing a stable increase in tickets will make up a good portion of your argument.
Of course, it’s not that simple. In my role, I’m also the support site administrator. That means that I create accounts, watch for and remove spam, make sure that users have the correct access permissions to be able to view our documentation, track usage, make sure we’re meeting our contracted SLAs…and then deal with the actual tickets.
Which hasn’t been as much “Go forth and RTFM” as I had hoped. Instead, users are asking complex questions (the nerve!), which involves more than a little research. I put a lot of this information back into the documentation as tips, new workflow topics, or troubleshooting articles. And that covers the “I write docs” part of my job, too. But it does mean that other tasks don’t get done.
Other support tasks
That’s always the key to building a case for resources: Document what you do day-to-day, and keep your backlog up to date. The first time I needed to ask to hire another tech writer, I spent time figuring out what I did, what I needed to do, and adding those tasks to the company’s task tracking system. I added up the estimated time per task and came up with a total close to 850 hours. Which translates to about 5 months worth of work. So if development stopped the next day, I would still have enough work to keep me busy for 5 months. Hard numbers are persuasive.
The second time was similar: Build a list of what I have to do, compare that with how much time I have (at least in theory), and notice the massive discrepancy. In that case we had two large projects on the way, so “we have no one to document these very important projects” was a persuasive argument.
So why am I having problems now?
The problem now is that I’m still learning how to estimate time required for tech support activities, how those activities scale with the number of users, and how to build an accurate resource plan.
Like tech writers, tech support needs to keep up with the latest changes to the product, keep up with changes to their tools, and understand how customers use the product (and any problems they’re likely to encounter). They also need to keep track of what the tech writers are adding to the documentation, and any internal info, including troubleshooting tips and known issues.
We include training with our product licenses, which helps explain the low number of simple questions with obvious solutions. I think there’s only been one time where I’ve been able to tell someone to turn it off and on again (in that case, to force a product update).
I need to build a measurement of number of tickets per day (or number of days per ticket). I’m still collecting info on that, but the range is pretty wide so far. One ticket took me half an hour to solve; another required multiple meetings with engineers and a lot of testing just to be able to replicate the problem.
But even writing metrics aren’t obvious
The old metric for tech writers was 2 pages per day. But what’s a “page” when you’re writing topics instead of manuals? A short topic could take me half a day from start to finish, while a longer topic could take me 4 days for research, writing, screenshots and other graphics, review, re-writing, etc. So maybe instead of 2 pages per day, I’m closer to 1 topic every 2 days (or so).
I’ll end with this
Regardless of how quickly I’d like to solve tickets, it’s INCREDIBLY frustrating for me to tell a user that we can’t replicate the problem, and what they’re seeing is caused by a problem with their system. I want to find a solution, and finding that the answer is “I don’t know, but I hope you have a good IT department” is painful. So I need to pad my metrics with some time to spend beating my head against the occasional impossible problem.