Starting from scratch

When it came to putting together our support stack, I wanted to focus on developing a small but high-quality set of fundamentals.

For the volume of tickets that we get, there’s not really a need to go all out with live chat and constantly manned phone support. Add to that the fact that we rarely get requests from social media, and the best fit for us right now is a solid help desk for emails and a top notch knowledge library to help users to help themselves.

We did already have a set of help guides, but they needed a lot of work. The library had been put together in a very piecemeal fashion, and with little to no curation. Each article had been added over time by different people, with different writing styles and who covered topics in different ways. They were messy, inconsistent, and sometimes plain wrong!

Given that there was so much to do, I knew that I wouldn’t be writing the new documents on my own, and I wanted to ensure that each article was consistent and of a good standard. It was time to draw up a style guide.

There’s no one right way of coming up with a style guide, but I thought that it would be helpful to share how we did it.

1. Find examples of best practice

I asked my team to take a look at help files for other SaaS products, and also to think any guides or instructions that they used recently. I especially wanted to know about guides that were really helpful and easy to use, as well as those that missed the mark.

We brought all of our examples together to discuss what we did or didn’t like about them:

  • What made these instructions easy to follow? Why was this one hard to use?
  • What’s the tone of this guide? Would that fit with our brand?
  • Have they made any style or formatting choices that we like?

2. Discuss and come to an agreement

When we’d made notes about the good, the bad and the ugly aspects of our examples, we began to discuss the kind of knowledge base that we wanted for our company.

I included the whole team in this part of the process. It would have been quicker and easier for me to come up with something on my own, but I felt it was important to work together on it.

Not only do I value their input, I also know that if they agreed with the guidelines, or at least understood the reasoning behind each point, they were more likely to follow them consistently.

3. Write it down and share it

After our discussion, I drew up a document that laid out each of our points.

I tried to make it as easy as possible for the team to both understand and implement the rules from the guidelines. I always tried to demonstrate how each rule could be put into practise using things like:

  • Examples of tone and sentence structure
  • HTML code for formatting so that the team could copy and paste if they needed to
  • Links to existing examples on our help pages

When the document was finished I shared it with the team via email and also posted it in our ‘Hivemind’ shared documents area, so that it was within easy reach when people needed it.

One hundred and thirty help guides later and we have a solid and (hopefully) useful knowledge library that is used by both our customers and by our support team.

The challenge now is to ensure that it stays up to date, and evolves as the product does. Starting on the right foot, with a solid style guide, means that I know that each new article can be written by anyone on the team, that it will add value to our product and, most of all, that it will be helpful for our customers.