Awesome docs deflect tickets from your inbox, make for happier customers, and even boost up the effectiveness of your internal teams.
Documentation is frequently the first interaction that a customer has with your product and brand. When someone is having trouble, 91% of them prefer to read documentation rather than ask someone for an answer. So, instead of reaching out directly to your support team, they’ll often do a quick search through your knowledge base instead. It’s imperative that you get that first impression right—otherwise, you’ll run the risk of losing trust, or even turning away potential users.
Equally important is the amount of time that it takes for a customer to resolve their issue. Many users prefer documentation because it helps them solve the issue on their own quickly.
People, whether they be coworkers at your company, or customers using your product, don’t want to have to wait for responses. According to MIT queuing theory professor, Richard Larson, “the psychology of queuing is more important than the statistics of the wait itself.” We tend to think we’ve been standing in line for longer than we really have; our perceived wait time can feel like an eternity even if it’s just been a few minutes. For customers, how long a line seems to be is the problem, despite how quickly it might actually be moving.
Documentation allows your customers to cut the metaphorical line. It also helps your team deflect tickets, create a better customer experience, and potentially draw new users in—as long as it’s effective. Keeping your docs up to date and informative is one of the best ways to do this.
Here are three tasks to keep your documentation in tip-top shape.
Documentation is one of those things that is seldom owned by a single person. Unless your support organization is extremely vast and has a whole designated ops team, this is likely something that falls a little bit to everyone. Unfortunately, that means something pretty important to customer experience is exposed to potential pitfalls.
Consider the bystander effect. The bystander effect predicts that the more people assigned to a specific task, the less likely people are to actually take responsibility. The thinking is: “oh, I don’t need to do that. There are five other people who are assigned to do this, too. One of them will do it.” But, most frequently, no one actually does. With documentation it’s no different: unless someone is specifically assigned to do something, it’s not likely that it will get done of their own volition.
When you are picking someone to lead the charge in making your documentation awesome, consider the people that have enjoyed doing it in the past or really have a knack for it. A recent study shows that 25% of employees would be more satisfied if they were given the opportunity to do what they do best. There’s probably someone who cares a lot about your docs and has historically done really good work when updating them. Empower them to take the reins, and you’ll be on your way to doc excellence.
Human beings are, by their nature, fallible. They make mistakes, forget to do things, break processes, and just generally mess up. When it comes to your docs, try to take as much human touch out of the process as you can.
One way to automate update requests is through using Slack. When an agent or other employee finds something that would either make a good doc or needs to be updated, they can either post something in a Slack channel or add a custom emoji reaction to an existing post. This kicks off an automated workflow that will track the ticket, message or issue and forward it through to a venue of your team’s choice. The benefit here is that people are able to request new documentation or suggest improvements without needing to do a whole bunch of lifting, and you can then get those requests sent automatically to where it makes the most sense for your team. That could be a Slack channel, and email inbox, or any other queue that makes sense.
Any step of the process that you can take out of the hands of a human is a good step forward. There’s nothing more frustrating than thinking that you’ve found an answer, and realizing that all the information inside of the article is incredibly old.
One way that some companies are handling this need for efficient updating is by setting timers on their docs that trigger notifications to review them within a certain time period. For example, if you were to set a three-month timer on one of your docs, your team (or doc manager) would receive a notification to go and review, and could then mark it as “done” until another three months is up. Some tools have this functionality built in (like Guru), but you can also do it by creating a Google sheet of all of your docs and the last times they were updated.
This timer should be different depending on the parts of your product that the documentation deals with. For instance, if it’s a part of your product that is pretty core, stable and unlikely to change, setting a notification timer for three months is probably fine. If it’s a new beta project that your team is constantly updating, you may even set the timer to every two weeks until the iterative process slows down. Play with times and see what is easiest to maintain (and makes the most sense) for your team.
Yes, we know that we just told you to cut down on the number of people involved in the documentation process. That being said, as long as you’ve put a single person in charge of the process, it’s still okay to encourage members of other teams to contribute. This helps for a few reasons: members of other teams (especially customer-facing ones) will have different perspectives on what may or may not be helpful for your customers. They also have different ways of presenting and processing information.
Not all of your customers are going to be the same and learn the same way—by letting people with multiple perspectives contribute to and update your documentation, you increase the likelihood of reaching more people and having more meaningful docs across the board. Diversity of perspective is incredibly important.
A great example of this is your more technical docs, such as API documentation or advanced feature guides. Support people and engineers have extremely different communication styles— and you should try to write your docs for the audience that will read them.
“Being able to rewire the neurons in someone’s brain so that they understand something they didn’t understand before is extremely satisfying,” Steve Losh says. “Seeing (or hearing about) the ‘click’ when a bunch of concepts suddenly fall together and make sense never fails to make my day.”
Your engineers can write for a technical/engineering-heavy audience in a more accessible way than your support team can. Let them do a bit of work in the docs, learn from how they write and what their process is, and then train your team up to do the same. You’ll do better at getting those “Ah Ha!” moments when you write in a language that makes more sense to your customers.
Conclusion
Documentation might seem like a necessary evil, but it is also actually a really helpful secret weapon in your customer support arsenal. Awesome docs deflect tickets from your inbox, make for happier customers, and even boost up the effectiveness of your internal teams. Beyond that, they’re an opportunity for growth and advancement for team members that are passionate about them.
These three tips will take your docs from blah to beautiful and keep them updated to boot. What are you waiting for? Get going!