Third-party logistics providers, freight brokers, regional distributors, private fleets. Assumes a TMS or WMS, a separate accounting system, and a lot of email.
On-time delivery risk alert
In one line: Flags the load that is going to be late while there is still time to call the customer, and gives you an on-time number you can defend in a QBR.
Who uses it and when: whoever owns the account, while the load is still moving, on a flag that it is running late instead of finding out from the customer. It changes one decision: whether that call happens now or after the delivery window passes.
What it does not do: it will not move the truck faster. It flags the risk early enough for someone to make the call.
Usually needs work.
It depends on shipment status events, which are already captured, one per stop. The promised delivery date is the problem: it gets overwritten every time the appointment moves, so on-time gets measured against a target that shifted to meet the truck. Arrival is also timestamped when paperwork is keyed, not when the truck actually showed up. Nothing new has to be built. The promised date keeps its history instead of being overwritten, and arrival gets timestamped at the door.
The pain: “Our on-time number and the customer’s on-time number are never the same and we always lose that argument.”
What it runs on
- One row per: one status event on one stop. One shipment, one stop, one status, one timestamp. Paired with one row per shipment carrying its milestone dates as it advances.
- Described by: customer, carrier, driver, origin site, destination site, lane, equipment type, service level, appointment time, arrival time, departure time.
- Must agree across systems: customer, site, and carrier. Origin and destination have to be identified sites, not address strings, or “same location” cannot be established and lane performance is unmeasurable.
- History: you need history on the promised time. Every appointment change with the date it changed.
Why it usually fails: the promised delivery date field gets overwritten each time the appointment is moved, so on-time is measured against a target that moved to meet the truck. That is why your number and the customer’s never match, and why the customer’s is the one that counts. Second cause: arrival is timestamped when paperwork is keyed, not when the truck arrived.
Load pricing and margin guidance
In one line: Tells the rep what a load on this lane should cost and should sell for, in dollars, before they commit.
Who uses it and when: the rep, before they quote the load, on a buy and sell number for that lane instead of a guess based on mood. It changes one decision: what number goes back to the customer.
What it does not do: it will not commit to the load. It gives the rep a number to start the negotiation from.
Usually needs work.
It depends on buy rate and sell rate, which are already captured per load. Accessorials, detention and layover all land in one “other charges” bucket, so the true margin is off by a varying amount. The reporting layer was also built on margin percent rather than the two dollar figures, so the numbers underneath it cannot be rebuilt. Nothing new has to be built. Other charges get their own codes, and reporting moves back to storing dollars in and dollars out.
The pain: “Margin on a load depends on which rep took it and how they were feeling that day.”
What it runs on
- One row per: one load, with buy rate and sell rate as separate amounts. Store the dollars in and the dollars out. Never store margin percent as the number of record, because percentages cannot be added up and every roll-up built on them is wrong.
- Described by: customer, carrier, lane (origin and destination pair), equipment type, service level, rep, pickup date, mileage, weight.
- Must agree across systems: customer, carrier, and geography. Lane definitions have to be consistent, whether that is city pair, three-digit zip, or market.
- History: mostly today’s picture, with two exceptions that need effective dates: contracted rate agreements and fuel surcharge schedules.
Why it usually fails: accessorials, detention, and layover land in a single “other charges” bucket, so the true margin per load is off by an amount that varies load to load. And because the reporting layer was built on margin percent, nobody can rebuild the dollars underneath it.
Warehouse labor planning
In one line: Forecasts how many pickers tomorrow needs and shows which zones are quietly slow.
Who uses it and when: the warehouse supervisor, the evening before, on a staffing number for tomorrow and a list of the zones running slow instead of a schedule built off yesterday. It changes one decision: how many pickers to schedule and where to put them.
What it does not do: it will not build the schedule. It gives the supervisor the number and the zones to build it around.
Usually needs building.
It depends on a pick rate that cannot currently be derived: picks are confirmed in a batch when the order closes, so forty lines can share one timestamp. A meaningful share of the hours also has no consistent worker attached, because temp labor is not given a stable identity. Timestamping each pick as it happens, and giving every worker one identity, is the project. The feature is what happens after it.
The pain: “We staff to yesterday and we are either paying overtime or paying people to stand around.”
What it runs on
- One row per: one pick transaction. One worker, one order line, one location, one timestamp. If the timestamp is not per pick, the feature does not exist.
- Described by: worker, shift, order, item, warehouse zone and slot, customer, equipment used, date and time.
- Must agree across systems: item, warehouse location, worker, and customer.
- History: you need history on slotting. Where an item was stored at the time it was picked drives the pick rate, so slotting changes have to be dated. Comparing today’s rate to last quarter’s without that is comparing two different warehouses.
Why it usually fails: picks are confirmed in a batch when the order closes, so forty lines share one timestamp and pick rate cannot be derived at all. Temp labor with no consistent worker identity is the other half: a meaningful share of the hours has no name attached.