Ask a light manufacturer for its on-time delivery rate and you get a number with a pause before it. The pause is the controller remembering how the number was made: a spreadsheet, built monthly, from the ship dates in one system and the promise dates in another, with judgment calls where the two did not line up. The number is defensible in the way a reconstruction is defensible. It is not a measurement.
The reason is not the scheduling software. It is that the promise date, the one fact on-time delivery depends on, is a field nobody owns, because it lives on no single record.
Follow one order. Sales quotes it and tells the customer the fifteenth, because that is what the customer asked for and the rep wanted the order. The promise is in the quote, or in an email, or in the rep's memory.
The order reaches production, where the planner looks at the schedule and the components on hand and plans it for the eighteenth. The planned date is in the production system or the planner's spreadsheet. Nobody tells sales, because the planner does not know the fifteenth was promised; the quote did not travel with the order.
The warehouse picks and ships on the twentieth, because a component arrived late, and the ship date is in the carrier's portal and on the packing slip. The customer receives it on the twenty-second.
Was it on time? Against the fifteenth, no. Against the eighteenth, close. Against the standard lead time, yes. Three systems, three dates, and the metric depends on which one you believe. When the controller builds the monthly spreadsheet, the choice is made by hand, order by order, and the number inherits every choice.
This is the same shape as the stock problem we described in the piece on three counts that disagree. The fact exists in several places, each system is internally consistent, and the business runs on the disagreement.
Each of the three dates has an owner. The promise belongs to sales, the plan to production, the ship date to the warehouse. What has no owner is the one date the customer heard, as a field on the record the order lives on, that all three teams read and that the shipped date is compared to.
Without it, three things happen. Sales keeps promising dates production cannot meet, because nothing checks the promise against capacity or stock at the moment it is made. Production keeps planning without knowing what was promised, so the plan is optimised for the shop and not the customer. And the customer hears three dates from three people, which is the experience that makes a customer leave, more than the lateness itself.
It also means on-time delivery cannot improve, because a metric reconstructed monthly from spreadsheets cannot be acted on weekly. Nobody sees the order slipping on the sixteenth; they see the rate in the following month.
The design is small and it changes the operation.
One field: the promised date, on the sales order, set once when the order is confirmed. Not on the quote, not in an email. The sales order is the record every team already reads, so the promise lives where production and the warehouse will see it.
One rule: the promised date is not a free entry. Before sales confirms it, the system checks the components on hand and on order, and the planned capacity in the window, and offers the earliest date it can support. Sales can promise that date or a later one. Promising an earlier one requires an approval, with the reason recorded, so the expedite is a decision someone made rather than an accident someone discovered. This is the manufacturing cousin of the gate in our piece on where the quote stops matching the invoice: the commitment is checked before it is made.
One write-back: when the warehouse ships, the shipped date is written to the sales order automatically, from the shipping transaction, not typed by a person later. Now the order carries the promise and the outcome, and on-time delivery is a report: orders shipped on or before the promised date, over orders shipped, by week, by product, by customer. No spreadsheet, no judgment calls, available on Monday for last week.
The first thing the report shows is the gap between what sales promises and what production can do, in days, by rep. That conversation has usually been had as an argument; now it is a number, and the rule removes the cause.
The second is which products and which components drive the misses. A promise date that the system calculated and still slipped is a supply or capacity problem, and the report says which one, because the order carries the component that arrived late.
The third is the expedite cost. Every early promise that was approved is logged with its reason, so the cost of saying yes to the customer is a line the business can see, instead of a freight invoice that surprises the controller.
The customer hears one date. If it moves, it moves on the record, and the person who tells them reads it from the same place everyone else does.
The objection sales raises is that a checked promise date will be later than the one the customer wants, and the order will go to a competitor who promises the fifteenth without checking. Sometimes it will. But the competitor who promises without checking is the competitor who ships on the twentieth and tells the customer on the nineteenth, and the customer who has lived through that once values the supplier whose date held. The honest date, kept, is a sales argument, and it is one the rep can only make when the company has a record of keeping it. That record is the on-time delivery report, which is why the field and the metric belong to the same project. A promise the company can defend is worth more than a promise it cannot, and the only way to know which kind you are making is to write it down where the outcome will be written next to it.
For a light manufacturer on Zoho, the sales order and the inventory and production records already share a data model, which is what makes the rule possible: the availability check reads the same stock the warehouse counts, and the write-back comes from the same shipment that relieves it. The work is the field, the rule, the approval and the report, plus the discipline that the sales order is the only place a promise lives. For a company on a mix of systems, the same design needs the connection between the sales system and the production system to carry the date both ways, which is the integration work and the reason the three dates have never met.
The metric was never the hard part. The field was. Discovery is no-risk: we read your last quarter's orders across the three systems, show you the three dates side by side, and you pay only if you go ahead.
In a no-risk discovery we follow an order from sale to shipment to invoice across your systems and show where it breaks and what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
