A delivery reaches the customer on Tuesday morning. Sales calls it late because the customer originally requested Monday. Dispatch calls it on time because the confirmed appointment was changed to Tuesday. The dashboard also calls it on time, but only because it compares calendar dates and ignores the promised two hour window.
All three teams are looking at the same delivery. They are not using the same definition.
That is the central challenge behind on time delivery rate. The calculation is simple only after the business decides which promise counts, what event proves completion, which deliveries belong in the denominator, and how exceptions should be treated.
Without those rules, the percentage can move because the definition changed rather than performance.
What Is On Time Delivery Rate?
On time delivery rate measures the percentage of eligible delivery commitments completed within the date or time window promised to the customer.
The basic on time delivery formula is:
On time delivery rate = (On time eligible deliveries / Total eligible delivery commitments due) x 100
For example, suppose 240 eligible deliveries were due during a month and 204 met the agreed promise:
(204 / 240) x 100 = 85%
The difficult part is deciding what the formula means.
- Does an order count once, or does every stop or order line count?
- Is performance measured against the requested date or the confirmed date?
- Does “on time” mean before the end of the day or inside a specific window?
- Does a photo, signature, status update, or geofence event establish completion?
- Are cancellations, customer reschedules, failed attempts, and missing timestamps included?
Two companies can report 85% while measuring different events.
Build an OTD Measurement Contract First
Before creating a dashboard, document the rules that make a delivery eligible and determine whether it passed. This measurement contract should answer six questions.
A trustworthy on time delivery rate begins with a written measurement contract that every reporting team follows.
| Measurement decision | Rule to define | Why it changes the result |
|---|---|---|
| Unit of measure | Order, stop, shipment, package, or order line | One late item can affect one line or the entire order |
| Promise source | Customer requested date, original confirmed date, or approved revised date | Replacing the original promise can hide service failures |
| On time boundary | Exact date, delivery window, or allowed tolerance | A delivery can meet the date and still miss the appointment |
| Completion event | Delivered status, scan, signature, photo, or another verified event | Weak events can record completion before the handoff occurs |
| Eligibility rules | Which cancellations, holds, returns, and exceptions are excluded | Broad exclusions can artificially improve the percentage |
| Reporting cutoff | Time zone, reporting period, and treatment of open deliveries | Inconsistent cutoffs move the same delivery between periods |
Oracle’s delivery performance guidance illustrates why configuration matters. It allows promised dates, tolerance, and required received quantity to be defined, and treats past due work without completion as late. Although supplier focused, the measurement principle applies to outbound delivery: the rule must exist before the percentage is trusted.
Requested Date or Promised Date?
A requested date records what the customer wants. A promised date records what the operation has agreed to provide.
Those dates may be identical, but they answer different questions:
- Requested date performance: How often did the operation meet the customer’s original preference?
- Promised date performance: How often did the operation keep the commitment it accepted?
The standard OTD dashboard normally needs a clearly governed promised date. A separate promise gap metric can show how often the confirmed commitment was later than the customer’s request. This prevents one number from hiding two different problems.
Revised promises require care. A customer requested reschedule may become the new measurement date. If operations changes the date because it will miss the promise, overwriting the original can make a late delivery appear on time.
A useful order record preserves the original request, original promise, current promise, change time, change initiator, and reason.
Date Based OTD and Window Based OTD
Date based OTD asks whether delivery occurred on or before the promised day. Window based OTD asks whether it occurred inside a committed time interval.
Consider a delivery promised between 10:00 a.m. and noon:
- Completion at 11:42 a.m. is on time.
- Completion at 1:05 p.m. may meet the calendar date but miss the window.
- Completion at 9:15 a.m. may be early, but it is not automatically successful if the recipient was not ready.
The business should decide whether early arrival counts as on time. For unattended parcel delivery, it may be acceptable. For attended services, arriving before the agreed window can create the same customer problem as arriving late.
Do not mix date based and window based deliveries in one unexplained percentage. Segment by service type or publish both measures.
Choose the Right Denominator
The denominator can materially change the reported on time delivery rate, even when operational performance stays the same.
The denominator is where many OTD reports become misleading.
Two common models are useful, but they should not be mixed.
Completed Delivery Model
On time completed deliveries / All eligible completed deliveries
This model describes completed work, but open commitments can disappear unless they are reported separately.
Commitment Model
On time deliveries / All eligible commitments due in the period
This model includes work that remained incomplete after the promise expired. A delivery that never happened cannot improve the score by vanishing from the denominator.
Publish the selected model beside the KPI. The denominator should not be a hidden setting.
A Worked OTD Calculation
Assume 250 delivery commitments were due in June.
- 10 were cancelled by customers before the documented cutoff and qualify for exclusion.
- 240 remain eligible.
- 204 were completed within the promised date or window.
- 28 were completed late.
- 8 were still incomplete after the promise expired.
Using the commitment model:
On time delivery rate = (204 / 240) x 100 = 85%
The 8 incomplete deliveries stay in the denominator. Now suppose 12 late deliveries had their promised dates overwritten after the operation knew it would miss them. The dashboard could incorrectly count 216 as on time:
(216 / 240) x 100 = 90%
Nothing improved, yet the rate rose by five percentage points. Preserving the original promise prevents this measurement drift.
What Counts as Delivery Completion?
A completion timestamp should represent the event the customer promise refers to.
Depending on the service, that event might be a package placed at an approved location, a recipient signature, a confirmed handoff, or completion of an additional service.
A driver tapping a status early, a vehicle entering the neighborhood, or a route reaching its planned end time may not prove that the delivery commitment was completed.
This is where proof of delivery supports measurement. A photo, signature, timestamp, status, and order history can help establish what happened and when. The proof rule should match the service.
The live order tracking guide explains how current location, status, and ETA can reveal an at risk commitment. The OTD result still needs a defined completion event.
On Time Delivery KPI Data Requirements
An accurate on time delivery rate needs more than a delivered date column; it depends on consistent promise, eligibility, and completion data.
At minimum, preserve the order identifier, service type, requested date, original and current promise, revision history, completion timestamp, completion status, reschedule reason, cancellation details, time zone, and proof reference.
Data quality exceptions should remain visible. Report missing timestamps beside OTD or place uncertain records in a review queue. Do not automatically classify or remove them.
A delivery management software workflow can centralize status, ETA, driver visibility, order history, customer updates, and completion evidence. The official It’s Here page documents these inputs, but the business must still define its measurement rules.
OTD vs OTIF
OTD measures timing. OTIF, or on time in full, adds a completeness requirement.
| Measure | Core question | A delivery can fail when |
|---|---|---|
| OTD | Did the delivery meet the agreed date or window? | It arrived after the commitment |
| OTIF | Did the full order arrive within the agreed time? | It was late, incomplete, or both |
Suppose 100 units are promised for Friday and 80 arrive within the window. A timing only measure could pass if its rule ignores quantity. OTIF should fail because the full quantity did not arrive.
ASCM describes OTIF as including all items and quantities on time according to the customer’s definition, with complete documentation. This shows why OTD vs OTIF is not a choice between two names for the same metric. ASCM’s OTIF definition provides the fuller context.
Use OTD when the immediate question is delivery timing. Add OTIF when quantity or order completeness materially affects whether the promise was kept.
KPIs to Read Beside OTD
OTD becomes more useful when a small set of supporting measures explains why it changed.
| Supporting KPI | What it reveals |
|---|---|
| Promise change rate | How often confirmed commitments are revised |
| Average late minutes or days | The severity of misses, not only their count |
| First attempt success rate | Whether an arrival resulted in a completed handoff |
| Window compliance | Whether date level success hides appointment misses |
| Completion data coverage | How much of the KPI rests on trustworthy timestamps |
| Exception detection time | How early the team recognizes an at risk commitment |
| Customer caused reschedule rate | How much change originates outside the operation |
Each supporting KPI should explain a decision, failure pattern, or data quality issue. Common errors include overwriting the original promise, excluding incomplete deliveries, mixing requested and promised dates, treating every early arrival as successful, combining unlike units, and changing exclusions between periods. When a definition changes, annotate the reporting date instead of presenting the new series as directly comparable with the old one.
Keep Improvement Work Separate From Measurement
Once the baseline is trustworthy, segment misses by service type, region, route, promise window, exception reason, and stage of detection. Keep the definition stable while testing operational changes. A separate improvement plan can then address scheduling, route execution, exception response, customer communication, and recurring causes.
Make the OTD Number Auditable
The value of on time delivery rate does not come from the percentage alone. It comes from giving operations, customer service, and management the same defensible answer about which promise was made and whether it was kept.
Start with a written measurement contract. Define the unit, promise source, boundary, completion event, denominator, exclusions, and cutoff. Preserve revisions and show missing data.
Once those rules are stable, the KPI can support meaningful comparisons. Until then, a higher number may reflect better performance, a looser definition, or fewer difficult orders counted.
FAQ
What is a good on time delivery rate?
There is no universal target for every service model. Establish a consistent baseline and compare similar delivery types and periods. Appointment and date based services should not automatically share one target.
How do you calculate on time delivery?
Calculate the on time delivery rate by dividing eligible on time deliveries by all eligible commitments due, then multiplying the result by 100. Document the unit, exclusions, tolerance, and completion event.
Should cancelled orders be excluded from OTD?
A customer cancellation made before a documented cutoff may be excluded if the policy is applied consistently. Operational cancellations and deliveries that remain incomplete after the promise expires should not disappear automatically.
Is an early delivery considered on time?
It depends on the service promise. Early delivery may be acceptable for unattended work, but it may fail an attended appointment if the customer is unavailable before the agreed window.
What is the difference between OTD and OTIF?
OTD tests whether delivery occurred on time. OTIF also requires the full order, including the required quantity and defined documentation, to arrive within the agreed time.
