How to build a knowledge base for your hosting company

A good knowledge base does two jobs for a hosting company. It answers customers' questions before they open a ticket, and it gives your support team one reliable source for how things are done. Most hosting companies start with a handful of articles and a lot of good intentions. This guide covers how to build one that keeps working as you add services, customers and staff.

Start with the questions you answer every week

The best first articles come from your ticket history, not a blank page. Pull up last month's support tickets and group them by topic. You'll usually find that a small number of questions make up most of your tickets: how to point a domain, how to set up email, how to reset a control panel password, why a site is slow, how to upgrade a plan.

Write those articles first. Each one you publish is a ticket your team doesn't have to answer again, and a customer who gets their answer straight away.

Separate customer guides from staff procedures

Hosting companies need two kinds of documentation, and they shouldn't be mixed together.

Customer-facing guides explain how to use your services:

• Getting started with each product
• Setup guides for domains, email, SSL and control panels
• Billing, upgrades, cancellations and refunds
• Troubleshooting common problems
• Migration guides for customers moving from another host

Internal procedures explain how your team works:

• Escalation paths and on-call contacts
• Abuse and spam handling
• Suspensions, refunds and billing exceptions
• Outage and incident response
• Server and infrastructure notes
• Onboarding for new support staff

Keeping these apart matters. Customers shouldn't see your internal notes, and staff shouldn't have to dig through customer guides to find a procedure. The simplest approach is one place with clear permissions: customer guides are public, and internal procedures are visible only to staff.

Use a structure that grows with your services

Organise customer guides by product first, then by task. A structure like this works for most hosts:

1. Getting started, covering creating an account, logging in and your first order
2. Web hosting, covering control panel, files, databases and email
3. VPS and dedicated servers, covering access, operating systems and backups
4. Domains, covering registration, transfers and DNS
5. Billing and account, covering invoices, payment methods, upgrades and cancellations

When you launch a new product, it gets its own section, and nothing else needs to move. Inside each section, nest pages so that a broad topic like "Email" can hold specific guides like "Set up email on iPhone" without cluttering the top level.

Write guides customers can follow

Customers usually open a guide in the middle of a problem, so make each one easy to follow:

• One task per page. "Point your domain to your hosting" is better than "Domains and DNS explained".
• Say what they need before they start, such as their login details, a domain registrar account or SSH access.
• Number the steps, and keep each step to one action.
• Show what success looks like, so they know when they're done.
• Link to the next step, such as setting up email after pointing a domain.

Write in plain English and avoid internal jargon. If a customer has to search for a term you used, the guide has failed them.

For more on writing pages like this, see how to write documentation people actually use.

Document your staff procedures too

Internal documentation is often the part hosting companies skip, and it's the part that makes support consistent. When procedures live in people's heads, two staff members handle the same situation two different ways.

A simple template keeps procedures easy to write and easy to follow:

• When to use this: the situation it covers
• Who can do it: which roles are allowed
• Steps: what to do, in order
• Escalate if: when to pass it to someone more senior

Start with the procedures where mistakes are costly, like suspensions, refunds and abuse reports, then work outwards.

Link it from everywhere customers already are

A knowledge base only reduces tickets if customers find it. Link to it from:

• Your client area's navigation and homepage
• Welcome and order confirmation emails
• Ticket auto-replies, with links to the most relevant guides
• Your support team's canned responses
• Your status page and community channels

When a support agent answers a question that has a guide, they should link to the guide. Customers learn to look there first, and you find out which guides need improving.

Keep it current

Out-of-date documentation is worse than none, because customers follow it and get stuck. A few habits keep it accurate:

• Give each section an owner who reviews it when the product changes.
• Update guides as part of every product change, not afterwards.
• Watch which pages get the most views. Popular pages are worth polishing, and the questions still arriving as tickets show you what to write next.
• Keep a version history, so you can see what changed and undo a mistake.

A starting checklist

• List your 20 most common ticket topics
• Write a guide for each of the top 10
• Create a private staff section with your top 5 procedures
• Organise customer guides by product
• Link the knowledge base from your client area and welcome emails
• Add guide links to your canned responses
• Assign an owner to each section

If your knowledge base currently lives inside your billing system, it may be time to give it a home of its own. See how Docvora compares with the WHMCS knowledgebase.