How to run customer support: channels, service levels and tools.

For many customers, support is the main human contact they have with your company. A slow or inconsistent answer damages trust far more than the original bug. Done well, support also tells you where the product is confusing, which is valuable input for your product team.

Choose your channels deliberately

Every channel you open is one you must staff. Start small and add channels only when customers clearly need them.

• Email or web form into a helpdesk. The default for most business software. Easy to track, assign and measure.
• In-app chat. Good for quick questions during setup, but customers expect a fast reply. Only offer live chat during hours you can staff it, and say so clearly.
• Phone. Expected by some sectors, such as healthcare or trades. Expensive to staff; consider scheduled call-backs instead of a live line.
• Community or forum. Useful once you have many users who can help each other. Unhelpful when empty.

Whatever channels you use, route them into one helpdesk so every conversation has an owner, a status and a history.

Set service levels you can keep

A service level agreement (SLA) is a promise about response times. Set targets by priority and publish them. The figures below are a rule of thumb for a small business-to-business software company, not a standard.

Only put service levels into contracts once you have met them internally for several months. If you sell to larger customers who need contractual commitments, see the legal playbook on how service credits and liability interact.

Build a knowledge base early

Every question you answer twice should become a help article. A good article has a title phrased the way customers ask the question, a one-line answer at the top, numbered steps with screenshots, and a note on what to do if it does not work. Link articles from the product where the question arises. Review the ten most-viewed articles every quarter and retire anything out of date.

Run the queue well

• Tag every ticket with a short, fixed list of categories (billing, login, integrations, bug, how-to, feature request). Tags are what turn support into insight.
• Write saved replies for common answers, but always personalise the first line.
• Agree an escalation route to engineering: what counts as a bug, how it is logged, who decides priority and how the customer is updated.
• Run a rota so someone owns the queue each day, including cover for holidays.
• Hold a weekly review of the top tags, oldest open tickets and any service level breaches.

A worked example

Quaylane, a fictional Liverpool tech startup selling booking software to venues, ran support from a shared inbox and three people’s personal email. Customers chased the same issue in several places, and urgent problems sat unseen over weekends.

It moved everything into one helpdesk, published response targets, added an out-of-hours urgent line for venues on event days, and wrote 30 help articles based on the most common tags. Within a quarter, repeated how-to questions fell markedly and first response times became predictable.

Common mistakes

• Opening live chat without the people to staff it.
• Letting engineers answer customers directly without a record in the helpdesk.
• Measuring only speed and ignoring whether the answer was right.
• Closing tickets that are waiting on a bug fix, which hides the real backlog.

What to measure

• First response time and resolution time by priority, against target.
• Customer satisfaction score after each resolved ticket.
• Tickets per 100 active customers, by tag, over time.
• Reopen rate and the share of questions answered by a help article.