Resolution time

Settle what the clock measures before comparing it to anyone

Resolution time is the elapsed period between a customer raising an issue and that issue being settled. Published benchmarks vary widely because they measure different things: some count business hours and some elapsed hours, some stop at the agent's last reply and some at the customer's confirmation, and some exclude cases awaiting a third party. In ecommerce the last exclusion matters more than anywhere else, because a large share of post-purchase cases wait on a carrier, a warehouse, or a refund clearing. Some of those waits are published rather than guessed: FedEx sets out its own claim windows, and USPS publishes how it measures service performance against a stated standard. A benchmark that excludes third-party wait measures the support team. One that includes it measures the customer's experience.

Before comparing a resolution time to anybody else's, settle what the clock is measuring, because I think the industry standard measures the wrong interval. For the last 20 years, customer service teams have waited for the customer to reach out, and they are measured on first response time, average handle time, resolution time and CSAT. None of those asks whether the order was fixed. My co-founders and I worked out that if you can spot the upstream issue in real time, you can fix it before it becomes a ticket, and then it is no longer resolution time at all. It is complaint prevention. A ticket can close inside target while the parcel is still sitting wherever it stopped. Benchmarks assembled from that measure tell you how quickly businesses close conversations, which is not the same subject as how quickly they solve problems. Building a comparison against your own orders instead is ecommerce benchmark, and the measure definitions sit with ecommerce KPIs.

Report the median and the 90th percentile, never the average

Average resolution time is total resolution time divided by resolved cases in the period, and it is the least informative version of the measure because a small number of long-running cases distort it. More useful are the median, which describes the typical case, and a percentile such as the 90th, which describes the tail where dissatisfaction concentrates. Related measures are first response time, which sets the customer's expectation, and time to first meaningful update, which is more honest where an automated acknowledgment is sent instantly. Resolution time should be segmented by contact reason, since order-status and refund cases have structurally different floors.

The point of measuring it is not a faster scramble. As I said on Add To Cart: "Keeyu is not about firefighting all the time. It's actually about helping our retailers understand the health of their business and then be able to make effective ops changes to avoid that pain."

First-contact resolution moves the number more than any speed initiative

First-contact resolution is the share of cases settled in one interaction without transfer or follow-up. It improves resolution time more reliably than any speed initiative, because most elapsed time in a case is queue time between touches rather than work time. Three things determine it. Agent access to order, fulfillment and carrier data in one view, which is a helpdesk question answered by third-party integrations. Authority to act without escalation within defined limits. The ability to execute the remedy directly rather than requesting it from another team. The research case for treating this as the priority is Harvard Business Review's finding on customer effort, where the work the customer is made to do predicts disloyalty better than how the reply was worded. Measuring it honestly requires counting reopens and repeat contacts about the same order, which are the two ways an apparent first-contact resolution turns out not to be one.

Much of the clock runs before anyone starts fixing anything. On Spotlight Fridays I described what the agent starts with: "a customer's name, an email address, maybe they got an order number, and there's no one place to go drop that information in and then establish exactly where it's broken ... constantly new applications are being loaded into a stack and they were just bolt-ons ... and so it's super fragmented and that's why there just isn't one path to it."

Three kinds of automation, and only one collapses the interval

Automation reduces resolution time in three distinct ways, and conflating them causes disappointment. Deflection removes cases entirely by answering before contact, which improves totals without improving the measure for the cases that remain. Assisted resolution shortens work time by assembling context and drafting responses. Automated resolution settles defined case types without a human, which is where the largest reductions come from and where the constraint is the ability to act on the underlying system rather than to compose a reply. Deflection is customer self-service, and the tooling layer is the automated ticketing system. Reporting should separate the three, since a rise in deflection can mask a deterioration in the resolution of real problems.

Which sets up the only automation that moves this number properly. Automating the reply shortens the part of the process that was already short. Automating the resolution means the system reads the order state across every connected platform, acts on it, and records what it did, and the interval collapses because the looking-up disappeared rather than because anyone typed faster. When we launched Keeyu, we only believed in detection, and teams fixed the issues manually. Then we realized automation was the real answer, and started building the system of action, because fixing by hand is not economically viable at volume. That is the difference between a fast support function and an operation where the ticket did not need to exist, which is proactive versus reactive customer service stated as a metric.

Most of the elapsed time is swivel-chair work

A substantial proportion of post-purchase cases cannot be resolved by the support function alone because the facts sit with a carrier or warehouse. Carrier investigation windows, claim processing periods, and warehouse inspection queues each impose a floor on resolution time regardless of support performance. A USPS Missing Mail search cannot be opened before the parcel qualifies, whatever the customer has been told, and that floor belongs in the report rather than in an apology. The operationally useful response is to distinguish cases blocked on a third party from cases in the team's own control, report them separately, and act on the blocked ones where policy allows, for instance by replacing a stalled parcel rather than waiting for the investigation to conclude. The connection work that makes the carrier state visible in the first place is carrier integration.

This is where most of the elapsed time actually lives, and it explains why resolution time resists improvement. When a business sees ticket volume spike, hiring more agents is the wrong response, because you are hiring humans to do work systems should do, and more agents just scale the inefficiency. Most of an agent's day on a post-purchase ticket is not resolution at all. It is swivel-chair work: opening the storefront, then the warehouse system, then the carrier portal, then back again, to assemble a picture that the systems could have assembled themselves. Every order is a promise, and the minutes being counted are mostly the minutes spent finding out whether it was kept. The process that surrounds this metric is the complaint resolution process, which also owns the complaint prevention rate.

You can see the swivel-chair share in a browser. When we were raising, we made a demonstrator video about a retailer with eight brands in four geographies. That is 32 storefronts, so 32 browser tabs, clicked between all day. I told that story on Add To Cart: we pull all that data into one place, so they're not having to gather it manually. The minutes that come off resolution time are looking-up minutes, not typing minutes.

The tail is where retention is lost

Resolution time correlates with repurchase behavior, and the relationship is not linear: the difference between same-day and next-day resolution matters less than the difference between resolved and still-waiting after several days. The tail is therefore where retention is lost, which is another argument for measuring percentiles rather than averages. The measure that connects this page to revenue is repurchase rate segmented by resolution time band, which most businesses can calculate and few do. What a retained customer is worth is customer lifetime value, and what the tail costs is reduce churn. The operating model behind all of it is post-purchase operations.

On a demo call the point I keep making is simple: if you fix the issue and the shopper never has to reach out and ask where their order is, they are likely not to churn. The tail is where that chance runs out. Every order is a promise. Keeyu keeps it.

• FedEx. FedEx sets out its own claim windows. A third-party floor on resolution time, published by the third party.
• United States Postal Service. USPS publishes how it measures service performance. What a stated delivery standard actually is.
• United States Postal Service. USPS Missing Mail search. When a lost-parcel case can be opened at all.
• Harvard Business Review. Harvard Business Review's finding on customer effort. Why first-contact resolution beats speed initiatives.