Measure first reply time, unanswered requests, resolution, and repeat questions with a small manual review. Includes clear definitions and worked examples.
Start with four questions when measuring live chat support: Did someone reply? How long did the customer wait? Did the conversation produce a useful outcome? What keeps causing customers to ask for help?
A small SaaS team can answer these with a consistent manual review before investing in a reporting system. The method below uses conversation history and a private worksheet. It does not assume that tkit.ai includes a metrics dashboard, automatic categorization, exports, or service-level timers.
Define the conversations you are counting
Choose a review period and a clear unit, such as one new customer conversation. Exclude internal tests and obvious spam using the same rule each time. Keep follow-up messages within the original conversation instead of counting every message as a new request.
For low volumes, inspect every eligible conversation. For larger volumes, use a consistent sample and label the results as sampled. Record the denominator with every percentage: “2 of 12 requests” is more informative than “17%” alone.
Keep only what the review needs. A private record can contain a conversation reference, start time, first human reply time, outcome, and broad topic. Avoid copying customer messages or personal details into another system unnecessarily.
1. First human reply time
For this review, define first human reply time as the elapsed time between the first customer message and the first reply from a team member. Keep automated acknowledgments separate if your setup has them. A receipt confirmation does not show that someone understood the request.
The distinction between calendar time and working time matters. For example, Zendesk's metric definitions include a first reply measure counted within business hours. If you calculate your own working-time measure, document the schedule, holidays, and time zone.
Suppose a message arrives at 17:50, coverage ends at 18:00, and the team replies at 09:20 the next working day after reopening at 09:00. That is 30 minutes of covered time. If the next working day is the following calendar day, the customer's elapsed wait is 15 hours and 30 minutes. Both descriptions are useful, but they answer different questions.
Review the median and the longest waits alongside the individual cases. With five reply times of 2, 3, 4, 6, and 90 minutes, the median is 4 minutes and the average is 21 minutes. The 90-minute case still needs attention even though most replies were quicker. These are illustrative figures, not customer results.
2. Requests still waiting for a human reply
At a fixed review time, count eligible conversations that have not received a human reply. Show their ages as well as the total. A message received just before the review is different from one left overnight despite a promised response.
Do not assign unanswered conversations a zero-minute reply time or silently exclude them from the report. Keep them in a separate waiting group until they receive a reply. Otherwise, a fast median can hide customers who never heard back at all.
For example, if 18 of 20 eligible conversations received a reply by the review, report “18 replied; 2 still waiting” and state the cutoff time. Do not call the remaining two missed commitments without checking their arrival times and the expectations you gave those customers.
3. Outcomes rather than closed conversation counts
Use a few explicit manual labels: resolved, useful workaround provided, waiting on the team, waiting on the customer, and outcome unknown. Decide what evidence qualifies for each label before comparing weeks.
A customer confirming that a fix worked is stronger evidence than a conversation being marked closed. Silence may mean the customer succeeded, got distracted, or gave up. Keep that uncertainty visible.
If you track time to resolution, specify the start and end events and report unresolved cases separately. Compare similar request types. A navigation question and a difficult product defect need different work, so changes in the mix can change your numbers even when the team's process stays the same.
Review speed alongside outcome quality. Faster first replies are useful when they help customers progress; a quick generic answer followed by several rounds of clarification can still be a poor experience.
4. Repeated reasons for contact
Give each reviewed conversation a short topic based on what the customer was trying to do: find an invoice, invite a teammate, or finish an export. Add a second note when the cause is known, such as unclear navigation or a reproduced error. Keep “unknown” available rather than guessing.
Compare the count with relevant product activity when you have it. Ten export questions during a much busier week may mean something different from ten during a quiet one. Do not claim an improvement from falling contact volume alone; check for reduced usage or a broken support entry point.
Use the founder-led support guide to turn recurring questions into documentation or product work. If reply wording needs improvement, the support templates provide a starting point to adapt to the actual case.
Make one decision from the review
Finish each review with a specific change and a way to check it. A cluster of long waits outside coverage might call for clearer expectations. Repeated questions about one setting might call for a better label. Unknown outcomes might call for a more precise closing question.
Keep your definitions stable long enough to compare results, and note changes in traffic, coverage, or product releases. The objective is to find an action that makes support more dependable. Start with the conversations in your shared workspace inbox, preserve the uncertainty in the data, and check whether the next change helps.