Support requests as a business metric

Most membership owners treat support as a chore to get through: answer the emails, clear the inbox, move on. But every support request is a member telling you, unprompted, that something about your membership did not work as they expected. Taken together, those requests are one of the richest sources of business information you have, and they cost you real time every week.

Measuring support does not mean building a call center dashboard. It means counting a few things consistently, so you can see where members struggle, what that struggle costs you and whether your fixes are working.

Count requests per 100 members

The raw number of requests will grow as your membership grows, which makes it hard to read. A membership with 400 members and 60 requests a month is in the same position as one with 800 members and 120. Divide requests by members and multiply by 100 to get a figure you can compare across months:

Requests per 100 members = requests this month ÷ paying members × 100

If that figure rises, something is generating more confusion or more problems than before. If it falls while the membership grows, your fixes and your help content are doing their work.

Tag every request with a category

Counting tells you how much. Categories tell you why. Keep a short, fixed list and tag every request with one main category as you close it. A typical list for a membership might be:

• Login and access
• Billing and payments
• Finding content
• Technical problems
• Questions about the subject itself
• Ideas and feedback
• Cancellations and pauses

Seven or eight categories is plenty. If more than a small share of requests end up in an Other category, read through them and decide whether a new category is needed. Whatever tool you use, even a shared inbox with labels or a spreadsheet, the discipline of tagging matters more than the tool.

Measure speed and effort, not just volume

Three further measures show how well support is working, for members and for you:

• First response time: how long a member waits for a first reply. Compare it with whatever you have promised, as discussed in how quickly to answer support requests.
• Time to resolution: how long until the problem is actually solved. A quick first reply that leads to a week of back-and-forth is not good support.
• Replies per request: how many messages it takes to close a request. If it is often three or four, your replies may be missing information, and writing replies that solve problems the first time is the fix.

A worked example: what support really costs

Take a hypothetical online model railway society run by an enthusiast named Hamish. The figures are invented to illustrate. The society has 800 paying members and receives about 120 support requests a month, or 15 per 100 members. Hamish tags them for a month and finds:

• Login and access: 40
• Billing and payments: 30
• Finding content: 25
• Everything else: 25

Each request takes about 12 minutes on average, including reading, checking the account and replying. That is 120 × 12 = 1,440 minutes, or 24 hours a month. If Hamish paid an assistant $30 an hour to handle it, support would cost about $720 a month. Even if he does it himself, that is three working days he is not spending on content or marketing.

Login problems are the largest category. Reading through them, Hamish finds that most come from members who cannot find the password reset link or whose reset email lands in their spam folder. He moves the reset link beside the login button, rewrites the reset email and adds a line to the welcome email about checking spam. The next month, login requests fall from 40 to 20. At 12 minutes each, that saves 240 minutes, about four hours a month, from one afternoon's work.

He also notices that 48 of the 120 requests came from members who joined in the last 30 days, although new members make up only 80 of his 800. One in ten members is generating two in five requests, a strong sign that his onboarding leaves people confused.

Connect support to the rest of your numbers

• After changes: watch requests per 100 members for two weeks after any site change, price change or new feature. A spike tells you something needs explaining or fixing.
• By member age: compare requests from new members with those from established ones, as in Hamish's example.
• Against retention: note whether members with unresolved or slow requests are more likely to cancel. That link is why setting up support properly is worth the effort.
• Questions about the subject itself: these are not problems but content ideas. A cluster of similar questions is a lesson or guide waiting to be written.

Reduce requests at the source

The cheapest request is the one that never needs sending. For your top two categories each month, ask what would have stopped the member needing to write. Usually the answer is one of four things: a clearer page, a better email, a help article or a small change to how something works. Fix the cause, then watch whether that category shrinks.

Your monthly support report

1. Agree on a fixed list of seven or eight categories and tag every request.
2. At month end, record total requests and requests per 100 members.
3. Note the top three categories and their counts.
4. Record typical first response time, time to resolution and replies per request.
5. Estimate the hours support took and what that time is worth.
6. Choose one fix for the largest category and check the following month whether it worked.