What Operating Data to Require From a Sorter Supplier: Reporting in the Contract

Every sortation project produces data, and almost every contract is silent about who gets it. The machine counts parcels, logs faults, records stoppages and tracks availability – and unless the reporting requirement is specified, the buyer receives whatever the supplier’s standard report happens to contain, which is usually designed to demonstrate that the supplier performed well.

The time to define this is before the machine is built. Asking for reporting as a favour after handover is slow, occasionally chargeable, and produces whatever is easiest to export rather than what is needed.

The Metrics Worth Specifying

Most buyers need six metrics, and each needs a definition rather than a name. An undefined metric is not a requirement, because the supplier will compute it in whatever way is most favourable.

• Inducted parcels per hour: counted where, over what window, and including or excluding recirculated items.
• First-pass sort rate: parcels reaching the correct destination on the first attempt, stated separately from induction rate.
• No-read and no-sort rate: with the handling rule stated, since this is where most disagreement occurs.
• Availability: uptime as a fraction of scheduled operating time, with the definition of scheduled time and of a stoppage.
• Stoppage causes: categorised, with duration, so that the largest contributors are visible rather than aggregated.
• Jam and fault counts: per module where possible, because they point at the component rather than the system.

These are the same figures that appear in throughput verification and in the acceptance testing method. Requiring them in the operating report keeps the acceptance baseline and the operational picture on the same definitions, which is what makes later comparisons meaningful.

How the Data Must Be Delivered

A report that exists only on a supplier’s portal is not operational data. Specify the delivery mechanism as concretely as the metrics.

• Export format: a documented format – CSV or a defined API – with stated field names and units.
• Frequency: per shift, per day, or continuous, with retention period stated.
• Access: who can retrieve it, whether retrieval requires supplier involvement, and whether it works during an outage.
• Ownership: stated explicitly. Operating data generated by the buyer’s production belongs to the buyer, and this is worth writing down even where it seems obvious.
• Granularity: whether raw event logs are available or only aggregates. Aggregates cannot answer questions that were not anticipated.

The last point is the one that matters most over a five-year life. Aggregated reports answer the questions that were thought of at design time. Raw or granular data answers the questions that appear in year three.

Using Reporting in the Commercial Terms

Reporting is not only an operational asset; it is evidence. Three clauses make it useful:

• Availability reporting as the SLA basis: if a service commitment is measured, the measurement should come from the machine’s own data rather than from a ticket log. This is what makes the response commitments in the warranty and service SLA testable.
• Baseline retention: the acceptance-run data must be retained and handed over, so that performance drift can be measured against a known starting point.
• Reporting as a handover condition: tie delivery of the reporting capability to a payment step, in the way described in the payment milestones article. A requirement with no consequence attached tends to arrive late.

What the Reports Are Actually For

The purpose is not reporting for its own sake. Operating data answers three questions that otherwise get answered by opinion: whether the sorter is meeting the rate it was bought for, where the lost time goes, and whether performance is drifting.

The second question is usually the most valuable early on. Stoppage cause data almost always shows that a small number of causes account for most lost time, and those causes are frequently mundane – a specific induction issue, a chute that fills faster than it is cleared, a recurring no-read pattern from one label type. None of that is visible without categorised stoppage data, and all of it is actionable.

Overall equipment effectiveness is the standard framing for combining availability, performance and quality into one figure, and it is worth specifying how each component is computed. Key performance indicators only work when the underlying definitions are fixed, which is precisely the point of writing them into the contract rather than into a dashboard later. Where the data will be stored on site, data logging retention and access should be part of the same specification, because a report nobody can retrieve is not a report.

A practical note on scope creep in reporting: start with the six metrics and add later. Buyers who specify twenty indicators at the outset usually find that half are never looked at, and that the effort spent defining them delayed more useful work. A better pattern is to specify the core set with precise definitions, agree a mechanism for adding metrics later, and review the list after the first quarter of operation, once the team knows which numbers it actually uses.

Frequently Asked Questions