Keeping written documents of questions, answers, and information is key when it comes to running a support department successfully. No one wants to run their support without writing down answers, troubleshooting tips, workarounds, processes, and tasks undertaken and performed by support.
It’s also unfair on your support staff to not do this. Without this information, they all have to learn these things separately and keep all of the important information in their memory. It’s also unfair for customers, as without this basic knowledge made available to them they have to contact customer support for every little problem.
Documenting
When we say documenting, we don’t mean on the Slack channel where people ask questions from company’s Product department or colleagues. We also aren’t referring to people mentally documenting things. After all, that is useless unless there is some way to get the information from one brain to another. The human brain isn’t made for storing things a group needs access to. Better to allow your staff to have that space and put it to better use, such as thinking creatively and coming up with new solutions to problems.
This is why you need to write everything down.
I recommend that you start documenting as soon as possible. Write down all the questions that your clients have during a pilot run/soft launch. Also try to come up with some questions of your own that a client might not have. There are some basic questions and documents that you should go through as well, including:
How To – a basic user guide that guides users through the entire product/platform
Basic questions on billing, accounts, passwords, etc.
Any known limitations of the service or features
API
The documents that you write will usually be put in front of two different audiences; the internal customer support team and the external customers. When you put together a knowledge base and begin documenting knowledge, it helps to train new employees and reduces how many support requests come in to the team as customers can learn from previous experience.
Internal Documentation
Having internal documents is as important as having external ones. What if your only support agent gets sick and you have to take over? How can you find answers to complex technical questions when the only one who has those answers is not at work? You can’t keep customers waiting until the agent is feeling better and back at work.
If you pre-launch your product or do testing with real customers, then this gives you a great chance to understand the kind of questions a customer will have. You should find some way to collect and store these questions. Do you have them in emails? Great! It’s time to look through them and collect questions, organizing them into different categories such as Product, Billing, API and User Accounts. Ideally, you should be documenting the questions and answers in real time as it’s much easier to remember answers at the time – especially if the support agent had to perform internal actions to deal with the situation – and it helps agents get in the habit of documenting support requests.
You should get a ticketing system set up as soon as possible, as most ticketing systems come with Knowledge Base functionality. However, you don’t need a tool from the very beginning to handle documentation, especially if you still aren’t sure which ticketing system would be best for you. Shared documents – Word or Google Docs – is a good choice at the start. It allows you to collect information and store it in a central place. You can always transfer the information to a real Knowledge Base afterwards. Starting documentation is more important than knowing where you’ll be storing everything.
External Documentation
Make sure instructions are written as clear as possible. There’s nothing worse than having to try and understand long sentences and chapters. Keep the information easy to read using screenshots / pictures, GIFs, and videos.
External documentation should preferably be attached to the product User Interface, so that the information is easily accessible to customers when they need it.
It may seem like providing answers to customers is slow at first, as you have to investigate the topics and you must learn from their questions. Take it as a chance to document things immediately. For example, let’s say a customer asks about the advantages of connecting to your platform through an API. Write out a document about the topic and use it to answer the client’s queries. In time there will be less and less undocumented topics, questions, and situations, but you’ll always need to write new documents. As the software continues to change and evolve, so too must the documentation.
Don’t wait too long to publish external documentation either. Putting together an FAQ is a great starting point. This FAQ should be kept to a maximum of between 10 and 15 common questions. If you are using an online Knowledge Base then the information will live and evolve. As long as a customer has access to the online instructions – as opposed to documents shared via email – and follows them, they will always have all of the latest information to hand. You want the content to be read and used and you also want to collect any experience people have with it to ensure it still works and, if it doesn’t, what needs to be changed.
Also take the time to create a clear onboarding program for customers based on their experiences with a soft launch/pilot scheme. This helps customers in the future to better self-service and reduces how many questions and queries your customer support agents get about basic functions of the software.
The good news is that most ticketing systems have Knowledge Base functions built into them, which makes it easier than ever to adopt this vital feature.