Eliminating support tickets

Simon Anstey explains how working with support can help us show the business value of documentation; and make customers happy.

This article was published originally in Communicator (Winter 2016). Communicator is the authoritative, award winning, journal for UK technical communicators. It is home to high quality, objective, and peer-reviewed features – current, relevant, and in-depth.

One of the biggest challenges that writers are faced with is demonstrating our value to management. In a couple of pilot projects we ran last year, we teamed up with the support engineers to improve the documentation with the specific aim of preventing customers from having to raise support tickets. It worked, and it translated into less work for the support engineers and the software engineers, a time saving that we quantified in time and money.

This article explains how we ran the pilot projects and offers some recommendations for putting these ideas into practice yourself.

What kind of ticket?

Before we look at the projects, a quick word about the kind of support ticket we are talking about. Customers create tickets for all manner of reasons, such as bugs, translations, or not finding the right information about a product. This project covers the last of these.

In the beginning

Now — let’s go right back to the start, and how the project came about in the first place. In actual fact, the idea for this project emerged as the result of various things I had been thinking about.

First, the writers in my team are always looking for ways to get closer to the customer. Sometimes customer visits are possible, and we are doing them more often, but they are still the exception rather than the rule. So I was thinking about alternatives that might still give us some idea of what our customers need.

Second, I had recently been in touch with a colleague in the support organisation. (Although I of course knew that we have support engineers, I had never knowingly met one and certainly never worked with any. They belong to a separate unit and sit in different locations from us. Much like the yeti, they were believed to exist about but no one had ever seen one.) The reason for our conversation was a central initiative they were setting up to ensure that support could channel feedback on the documentation to the writers. In any case, the conversation was very fruitful and we both began thinking about other ways of working together.

Third, as a manager (and before that as a writer too), I had always wanted to demonstrate the value that we, as technical communicators, add to the product, but had never really had the right idea as to how to go about it. I think also that it was important to me not just to show this to others, but to somehow prove to myself that what I was doing was adding value.

Fourth, and still in my role as a manager, the team were not sure that their work was appreciated by others, especially when compared to software engineers, for example. This is the net result of the previous point.

Fifth, during discussions with the software engineers’ managers, it emerged that they had concerns that their software engineers were spending valuable time answering support tickets (if the support engineers were unable to solve them, they get forwarded to the software engineers). This is time they should be using for value-adding activities, that is, coding.

And sixth, and certainly not least, some customers had been telling us that they didn’t even know that documentation exists, or if they look for it they often can’t find it. If they do find it, there is such a wealth of information (our documentation; notes published by software engineers; knowledge base articles written by support; and additional roll-out information written by subject matter experts) that they do not know where to start. I wanted to give our customers a better experience than this.

The fog clears

Gradually an idea began to form that teaming up with the support engineers might help with the majority of these problems: they might be able to give us more concrete input for our documentation; that would bring us closer to the customers (if not at first hand), and it might be a way of showing some practical use for the documentation if we were able to reduce the number of support tickets.

I then got in touch with a couple of managers from support, to see if they might be interested. I had never met these people and didn’t know what answer to expect. I was in fact expecting mild disinterest at best, but at the meeting I had set up, I soon got the feeling that we might be on to something: they told me that their organisation’s goal is ‘zero support tickets’, and as a result, were more than happy to work with us.

So having got their full backing, I talked to a few members of our writing team to see who might be interested in giving it a try, and which projects might be suitable.

The pilot projects

We selected two pilot projects to try out our initiative. One was working within a new development, for which the product owner estimated that we might get about 50 -100 tickets in total, and he was interested to see if this approach would save them some work.

The other project was to work with an existing development that customers have been using for several years, and which was generating a steady stream of tickets, an average of 55 per quarter.

For both projects, we followed more or less the same process:

• ƒImprovement project initiation (getting buy-in)
• Project kick-off (the formal start to the project)
• Development (doing the work)
• Roll-out (making sure that customers and internal stakeholders know what documentation is available)
• Retrospection (analysing the number of tickets, collecting feedback)

Project initiation

For both projects, we set up a separate initiation meeting to which we invited everyone involved in the creation of the documentation: the writer, the support engineer, the product owner (who is accountable for the documentation), and also the subject matter expert. It was important to us to have everyone at the table to make sure everyone knew about it, accepted it, and would contribute.

At this meeting, we simply explained the background to the project, what we were trying to achieve, in broad terms, and get consensus. And it worked.

Kick-off

The next meeting was the actual kick-off meeting. I did not attend this. I took a conscious decision to step back as the project went into ‘operative’ mode, to make it clear that the writer now had the authority. So the meeting was hosted by the writer.
The focuses for the new development and the existing development were slightly different.

At the meeting for the new development, the agenda was for everyone to get a common understanding of the following:

• The business purpose of the development, that is, what our customers use it for.
• Which customers will implement and use it (is it for all customers, or will it only be used by a few?); are there any customers that need special attention for any reason? (For example, those that might be piloting it.)ƒ
• What information we need to provide our customers with (in this case, they agreed on three different kinds of information: how to install, configure and run the software).
• Who will write which information (the support engineer agreed to write the installation information, and the writer to write the rest; the subject matter expert agreed to provide both with the necessary additional information so that an additional roll-out document would not be necessary).
• What activities are planned to roll out the new development to the customer (in this case, two webinars and a customer forum).
• How they would work together during the course of the project.

At the meeting for the existing development, the agenda was similar. However:

• Instead of discussing which information to provide the customers with, they agreed that the support engineer would analyse the support tickets from the last twelve months, to see which topics our customers were struggling with and where better documentation might help.ƒ
• Instead of discussing who would write which information, the writer agreed to update the existing documentation.

In both cases, at the close of the meeting, they were all on the same page.

Development begins

Once development started, the team working on the new development began writing their documentation as normal — but with several improvements:

• There was a mutual review, which proved very beneficial and made excellent use of the different skills of the team members. When the writer reviewed the support engineer’s document, she helped structure the information, made the content easier to absorb, and did a copy edit; the support engineer on the other hand was able to provide the writer with excellent feedback about issues that the customers usually have problems with, and this also made the documentation a lot more concrete.ƒ
• On top of that, the writer and support engineer cross-referenced each other’s documentation, explaining how the documentation was structured and where to find the other parts of it.ƒ
• Just before the software was released, the subject matter expert and the product owner reviewed the documentation one last time, and it was published together with the software.

In the case of the existing development, the support engineer analysed the support tickets and informed the writer which topics needed to be changed. The writer updated the documentation, involving the responsible software engineers when he needed more input about the content.

Roll-out

Then the next phase started: the roll-out to the customers, and the roll-out to the teams involved in the development and support of the software.

For the new development, the team had already discussed how they would roll out the software to the customers at two webinars and a customer forum. In each case, the presenter took the time to explain how the documentation was structured and showed where to find it. The writer had also produced a 90-second video with this information, which was well received.

For the existing development, the documentation was rolled out similarly to all customers.

The final roll out in both cases was to the software and support engineers who were working on the product, to make sure that they also knew what information was available and that they were familiar with the contents. The writer also furnished them with a boilerplate text that they could paste into all communications with customers, explaining to them where to find the documentation.

Retrospective meetings

For the new development, three months after the majority of customers had implemented and begun working with the software, and we would normally expect the flow of support tickets to ease up, we held a retrospective meeting, with the same people as at the beginning, to collect the numbers of support tickets and discuss the upsides and downsides of the project.

The result was far beyond what I had hoped for. The product owner had predicted somewhere between 50–100 consulting tickets. Instead, only two had been created. Support told us that that translates into a time saving for them of 5–10 days, and development told us that they save half of that again, that is, 2.5–5 days. A total time saving for our company of 7.5-15 days, for one relatively small project.

The icing on the cake was the fact that in total, the team reckoned the additional overhead from this project added up to only six hours.

For the existing development, the results were similarly spectacular. At the retrospective meeting three months after the updated documentation had been published, we discovered that not a single ticket had been created. That means an annual saving of 22 days for support, and almost 12 days for development.

However, the icing on this cake was a lot thinner. This project required a lot more work from the team — four days from support for the analysis, three days for the writer, and one day for the software engineer. Remember, this project was being run on top of the team’s regular tasks, so they had to squeeze this additional work in.

Project conclusions

• This project really exceeded the expectations I had of it.
• The figures that we had collected proved the importance — and business value — of good documentation
• The customers were presumably more satisfied with the documentation (this is an assumption, since we never got feedback)
• The writers’ own satisfaction with their work improved. By working with support, who gave them input as to what customers really need, their sense of purpose improved. Their standing improved in their teams, as it was seen how they approach documentation in a professional manner.

The figures that I have given here are an indication of what might be possible. The writers in my team are responsible for around 50 scrum teams. So this year we have started another project, in which around a dozen writers will apply this approach. Let’s see if we can repeat last year’s success.

Recommendations

I’m at the end of my story. However, if you are thinking about trying this approach out for yourself I would like to offer you a couple of recommendations based on my personal experiences.

• Get the backing of management. If you can tell them that with relatively little effort you might be able to save time for their teams (support engineers and software engineers), they might well be interested. This will make the project easier, and make them more interested in the good results at the end of the project.
• When you choose your pilot projects, go for ones that are likely to succeed. The writer should be keen, and capable of guiding their colleagues through the process; the product owner should be interested and supportive. Go for new developments over updates to existing developments, since the latter mean additional work.
• Make sure that you collect the data right at the beginning of the project. Ask the product owner and support engineer to provide you with an estimate of the number of tickets they expect. Find out from them, or their managers, how long it takes to solve a ticket. In both cases, if there are no ‘official’ data, get them to agree on what they think is a good approximation, and then use this data.
• At the end of the project, make sure everyone hears about the results.

Good luck, and I would be very interested to hear if this approach has worked for you.

Simon Anstey has over 20 years’ experience in tech writing, as a writer and manager. He works at SAP in the south of Germany, where he manages a team of 25 writers based in eight countries.

E: simon.anstey@sap.com T: @simonanstey72