Support receives more messages over a week. The manager sees the counter rising and plans to hire another agent. Yet some traffic is automated notifications, some is clarification within open cases, and some is new problems following a change to payment terms. One total mixes different work and encourages a premature decision.
Assess real support demand through customer needs, the work involved and its effort, not just message or ticket counts. Define the counting unit first, examine your own sample and only then decide what to change: team capacity, guidance or a process outside support.
This article offers a diagnostic method for managers. It does not replace shift planning or establish a universal ticket quota per agent. Its purpose is to identify the work behind the traffic and the intervention worth testing first.
Messages, tickets and needs are different units
A message is an individual statement or channel event. A ticket is a record used to organize work. A need is the outcome the customer wants: a document, restored access, clarification of a payment or correction of an error. These units do not necessarily match one to one.
One need may generate several messages and even several records. Conversely, a long-running ticket may contain different independent questions. A rising ticket count can therefore reflect changed creation rules rather than more customer needs.
Retain both levels for diagnosis: the record identifier and a description of the need. You do not have to change or merge operational tickets immediately. Analytical grouping is a research method, not an instruction to delete records or rewrite request history.
Start with a question, not every possible metric
A useful question is specific: “Why did manual work grow after invoices changed?” or “Which requests cause the most cross-department checks?” It defines the scope: channels, categories, period and customer types. Do not mix external support with internal assignments if the decision concerns customer traffic only.
The Zendesk customer-request analysis distinguishes traffic without a service need, repeatable work and contacts caused by business-process failures. That is a useful reason to examine your own traffic, but another study's proportions are not a benchmark for your company. Your conclusions need your own data.
Record rules before examining the sample. Which event places a record in the period? Are weekends and out-of-hours traffic included? How are carried-over cases counted? When these rules change unnoticed, week-to-week comparisons become unreliable.
Build a sample without convenient bias
For an initial diagnosis, review all records from a consecutive period if volumes are small. For a large flow, define a selection method in advance that covers different hours, days and channels. Do not select only closed, short or easily understood requests.
Flag a major incident, campaign, price change or seasonal peak separately. Do not hide those records, but do not present an unusual period as normal. If a channel is missing from the sample, explicitly limit the conclusions to the channels studied.
Use reference numbers and restricted conversation access. A management review generally does not need buyer names, addresses or complete message texts. An example can be anonymized while preserving its work logic and a link to a controlled record for verification.
A simple request-coding scheme
Separate two dimensions: what the customer needs and why contact was necessary. “Payment” only partially answers the first question: requesting a document and reporting a duplicate charge require different actions despite sharing a topic.
- No service need. A technical notification, confirmed spam or another event not requiring a customer reply. Retain the reason for excluding it.
- Ordinary need. Guidance or an action included in the service and available to the customer. Repetition does not make it unimportant.
- Contact caused by a deviation. Expected fulfilment did not happen: an incorrect document, an unavailable feature or conflicting guidance.
- Undetermined. Information is insufficient or reviewers disagree. This is a visible remainder for review, not a bin for inconvenient cases.
Add a short basis for each classification. Store routine nature, risk and complexity separately: an ordinary need can be critical, while a deviation can be easy to fix. Do not use an analytical category as an automatic reason to lower priority.
Check whether two people interpret the rules alike
Have two employees independently code a small shared subset. Discuss disagreements using examples and refine the glossary. If one reviewer calls every repeated question a deviation and another calls it an ordinary need, the final proportions reflect coding style rather than traffic.
Do not change categories just to create a better-looking chart. Retain the glossary version and the reviewed record list. Use the same definitions for the next measurement or explicitly identify the methodology change.
A hypothetical example: what 120 records show
This example is invented to explain the method. It is not market statistics or a HelpDeskStar customer's result. A team reviews 120 records: 20 have no service need, 60 concern ordinary needs, 30 concern deviations and 10 remain undetermined.
There are 90 classified records with a service need. Of these, 30 involve deviations: one third of the classified portion, not one third of all 120 records. No conclusion is available yet for the 10 undetermined records. Do not silently place them in a convenient category or call 90 the final total of all needs.
Those 90 records do not necessarily equal 90 independent needs either: that requires separate checks of links between records and questions within them. An honest initial finding may be more modest: “We know the composition of classified records and what to check next.”
If most deviations concern one new invoice template, the next logical step is to review the document with finance. Hiring an agent may ease the queue but will not remove the cause of those contacts. Correcting the template still does not remove the need to help customers already waiting.
Count does not equal effort
Alongside frequency, assess the work involved: a simple answer, a check in another system, exception approval or several departments' participation. Where possible, use actual active work time rather than only creation-to-closure time. Waiting for a partner can be lengthy without continuously occupying an agent.
If accurate time records are unavailable, start with transparent qualitative effort groups and test them against examples. Do not turn that assessment into a precise staffing norm. Staffing also requires arrival patterns over time, team availability, response requirements and skills.
Do not judge employees by raw closure counts. Someone handling complex investigations may close fewer cases while doing more necessary work. Demand diagnosis should guide process changes, not encourage quick closure of difficult issues.
Turn an observation into one testable change
For the chosen cause, create a short decision record: what was observed, which evidence supports it, who tests the hypothesis, what changes and when measurement repeats. One limited experiment is better than “automate everything” without an owner.
For ordinary information requests, test whether guidance is clear or a document is accessible. For deviations, address the cause in the relevant department. For noise, inspect its source and safe selection rules. Test borderline cases before filtering so a genuine complaint is not hidden.
After the change, compare the same scope, category mix and unfinished work. Fewer records do not always mean better service: a channel may have failed or customers may find contact harder. Check contact availability and resolution quality before declaring success.
Using HelpDeskStar for this approach
Consider HelpDeskStar as a workspace for customer requests and internal tasks. During a demonstration, check how to record a category, an owner and a follow-up task for the department able to remove the cause of contacts. Confirm the available analytical data format and how the required attributes can be maintained in your configuration.
This method does not assume the product automatically identifies intent, counts independent needs or builds the described sample without configuration. A small team may initially need only a protected analytical spreadsheet. What matters is that its findings return to operational tasks rather than remaining a separate report.
For broader context, read our guide to support quality control. Categories, roles and review procedures can be agreed during turnkey HelpDeskStar implementation. Start with the decision you need to make, not the most complex possible report.
Good demand accounting explains why the team works, not merely how many times it replied. Separate messages, records and needs, keep undetermined cases visible and test changes with your own data. Choosing between extra capacity, self-service and a process fix will then become more concrete.