First response time vs first detection time

Two clocks, defined

First response time starts when a ticket or chat arrives and ends when someone sends a meaningful reply. Green means you answered quickly after the promise already broke. It says nothing about whether the parcel moved, the pick released, the carrier case was lodged, or the refund credited.

First detection time starts when the operational break occurs and ends when your systems see it with enough truth to act. Green means you saw the break before the shopper had to become your unpaid monitoring system. Every order is a promise. Keeyu keeps the promise. The whole discipline of proactive e-commerce operations lives in the gap between these two clocks. Most brands only run one of them, and it is the one that cannot prevent anything.

Who is currently doing your detection

An IT alignment lead at a surf and lifestyle group, now one of my customers, described their operation plainly to me before they signed. Roughly 118,000 tickets in a calendar year, about half WISMO or post-purchase, generally reactive, no proactive alerts for carrier issues, and transfer exceptions discovered through customer contact. Read that last clause again. The customer was first detection. First response time measured how fast they thanked someone for doing the unpaid QA job. Absolute volume does not cure the clock problem. It industrializes it.

What first detection actually measures, mode by mode

The metric is only real if you define it per failure mode. Here is where each clock starts.

Order stuck between storefront and ERP

• Detection starts when: The create fails or ages past threshold.
• Typical detection today: Customer asks on day three.

Stock lie after purchase

• Detection starts when: Inventory mirrors disagree.
• Typical detection today: Warehouse hits the pick face.

Label created, no scan

• Detection starts when: Threshold passes with no carrier event.
• Typical detection today: Customer refreshes tracking.

Awaiting collection aging

• Detection starts when: Carrier status flips.
• Typical detection today: RTS carton lands at the dock.

SLA past the promise sold

• Detection starts when: Order crosses its own dispatch window.
• Typical detection today: Never, unless someone writes in.

Warehouse-to-credit gap

• Detection starts when: Return received, no credit event.
• Typical detection today: Customer asks where the refund is.

The right-hand column is the honest audit. For most brands, three or four of those rows say the customer, and one says never.

The gap is the number that changes minds

You do not have to rebuild reporting to make this argument. Put both clocks on the same page for one quarter and measure the distance between them. A furniture founder I met on a discovery call gives the extreme version: orders sitting across a mesh of 15 to 20 drop-ship suppliers, up to three days of archaeology across ERP, supplier email and carrier portal to answer where is my sofa, and WISMO at 40 to 50% of his ticket volume. His first response time can look excellent. It only starts after three days of unpaid customer labor, and after however long the order had already been stuck before anyone asked. Archaeology time is the opposite of first detection. A tidy reply on day three cannot rewind the anxiety, or bring back the silent exits who never wrote in at all.

On a discovery call my team ran with an omnichannel footwear retailer, helpdesk AI had pulled average tickets from roughly 600 toward 400. Queue charts improved. Their biggest reach-out stayed WISMO, split delivery and tracking, because the warehouse system was not passing tracking numbers back to the storefront, with about 40% of orders shipping from store and 60% from the warehouse. First detection never started at that handoff. It waited for the shopper, every single time, and no amount of triage acceleration changed that. Where you have no exception feed, first detection time is not slow. It is undefined, and the customer fills the gap by default.

How to instrument it

Pick three failure modes where you already have a data signal. Paid-not-in-ERP, label-created-never-scanned and returns-received-not-credited are the usual starting three, because all three are unambiguous. Define the break moment for each: not the ticket, but the exact system event or age threshold that means the promise is now at risk. Log the detection moment: when did anything in your stack surface it as an exception with an owner? If the honest answer is "when the ticket arrived," record that. It is the finding. Publish both numbers side by side for one quarter, per mode, detection time then response time. Watch the gap close as you automate, and hold response time steady while you do. If response time is your only improving number, you are still on the old clock.

Step three is where teams get uncomfortable, and where the value is. Most discover that for several modes there is no detection event at all, which converts an abstract argument about metrics into a specific list of missing feeds.

Keep first response time

I am not arguing for abolition. First response time remains genuine staffing hygiene, and the contacts that reach a human deserve a fast answer. I am arguing about which clock decides investment. Promote tickets prevented and lifetime value protected, alongside first detection, to the scoreboard that sets budget, per the full contact-center to commerce-operations migration. The same clock problem shows up under a kinder name in CSAT grades an unwanted problem. Leave first response time where it belongs, managing the residual, which is also the argument in first response time measures apology speed.

At one of my customers, an anonymized sports nutrition brand, proactive operations delivered a 55% reduction in reactive helpdesk tickets and $455,000 saved, on roughly 10x return with about a three month payback. Detection moved first. Everything else was downstream of it.

Ask your team when they found out about the last five significant order failures. If the answer to any of them is "when the customer told us," your first detection time for that mode is not a number you can improve. It is a job you have outsourced to the person who paid you. Every order is a promise. Keeyu keeps the promise. Keeyu gets customers what they want, on time, as promised.

• 1. Keeyu pre-onboarding call (now a customer), Australia and New Zealand surf and lifestyle multi-brand group, IT alignment lead, internal call transcript, 2026-03-20.
• 2. Keeyu discovery call, Australian furniture and home interiors e-commerce brand founder, internal call transcript, 2026-01-06.
• 3. Keeyu discovery call run by the Keeyu team (prospect, not a customer), Australian omnichannel womens footwear and accessories retailer, internal call transcript, 2026-04-23.

The 55% / $455,000 / ~10x / ~3-month outcome set is one anonymized Keeyu customer's audited result, shared with permission (Keeyu Pain-Points KB and Sales Deck v3, internal, 786 labeled pain rows across 99 customers). See keeyu.com/customers.