Welcome to The Ops Digest!
Each week, we break down one real operations problem and one AI build you can actually use. No hype. No grunt work left on your plate.
This week: the customer order that said ASAP, the date the desk typed instead, and a read that splits your on-time number into the part you can defend and the part you made up.
Here’s how it works.
Required Date: ASAP
A customer order comes in Monday, September 14. Three lines. The required date box says ASAP.
The ERP will not save an order without a date. So the desk does what the desk does: today plus the standard lead time, five business days, September 21. Planning sees a 9/21 order in a queue full of 9/21 orders. Nothing is flagged. The order picks on the 21st, ships on the 21st, and the on-time report for September records it as on time.
The buyer wrote ASAP because a line was changing over Wednesday the 16th and they needed the parts on the floor Tuesday. They called Wednesday. They called Thursday. Both calls are in the order notes. The parts arrived the following Tuesday. On their count the order was five days late. On yours it was on time.
Same account, next order. The required date box says 9/28. The order was issued 9/28. Their purchasing system prints the issue date in the required date box, always has, and the desk learned to ignore it years ago. So now every date from that account gets ignored. Including the real ones.
Multiply by a year.
WHAT THE REQUIRED DATE BOX ACTUALLY SAYS
Pull a hundred POs and read the date box. You will find:
A real date. The buyer meant it. Sometimes.
The date they issued the order. Their system filled it in. Means nothing.
ASAP, RUSH, URGENT. A date, translated into a feeling.
Blank. They trust you. Or they forgot.
A phrase. “Week of the 12th.” “With next release.” “By month end.”
A date in the past. They needed it before they ordered it.
The ERP accepts exactly one of these. So the desk converts the other five into a date, and the report cannot tell which orders were converted.
The keyed date is not the customer’s date. It is the desk’s best guess at the customer’s date, entered under time pressure, and the on-time report has been treating it as a promise the customer agreed to.
And the guess is always generous. The default is order date plus standard lead time, and standard lead time is set so that most orders make it. So an order scored against the default is scored against a bar you set for yourself, at a height you already clear. The customer who wrote ASAP set a different bar, in their head, and never told you where it was. The report scores the first bar and calls it the second.
The issue-date accounts are the sharpest version of this. Some buyers’ systems print the issue date in the required date box, and the desk learns which accounts do it and overrides the date on every order from them. Fine, until that buyer types a real date, because the desk cannot tell a real 9/28 from an automatic 9/28. The override rule lives in one person’s head. It’s the Denise problem from August wearing a calendar.
The visible cost is expedite freight on the ASAP orders that turned out to have a real date behind them. The second cost is the two phone calls, which are in the order notes and will never appear in an on-time report. The third is the one that matters. The accounts that stopped writing dates are the accounts that trust you, and they are the ones the default date protects you from ever being late to, on paper.
Free Workshop on Using Claude for Quotes
See what AI can do for your quoting process in this 30 minute workshop. We’ll go over turning simple quote requests around faster, working through complex RFQs with drawings, plans and specs, and building your own Claude skill. We show you how to use Claude Skills to process quotes, and you leave with the prompts and templates.
October 8, 1:00 to 1:30 PM Pacific. Free.
First, the thing you are already thinking, and the answer is no.
Don’t ask your customers to always fill in a date. You don’t control their order form. Their purchasing system fills the box with whatever it fills it with. And a buyer who writes ASAP is telling you something a mandatory field would erase. Read what they wrote. Don’t fix what they wrote.
1. Pull the export
Orders from the last 180 days. Customer, your order number, the customer’s order number, order entry date, requested date as keyed, promised date if your ERP holds one separately, actual ship date, ship-to. Your ERP calls the date field something else. Requested delivery date, need-by, dock date. It’s the one the desk fills in from the customer order.
Then the customer order documents themselves. If your ERP stores the customer order text or attaches the PDF to the order, it comes out with the export. If it doesn’t, the PDFs are in the shared mailbox or the document folder, and you pull the last 180 days of them into the working folder alongside the export. That’s the one manual step in this, and it’s the step that makes the rest work.
One more thing in the folder: your published standard lead time, by product class if it varies. A single line in a text file.
2. The first read, which finds the invented dates
Here is a 180-day sales order export and a folder of
the customer order documents that go with those orders.
Do this.
1. For every order, find the customer order document and
read the required date field, or delivery date,
need-by date, dock date, whatever it is labeled.
Record exactly what it says.
2. Classify what the customer wrote into one of:
- A specific date after the order issue date
- A date equal to the order issue date
- A date before the order issue date
- ASAP, rush, urgent, or similar
- Blank
- A phrase or range ("week of", "by month end")
- Cannot find the customer order document
3. Compare the customer's date to the requested date
as keyed in the export. Classify the keyed date as:
- Matches what the customer wrote
- Equals order entry date plus [standard lead time]
- Equals order entry date
- Something else
4. Build a table: rows are what the customer wrote,
columns are what the desk keyed. Counts in each cell.
5. Post the table. Under it, list every order where the
customer wrote a specific date and the keyed date
is different, with both dates side by side.
6. Do not edit anything in the export. This is a list
for a human to read.The table is the first payoff. Down the left, what the buyer said. Across the top, what the desk typed. The cell where “ASAP” meets “order date plus standard lead time” is the share of your ASAP orders that got scored against your own default. The cell where “a specific date” meets “something else” is the list of orders where the buyer told you a date and the desk keyed a different one. That second list is short. Read it first.
3. The second read, which is the on-time number you should be reporting
Here is where the method question lands, and it’s the one everyone asks. Do we throw out the orders with no customer date, so we stop grading ourselves on things nobody asked for? Or do we assume the customer had an expectation anyway, and count it late when we missed it?
Neither, quite. Don’t throw them out. Segment them. And score each segment against the bar the customer actually had. That gives you three numbers, and the rule is that they never get blended.
Number one, stated-date on-time. Orders where the customer wrote a specific, meaningful date. After the order issue date, not the issue date itself. Shipped on or before it, or not. Report the number with the coverage next to it: “94% on time, on the 41% of orders where the customer gave us a date.” This is the only on-time figure you can defend as a promise kept.
Number two, implied-expectation on-time. Orders where the customer wrote ASAP, left it blank, or wrote the issue date. These customers had an expectation. They didn’t write it down because they assumed you already knew it, and what they assumed is whatever you did last time. So the bar is the account’s own recent history: the median days from order entry to ship on that account’s previous orders, last 90 days or last six orders, whichever is more. Shipped within that, on time. Slower than that, late, and the customer noticed even if they didn’t call. First order from a new account, no history, fall back to published standard lead time and mark it as such.
Number three, the number on the current report. Scored against the keyed date. Put it next to the other two.
Take the export and the classification from the
previous step. Do this.
1. Split orders into two groups:
- Group A: the customer wrote a specific date after
the order issue date
- Group B: ASAP, blank, issue date, phrase, or past
date
2. Group A: on time if actual ship date is on or before
the customer's written date. Report the on-time
percentage and the number of orders in the group.
3. Group B: for each order, compute the account's
median days from order entry to ship across its
previous orders in the export (at least six; if
fewer, use [standard lead time] and mark the order
as "no history"). On time if this order's days to
ship is at or under that median. Report the on-time
percentage, the number of orders, and how many were
scored against standard lead time for lack of
history.
4. All orders: on time if actual ship date is on or
before the requested date as keyed. Report it.
5. Post all three numbers side by side with the order
counts. Do not combine them into one figure.
6. Under that, list every Group B order that was late
by more than two days against the account's own
median, sorted by days late.Two things to be honest about with number two. It measures consistency, not speed. An account you have always shipped in nine days has a nine-day bar, and hitting it counts, because that is the bar they hold you to. Whether nine days is competitive is a different question, and not this week’s. And the list in step six is the list of surprised customers. Those are the calls you either got or should have.
Four things come out of this.
The gap between number three and number one. How much of your reported on-time was scored against dates the customer never wrote. Ask the desk to guess before you run it. Most guess a third. It is usually more than half.
The surprised-customer list. Group B orders that were slower than that account’s own norm. Nobody on the desk has this list, because the report said those orders were on time.
The issue-date accounts, written down. Which customers’ systems print the issue date in the required box. It has been in someone’s head. Now it’s in a file, and the next person can tell an automatic 9/28 from a real one.
The keyed-wrong list. Orders where the buyer wrote a date and the desk keyed a different one. Small list. Read every line.
4. Make it run weekly
Same shape as the last three issues. Schedule the ERP to drop the trailing 30 days into the working folder every Friday, customer order documents with it, and set the read up as a scheduled task in Claude Cowork for Monday morning. Same prompts, smaller file, one added line.
Every Monday morning, do this.
1. Open the newest order export and customer order
documents in the working folder. They cover the last
30 days. If nothing is newer than your last run, say
so in one line and stop.
2. Classify every new order by what the customer wrote
and what the desk keyed, as before.
3. Post the three on-time numbers for the month with
order counts. Never combine them.
4. Under it, the surprised-customer list: Group B orders
more than two days slower than the account's median.
5. Compare to last month and say in two or three
sentences what moved. If nothing did, say so.The difference between this and the on-time report you already get: that report scores every order against one date. This one asks whose date it was.
An Honest Take
Here is what I actually think. ASAP is not a missing date. It is the customer telling you the date is your problem now. And the desk answers by typing a number the customer will never see, and the report treats that number as a promise both sides agreed to.
I consider an Amazon order late on day three. Nobody at Amazon promised me two days. I formed that expectation from the last fifty times they shipped in two, and if the next one takes four, I notice. I don’t file a complaint. I just remember. Your ASAP customers are doing exactly that. They have a number in their head, it came from what you did last time, and the only way to know whether you missed it is to compare this order to your own history on that account. Not to a default you typed.
So don’t throw the no-date orders out of the on-time number. That drops the accounts that trust you most, and it leaves you reporting on the 40% of customers who write dates while the other 60% grade you quietly. And don’t blend them in against a default either, because the default is a bar you set at a height you clear. Score them against yourself. It is the only bar they actually hold.
One more thing. The 96% on the slide was never a lie. It was an honest count against the wrong column. But your customer’s scorecard has been counting against the other column the whole time, and their number is the one that decides whether the next order comes to you.
And yes, reading the date the buyer actually wrote, before anyone types over it, is what we sell, so weigh it accordingly. The read is worth doing whether you buy anything or not. You cannot fix a promise you never actually made.
The Bottom Line
The required date field in your ERP holds two kinds of dates and does not mark which is which. Dates the customer wrote, and dates the desk typed because the field would not accept ASAP.
Your on-time report scores both the same way.
Pull the export. Run the two reads. Put the three numbers next to each other. The first one is the on-time number you can defend. The second is the one your customers have been computing without telling you. The third is the one on your slide.
The most popular Ops Digest articles, in one report.
We have been doing this for a while now. The eleven issues readers opened most are collected in one report, Revenue Leaks: the quote nobody decided not to send, nine years of account rules none of them written down, the customer that is leaving without telling you, the 17 weeks left on the agreement. CTA’s stripped, so you can hand it to your team without the pitch attached.
