Leak 09 · Freight & Cost-to-Serve - Unprofitable emergency deliveries

A driver spends two hours delivering a $90 part because the customer’s line is down. It was the right call once. It is now a habit nobody prices.

Diagnostic note. Symptoms, required records, an initial check, and possible fixes. This shorter note does not include a full worked example.

What is it?

Emergency deliveries are part of the service that justifies buying from a distributor instead of online. The leak is not that they happen. It is that they are unmeasured, unpriced, and concentrated among a few customers who have learned that “urgent” costs them nothing extra.

Family
Freight & Cost-to-Serve
Primary owner
Operations Manager
Secondary owners
Sales Managers, CFO
Primary impact
EBITDA
Typical data source
Delivery logs, driver time, order values
Detection difficulty
30-day measurability

Ask yourself

Do you know how many same-day or hot-shot deliveries you ran last month, and what each one cost?

Yes, partially, no, or don’t know. “Don’t know” is the most useful answer, because it points at the test below.

What does it look like?

Warning signs. None of these proves the leak exists. They tell you where to look.

  • Same-day and hot-shot runs that are not coded differently from routine deliveries.
  • No emergency delivery fee, or one that is routinely waived.
  • A handful of customers who account for most of the urgent runs.
  • Drivers pulled off scheduled routes, delaying other customers.

What data do I need?

The minimum viable set. Most of it is already in your ERP.

Field
Delivery record: order, customer, date, delivery type
Driver time and miles for the run
Order value and gross profit
Fee charged for the delivery

The initial check

Start with a small sample. Gathering the exports, agreements, or observations is separate from running the check; agree that work with the person who owns the records.

  1. 1Ask dispatch or the drivers to list last month’s unscheduled runs from memory or the log.
  2. 2For each, note the order value, the gross profit, and the hours and miles involved.
  3. 3Estimate the run cost at your loaded driver rate plus mileage, and compare to the fee charged.
Loss per run = (driver hours × loaded rate + miles × per-mile cost) − delivery fee charged

Then ask one question: Which three customers generated the most emergency runs, and are they your most profitable accounts or your least?

How much could it be costing us?

A conservative range, not a headline. The goal is a number management can trust enough to investigate.

Emergency runs per year × average unrecovered cost per run × share you can reasonably charge for or consolidate

Common root causes

Fixes fall into three layers. Not every problem needs software, and almost none needs AI first.

Process
No definition of what qualifies as an emergency and no fee policy.
Data
Delivery type is not recorded, so emergency runs cannot be counted.
Technology
Dispatch is a whiteboard or a group chat, not a system.

What should we do?

Start with the simplest intervention that could solve it. Move down the list only if the one above is not enough.

  1. Level 1

    Visibility

    Code every delivery by type and report emergency runs monthly by customer.

  2. Level 2

    Policy

    A published emergency delivery fee, with a short list of accounts where it is waived by decision.

  3. Level 3

    Workflow

    A dispatch tool that records the run, applies the fee automatically, and shows the customer’s recent history.

Where AI helps

  • Identifying customers whose emergency pattern suggests a stocking or consignment conversation instead of a fee.

Where AI probably doesn’t

Counting runs and charging a fee needs a log and a policy, not a model.

Before you call it a leak

  • For key accounts, emergency service may be the reason they buy from you. Price it into the relationship deliberately rather than removing it.

Think this might be happening in your business?

Turn the finding into a next step.

If the numbers say there is something there, send us what you found and we will help you decide whether it is worth a full investigation. No transaction files needed for that conversation.

Let’s start with one thing.

What would better performance look like?

Bring a result you want to improve, a symptom, or a workflow you already understand. You do not need to know the bottleneck yet. We’ll help choose what to investigate first.

No transaction files needed for the first conversation.