Calculate Support Time per Active Reader

Support time per active reader is the human time spent helping a defined group during a period, divided by the number of active readers in that same group and period. It helps an author see whether a paid skill's day-to-day workload fits the business they want to run.

The number is useful only when both sides of the equation are clear. Count work, not the hours a message sits unanswered. Define “active” using an observation you actually have. Keep launch setup, product development, and separately sold consulting visible without quietly mixing them into the support total.

The worksheet below is an original resource with fictional numbers. It is not a benchmark, a pricing recommendation, or a claim that Skillfully automatically measures support time.

If a reader sends a question on Monday and you spend ten minutes answering on Tuesday, the work took ten minutes. The reader waited much longer. Both matter, but they answer different questions.

Support software uses specific definitions. Intercom's responsiveness documentation distinguishes response time from time to close, and notes that snoozed time can count toward closing time. Do not treat a dashboard's elapsed duration as your labor without checking its definition. Intercom's responsiveness guide

For a manual author log, count minutes actively spent reading the request, investigating, reproducing the issue, replying, and doing necessary follow-up. Stop the timer while waiting or working on something else. Zendesk's time-tracking guide explicitly provides pause and resume controls for interruptions such as unrelated calls. Zendesk's time-tracking documentation

You can begin with a spreadsheet rather than adopt a new help desk. The important part is a consistent rule that includes the work you actually do.

Use these columns: date, reader reference, issue reference, category, minutes worked, person doing the work, and next action. A reader reference can point to a restricted support record; your summary sheet does not need their name or the full conversation.

Choose a small set of categories, such as access, setup, method clarification, and output problem. Keep product improvement in a separate category. If one session spans several tasks, split the time when practical or note the estimate instead of pretending it is exact.

Here is a fictional week for an author, Victor, whose companion helps readers plan a short guided walking tour. The sample summarizes individual work-session entries; all values are invented.

The direct support total is 120 minutes. Victor also records 45 minutes of improvement work and 60 minutes of paid coaching. None of that work disappears; it simply belongs to a different question.

Suppose Victor has 50 paid readers with access during the week. Of these, 30 have a recorded qualifying activity under his stated definition. Six of those thirty request help, producing eight support issues. Assume the 120 support minutes all concern those active paid readers.

The calculations are:

• Support minutes per active paid reader: 120 ÷ 30 = 4 minutes.
• Support minutes per paid reader with access: 120 ÷ 50 = 2.4 minutes.
• Support minutes per reader who requested help: 120 ÷ 6 = 20 minutes.
• Support minutes per issue: 120 ÷ 8 = 15 minutes.

These are different measures, not competing answers. Four minutes describes the workload spread across the active group. Twenty minutes describes the average effort for people who needed help. Neither says every reader consumed that amount of time.

If the only activity signal is a recorded instruction load, call the group “readers with a recorded load.” Do not imply they finished a tour plan. If you cannot identify distinct readers reliably, use an available denominator such as paid accounts with access and label it accurately.

Support for someone who never managed to start still counts. Put it in the paid-access group's workload or a separate pre-activation support line. Do not exclude difficult onboarding cases merely because those readers failed to qualify as active.

For a simple management estimate, choose an explicit hourly labor value. Suppose Victor uses a fictional planning rate of $60 per hour. This is an assumption for valuing his time, not necessarily money paid out or a market rate.

Estimated direct support labor = 120 minutes ÷ 60 × $60 = $120.

Estimated direct support labor per active paid reader = $120 ÷ 30 = $4.

The 45 minutes of guide improvement adds $45 of separately identified work at the same assumed rate. If Victor chooses to report support plus improvement, the combined amount is $165, or $5.50 per active paid reader. Label the combined measure so it does not silently replace the direct-support figure.

For several helpers, calculate each person's time at the chosen rate and sum the amounts. Show software fees and other costs separately. This worksheet estimates a workload cost; it is not profit, revenue recognition, or a complete accounting model.

In a public discussion, course creator u/thedesignedlife described:

“students reaching out for 1:1 support that can be directly posted to the forum, such that answering their questions becomes valuable for everyone.”

The comment is one creator's account, not a support benchmark or proof that a forum will solve your workload. It illustrates why identifying repeated questions can be more useful than looking only at a total. Original comment

For Victor, setup accounts for forty minutes, so he should read those issues before deciding what to change. If several readers misunderstood the same instruction, a clearer guide may help. If each had an unrelated account problem, one tutorial may not address them.

Do not move private questions into a public forum just to reduce your workload. A general answer can be rewritten without the reader's personal context. Questions about the method's output may call for deeper work using the guide to measuring agent skill quality.

A lower support average is not automatically an improvement. Readers may be receiving clearer guidance, or they may have stopped asking because the help route is difficult to find. Check unresolved issues and reader outcomes alongside the time log.

Compare periods with similar definitions and note changes in the audience, product revision, or launch stage. Keep exceptional incidents visible rather than deleting them to improve the average. An outage can dominate a small week and still be real work your business had to absorb.

End the review with one concrete improvement and a plan to observe its effect. The point is to understand and reduce avoidable work while preserving useful help.

To turn your established method into a skill with a manageable reader experience, visit Skillfully and choose Book onboarding. Bring the recurring support questions and the task readers are trying to finish.