The Support Metrics That Survive Scrutiny

Most support dashboards in Indian ecommerce measure the same five things, and most of them are read wrong. The numbers are not usually false. They are just presented as five unrelated tiles, and read one at a time they can all move in the right direction while the customer experience gets worse.

A short note before the metrics. Every range in this article depends on category, average order value and how much of your volume is cash on delivery. A beauty brand with a low value basket and a high repeat rate has a different contact profile from an appliance brand with high value orders and installation requirements. Set your own baseline from three to six months of your own data before you compare yourself to anyone.

First response time versus resolution time

First response time is the easiest support metric to improve and the least meaningful one to report alone. An automated acknowledgement drives it to seconds. A canned opening line drives it to a minute. Neither has helped the customer.

Resolution time is the one customers actually judge. It is also the one that exposes real operational problems, because a slow resolution usually means support is waiting on someone else. A refund waiting on finance. A replacement waiting on inventory. A courier query waiting on a partner response.

Report resolution time as a distribution, not an average. Averages hide the tail, and the tail is where anger lives. Look at the median and at the ninetieth percentile together. A median of a few hours with a ninetieth percentile of six days describes a team that handles easy tickets fast and abandons hard ones.

Split resolution time by whether the clock was running inside support or outside it. If most of the elapsed time sits in a pending state waiting on another function, the fix is not a support fix. Do not keep first response time. Just stop treating it as a headline.

Contacts per hundred orders

Absolute ticket volume is close to useless as a management number, because it rises when the business grows. A team can improve every month and still see the total climb.

Contacts per hundred orders normalises for that. It scales, it is comparable across months, and it is the only volume metric that survives a growth period. Note that the sensible ranges vary widely by category and order value, so build your own baseline rather than importing one.

Two rules for using it well. First, compute it against orders in the period the contact refers to, not the period the contact arrived in. During a festive sale the two diverge badly, because orders spike on day one and the contacts about those orders arrive over the following two weeks. Second, break it down by contact reason. The headline number moving is not information. Knowing that damage related contacts per hundred orders doubled while everything else held flat is information.

CSAT and the sampling problem

Satisfaction scores are useful and are almost always read too confidently. The issue is not the question. It is who answers.

Response rates on post resolution surveys are low, and the people who respond are not a random sample. Two groups over respond, the delighted and the furious. The large middle group of customers whose issue was handled adequately mostly ignores the survey. That produces a bimodal distribution and an average that describes nobody.

There is a second bias that matters more, because it is inside your control. If the survey only goes to customers whose tickets were closed, every abandoned ticket, every customer who gave up in a self serve flow and every customer who never found the contact path is excluded by construction. The customers with the worst experience are systematically absent from the score.

Handle it three ways. Report the response rate alongside the score, every time. Track the share of responses in the bottom band rather than only the average, because that band is the actionable one. And survey a sample of customers who had a service failure but never opened a ticket, even though the numbers will be uncomfortable.

Backlog age, not backlog size

Backlog size is a snapshot that tells you almost nothing on its own. Two hundred open tickets in a business doing high daily volume may be perfectly healthy. The same two hundred could be a crisis.

Age is the metric with information in it. Bucket the open queue by how long each ticket has been open, and watch the oldest buckets. A queue where nothing is older than forty eight hours is under control regardless of size. A queue with a small but growing tail of tickets open more than a week is heading for a problem, and the tail is almost always made of the tickets nobody wants.

Backlog age also catches the most common queue failure, which is cherry picking. When agents are measured on tickets closed per day, easy tickets get picked first and hard ones age indefinitely. Volume looks fine. The oldest bucket grows quietly. Report the count of tickets over three days and over seven days as standing numbers and this becomes visible immediately.

Repeat contact rate

This is the quality signal most teams do not track, and it is the one we would keep if we could keep only one.

Repeat contact rate is the share of resolved issues where the same customer contacts again about the same issue within a defined window, commonly seven or fourteen days. It measures whether the resolution actually resolved anything.

Its value is that it cannot be gamed by the tactics that flatter every other support metric. Closing tickets fast raises it. Deflecting a customer who needed help raises it. Sending a scripted reply and closing raises it. Every shortcut that makes the dashboard look better shows up here as a penalty.

Track it by contact reason. A high repeat rate concentrated in one reason code usually means the standard resolution for that reason does not work, which is a process fix rather than a coaching problem.

Reading them together

The point of these five is the relationships between them, not the individual values. A few combinations worth knowing.

• Resolution time down and repeat contact rate up means tickets are being closed rather than solved.
• Contacts per hundred orders down and repeat contact rate up means contact was made harder, not easier.
• Satisfaction up while response rate falls usually means the survey base narrowed, not that service improved.
• Backlog size flat while the oldest age bucket grows means cherry picking in the queue.
• Contacts per hundred orders up in exactly one reason code is an upstream defect, and belongs in an operations review rather than a support review.

Put them on one page in that order. Volume, then speed, then quality, then queue health. Read top to bottom as a single sentence about the week. A support dashboard that cannot be read as one sentence is a collection of numbers, not a measurement system.