Measure Recovery, Not Just Delay Detection

Key Takeaways

Detection-to-recovery time runs from the moment an exception becomes visible to the moment a new shipment plan is confirmed, and it is the number operations actually feels.
Capture six timestamps per exception: detected, first outreach, carrier answer, decision, recovery confirmed and stakeholders informed.
Define "recovered" separately for delays, missed pickups and cancellations before you start counting, or the results won't compare.
Read the gaps between timestamps, not just the total: each gap points to a different bottleneck.
Wilson, by Cartage, records messages, confirmations and changes on the shipment, so recovery timestamps come from the shipment history instead of reconstructed inboxes.

What is detection-to-recovery time, and why track it?

Detection-to-recovery time is the elapsed time between the first moment a freight exception could be seen and the moment a confirmed next plan is in place for that shipment. It matters more than alert speed because the alert is usually the fastest part of the response.

Most teams can already tell when a load is late. Tracking sources, carrier emails and a customer asking for status all surface problems fairly quickly. What they rarely know is how long it takes to go from "we know" to "it's handled." That stretch holds the carrier calls, the waiting, the internal back-and-forth about cost and the rebooking. It is also where a missed pickup turns into a missed delivery appointment.

Measuring it changes the conversation. A team that reports "exceptions detected within the hour" sounds in control. A team that reports "missed pickups take most of a business day to recover, and over half of that is waiting on an approval" knows exactly what to fix. If you already track broader freight coordination KPIs such as manual touches and carrier response time, recovery time sits next to them: those describe the workload on every load, while recovery time isolates the loads that went wrong and shows how long they stayed wrong.

The six timestamps to capture for every exception

Capture these in order. Each one should be a date and time, plus who or what produced it.

Detected. The earliest moment the exception was visible in any source: a tracking update, a carrier message, a passed pickup window, a call from the dock. Use the earliest source, not the moment someone noticed it. The difference between the two is part of what you are measuring.
First outreach. The first message or call to the carrier about this exception. An internal chat saying "looking into it" does not count.
Carrier answer. The first reply that states a fact you can act on: a new arrival time, a confirmed cancellation, a driver assigned. "Checking with dispatch" is not an answer, so the clock keeps running.
Decision. The moment a recovery option is chosen, either inside existing rules or by an approver. Log the approval request and the approval as separate entries if you can.
Recovery confirmed. The moment the party that has to execute the new plan commits to it: the carrier confirms the revised ETA, a replacement carrier accepts the tender, or the original carrier confirms a new pickup window.
Stakeholders informed. When the internal team and, where your process calls for it, the customer received the new plan.

Write down what "recovered" means for each exception type before the first case. A reasonable starting point: a delay is recovered when the carrier confirms a revised ETA; a missed pickup when a truck is committed to a new window; a cancellation when an approved carrier accepts the load. Some exceptions also need a downstream step, such as a moved delivery appointment, before they count as closed. Decide that once and apply it to every case.

Where to find each timestamp in your own records

Most of these times already exist. They are just spread across mailboxes, chats and booking records.

Detected: tracking update times, the timestamp on the carrier's email, or the end of the pickup window from the order or booking. For a missed pickup with no signal at all, use the window end, because that is when the exception became knowable.
First outreach and carrier answer: sent and received times in the shared mailbox, phone logs, and EDI or API message logs. Personal inboxes are the hardest source; ask coordinators to copy a shared address while you measure.
Decision: approval messages in Slack, Microsoft Teams or email, and the time the booking changed in your records.
Recovery confirmed: the replacement rate confirmation, the carrier's written ETA, or the updated pickup appointment.
Stakeholders informed: the send time of the customer update or internal notice.

A few counting rules prevent arguments later. Measure in elapsed clock time, and flag exceptions that started outside business hours so night and weekend cases don't distort the main view. Keep one clock per exception: if a recovered load fails again because the replacement truck is also late, close the first record and open a new one rather than stretching the original. Log exceptions that resolved before anyone acted, such as a truck that showed up late with no intervention, but keep them out of the recovery figures. Note how many people touched each case alongside the times. Two hours with one coordinator and two hours with four people on a thread are not the same cost.

How to read the results

Look at intervals, not just the total. Each gap points to a different fix.

Detected to first outreach is long: nobody clearly owns the exception when it appears. That is an ownership problem, and an exception-response SLA that names the next owner addresses it more directly than faster alerts would.
First outreach to carrier answer is long: follow-up cadence or channel is the issue. Check whether second attempts happened and whether anyone switched from email to phone.
Carrier answer to decision is long: approvals are the bottleneck. Check whether approval limits match what recovery actually costs on your lanes, and whether approvers get enough context to decide quickly.
Decision to recovery confirmed is long: approved capacity on that lane is thin, or replacement tenders go out one carrier at a time with long waits in between.
Recovery confirmed to stakeholders informed is long: the plan exists, but the update step is manual and gets skipped.

Report the median and the slowest cases separately, by exception type. An average across delays and cancellations hides both: delays usually recover quickly because the carrier only needs to confirm a new time, while cancellations require new capacity. A handful of very slow cases often explains most of the pain, so read them one by one and ask which gap held them up and why: the carrier, an approval, missing data, or simply no one picking it up.

When you look for change, compare like with like. Use the same lanes and exception types before and after a process or software change, and collect several weeks of cases so one bad day doesn't decide the result.

A worked example: three exceptions, four gaps

The times below are illustrative, shown as hours:minutes.

Exception	Detected to outreach	Outreach to carrier answer	Answer to decision	Decision to recovery confirmed	Total	Biggest gap
In-transit delay, FTL	0:40	1:15	0:05	0:10	2:10	Waiting on the carrier's reply
Missed pickup, LTL	1:50	0:20	0:15	1:05	3:30	No one owned the alert
Carrier cancellation, FTL	0:15	0:10	2:30	1:20	4:15	Rebooking cost needed approval

Read across each row and the fixes are different. The delay needed a faster second ask to the carrier. The missed pickup sat unowned for almost two hours before anyone called. The cancellation was handled quickly at first, then waited in an approval queue for longer than the rebooking itself took. None of the three would improve meaningfully with faster detection.

Use the same columns for your own log, and add two more: the number of people involved and whether the customer update went out. After a few weeks, sort by the biggest-gap column. The most common entry is usually the first thing worth changing.

How Wilson, by Cartage, records and shortens recovery

Wilson is an AI logistics agent that replaces the TMS for freight execution and connects to the company's ERP or existing order data flow. It tracks each load from the best available source (carrier API, GPS/ELD data where available, or the carrier website by PRO number) and follows up by email or phone when those don't answer, which gives the detected timestamp a consistent starting point.

When Wilson detects a missed pickup, cancellation or delay, it contacts the carrier by email, API, EDI where supported, or phone where configured; notifies the team in Slack or Microsoft Teams; notifies the customer if configured; and initiates rebooking from the approved carrier list. Rebooking proceeds inside the company's rules or waits for approval when it crosses a configured limit, so the answer-to-decision gap reflects your actual approval design. If no approved carrier accepts, Wilson escalates with every attempt recorded. Wilson starts with assisted execution, and its scope can expand step by step as the team gains confidence.

Because messages, confirmations and changes are recorded on the shipment, each interval in the worked example has a source: outreach and follow-ups are logged when sent, carrier answers are attached to the load, and approvals show when they were requested and when they were given. For a broader view of what the agent does across a load, see what an AI logistics agent is.

To see recovery measured on your own freight, bring a recent exception and its timeline to Cartage and walk through how Wilson would record each step.