Many companies run a reporting system that nobody reads. Twenty figures across three pages, sent out once a month, laboriously assembled from several systems and a spreadsheet — and the decisions are still made on gut feeling. The problem is rarely a lack of will; it is the sheer volume. Anyone watching a dozen metrics ends up watching none. This article describes five figures that genuinely steer a mid-sized company: order lead time, on-time delivery, rework rate, utilisation and open receivables. For each one the same four questions apply: where does the data come from, how often does it need refreshing, who reads it, and which decision depends on it? The focus throughout is on reporting from data you already have rather than on new data capture. And on one limit no metrics system can cross: figures show that something deviates, not why.
Key takeaways
- Five metrics are enough to steer most mid-sized companies: order lead time, on-time delivery, rework rate, utilisation and open receivables. Every additional figure competes for the same attention and lowers the chance that any of them gets read at all.
- A metric only carries weight with a written definition: start point, end point, data source, refresh cycle and a named owner. If one is missing, two reports with different values appear and the meeting turns into a debate about method rather than substance.
- On-time delivery is measured against the date you promised, not against the customer's original wish; the rework rate needs the reason recorded alongside it, otherwise it shows a volume and points to no cause.
- The refresh cycle follows how quickly the company can actually react: open receivables deserve a daily look, lead time and on-time delivery a weekly one, rework and utilisation usually a monthly one. Refreshing more often does not mean steering better.
- Metrics do not explain why something happens. They narrow down where to look more closely; the cause is found in conversation with the people doing the work and in a process assessment, not in yet another report.
Why three figures beat a dozen
A metrics sheet competes for a scarce resource: the attention of management in a meeting that rarely runs longer than half an hour. Twelve values on one page therefore do not deliver twelve times the steering effect; in practice they deliver none. Nobody holds twelve figures in mind at once, compares them with the previous period and derives a decision from them. What happens instead is a glance at whichever value is currently coloured red — and that is seldom the most important one.
A small set of metrics also forces a decision many companies avoid: which question matters enough to be answered regularly? Making that selection makes your priorities visible. A company struggling with delivery dates puts on-time delivery and lead time first. A company with tight liquidity leads with open receivables and their ageing structure. Emphasising both at once is possible, but then something else has to come off the sheet — and that trade-off is the real benefit of the restriction.
How to spot an overloaded metrics sheet
A rule of thumb that has proved itself: three to five metrics (project experience) on one sheet, each with the comparison value from the previous period, each with a named person who can explain it if questioned. Anything beyond that which is still interesting belongs in a detailed report pulled on request — not on the sheet that lands on the table every week. Separating the steering sheet from detailed reporting noticeably shortens the meeting without losing information.
Order lead time: the figure the customer experiences
Order lead time measures the span between an order arriving and its completion from the customer's point of view: goods shipped, work accepted, invoice issued. It includes every waiting period, query, approval loop and handover. That makes it the only time-based figure the customer actually perceives, and the only one that says something about the performance of the whole workflow rather than the speed of individual departments.
For reporting, the median is preferable to the mean. A single order that waited eight weeks for a special part shifts the mean considerably and makes an otherwise stable workflow look poor. The median describes the typical case, while the range shown alongside describes reliability. Putting both next to each other immediately distinguishes a company that is uniformly slow from one that generally works quickly but lets individual cases sit.
- Start point: which event counts as arrival — the phone call, the written order, the order confirmation or the customer's release? The choice is free, but it has to be written down and applied consistently.
- End point: dispatch, acceptance or invoicing. Here too, what matters is not the theoretically correct definition but the consistently applied one.
- Scope: do nights, weekends and shutdown periods count? Anyone excluding them needs a rule that is applied identically in every report.
- Separating order types: standard orders, custom work and complaints have different lead times and should be reported separately, otherwise the message averages itself away.
- Data source: the field the timestamp comes from, together with a note on whether it is set automatically or maintained by hand.
The most common difficulty lies not in the calculation but in fields maintained manually. A completion date that an administrator enters at the end of the month is no basis for a time-based metric. In that situation it is more honest to derive completion from an event that arises automatically — the dispatch note, the invoice number, a status change — than to publish a figure that depends on how diligently a field is caught up.
On-time delivery: promise versus reality
On-time delivery is the share of orders completed by the date promised. It is the metric with the greatest external effect, because it measures the company's promise against reality. It is also the one most often defined poorly, usually because it stays unclear which date counts: the customer's original wish, the date confirmed in the order acknowledgement, or the most recently rescheduled one.
Both variants are legitimate, but they answer different questions. Measured against the promised date, the metric shows whether the company keeps its word. Measured against the original customer wish, it shows whether the customer got what they asked for. Companies that only track the first variant sometimes improve their figures by promising more generously. That is why the number of rescheduled dates belongs next to it as a second value.
| Aspect | Against promised date | Against customer wish |
|---|---|---|
| Question answered | Do we keep our promises? | Does the customer get their date? |
| Data source | Order confirmation, status change | Customer enquiry or order |
| Improved by | More reliable planning | Shorter lead time, more capacity |
| Vulnerable to | Generous promises | Unrealistic customer wishes |
| Necessary companion figure | Number of reschedules | Share of declined requested dates |
| Audience | Planning and production | Sales and management |
For a first rollout, measuring against the promised date is the practical choice, complemented by the number of reschedules per order. That combination can usually be derived from existing data without extra effort and cannot be flattered by easier promises. A tolerance rule matters too: does an order count as on time if it is completed on the promised day, or on the following day as well? Here again, applying the same rule consistently counts for more than the choice itself.
Rework rate: what gets done twice
The rework rate describes the share of cases that had to be worked on again after they were nominally finished: the corrected invoice, the second site visit, the reworked component, the re-picked shipment. It is the metric most directly linked to cost, because rework comes entirely out of the margin — the work has already been paid for once.
For the rate to steer anything, the reason has to be recorded alongside the volume, using a short closed list of five to eight categories. Free-text fields lead to a hundred different phrasings for the same three causes by the end of the year. A picklist with entries such as missing information, incorrect information, material fault, schedule delay, customer change and other produces a usable picture within a few weeks.
SELECT
DATE_FORMAT(o.completed_at, '%Y-%m') AS month,
COUNT(*) AS orders,
SUM(o.completed_at <= o.promised_at) AS on_time,
ROUND(100 * SUM(o.completed_at <= o.promised_at) / COUNT(*), 1) AS on_time_percent,
SUM(o.rework_reason IS NOT NULL) AS with_rework,
ROUND(100 * SUM(o.rework_reason IS NOT NULL) / COUNT(*), 1) AS rework_percent
FROM orders o
WHERE o.completed_at >= '2026-01-01'
AND o.promised_at IS NOT NULL
GROUP BY month
ORDER BY month;A query of this kind can be built in most order and inventory management systems from fields that already exist. The effort lies not in the query but in the prior agreement about which field means which state. Skip that step and you get a figure that is picked apart in the first meeting and ignored from then on.
Utilisation: the most misread figure
Utilisation sets planned or worked hours against available capacity. It answers whether there is enough work and whether the available people and machines can handle it. In practice it is regularly treated as an end in itself: the higher the better, so the common assumption goes. That assumption is why many companies report high utilisation alongside long lead times and weak on-time delivery.
The relationship is well documented and visible in any company: as utilisation approaches the capacity limit, queues grow disproportionately. A workflow without any reserve has no way left to absorb variation — every sick note, every rush order and every breakdown pushes the entire queue back. Deliberately keeping reserve is therefore not waste but the precondition for being able to keep promises.
Utilisation is a constraint, not a goal
Utilisation therefore works best as a companion figure rather than a headline metric, and as a trend across several months rather than a daily value. It becomes particularly informative when compared across areas: if one workstation runs permanently at the limit while the downstream area idles, you have found a bottleneck — and with it the point where an investment or a reallocation actually has an effect.
Open receivables: keeping liquidity visible
Open receivables are invoices issued but not yet paid. As a single total the value says little, because it depends on turnover and carries no time dimension. It becomes meaningful through its ageing structure: how much money has been outstanding for how many days? This breakdown is the metric that leads fastest to concrete action, because every line has a nameable counterpart.
For mid-sized companies the ageing structure is also the metric with the lowest collection effort. Every accounting system can produce it, the data is current to the day and the definition is not disputed. Where liquidity is tight it temporarily outweighs any other report — with the caveat that it describes a consequence rather than a cause. Late payments often originate further upstream: in incomplete invoice details, missing proof of work, or invoices issued weeks after the work was done.
- Not yet due: invoice issued, payment term still running. This sum is tied-up capital, but no reason to act.
- 1 to 30 days overdue: in most cases oversight or an internal approval run at the customer. A factual reminder is usually enough.
- 31 to 60 days overdue: a phone call is worth more than a second written reminder here, because a substantive disagreement is often behind it.
- 61 to 90 days overdue: the case belongs on the management desk, together with the question of whether further orders from this customer are accepted.
- Over 90 days overdue: a decision on how to proceed is due. Assessing the individual case in legal terms remains a matter for a lawyer.
- Disputed items: report them separately, otherwise they distort the structure and block work on the remaining lines.
Anyone introducing the ageing structure should decide at the same time who reacts at which stage. A report without assigned responsibility ends up unread in the archive within two weeks. A short rule works well in practice: up to 30 days accounting acts on its own, from 60 days the responsible salesperson is informed, from 90 days management decides.
Where the data comes from
The good news: for all five metrics the data already exists in most companies. Lead time and on-time delivery sit in the timestamps of the order system, the rework rate in the complaints or returns list, utilisation in staff and machine planning, open receivables in the accounting system. What is missing is rarely the capture but the consolidation — and specifically a consolidation that works without weekly manual effort.
This is exactly where many attempts fail. A report that somebody copies together by hand at the start of each week does not survive the first holiday and is the first thing dropped under time pressure. A solution only carries weight once consolidation runs automatically, the result is stored in a fixed place and every value carries its own timestamp. The technical work is manageable: queries against existing databases, scheduled exports and clean consolidation of the sources via a shared key such as the order or document number.
The second run illustrates a requirement that metrics projects regularly forget: a value that could not be refreshed has to be flagged as stale. A figure without an as-of stamp is assumed to be current, and a decision based on a three-day-old cash position is worse than no figure at all. Every value on the sheet therefore carries the date and time of its last successful refresh.
How often to refresh — and who reads it
The refresh cycle follows from how quickly the company can respond to a deviation at all. A metric refreshed daily whose causes are only discussed in the monthly meeting creates unrest without effect. Conversely, a liquidity overview maintained monthly arrives systematically too late in a tight situation. As a guide: open receivables daily, order lead time and on-time delivery weekly, rework rate and utilisation monthly.
Equally important is the question of the reader. A metric without a named audience does not get read, and a metric without a named owner does not get explained. Both belong in the written definition. What works well is one sheet for management carrying all five values, plus a detailed view for each area where the causes sit — planning sees lead time and utilisation in detail, accounting sees the ageing structure, production sees the rework reasons.
Management
One sheet with five values, each with the previous period and the direction of travel. The aim is deciding priorities, not hunting causes. A weekly look is enough, complemented by the daily position on open receivables.
Operations and planning
Lead time by order type and utilisation by area, plus the list of oldest open cases. This view supports sequencing decisions during the current week and therefore needs a weekly cycle.
Department and production
Rework reasons by frequency, broken down by order type. This report belongs in the departmental meeting rather than on the management sheet, because it triggers no decision there.
Accounting
Ageing structure of open receivables with a stored escalation rule and disputed items shown separately. Refreshed daily, because the ability to react exists immediately and every line has a counterpart.
Part of the cycle is a fixed slot in which the figures are discussed. A sheet that is distributed but never read together loses its effect within a few weeks. Fifteen minutes inside an existing meeting are enough if the structure stays the same: what changed, what is the suspected cause, what will be checked by the next meeting and by whom.
Limits: metrics do not explain why
The most useful property of a metric is at the same time its greatest limitation: it condenses many individual cases into one number. That is precisely what makes it suitable for an overview — and precisely why it no longer contains the explanation. A drop in on-time delivery may stem from staff absence, from a new customer with unusual requirements, from a supply shortage or simply from a changed data entry habit in the system. The figure does not distinguish between these cases.
The practical response is simple but rarely applied with discipline: the metric triggers a question, not a measure. A notable deviation is followed by a look at the individual cases — ten to fifteen from the period concerned, discussed with the people who handled them. Where a pattern emerges, a structured assessment of the workflow helps to find the point at which time or quality is lost.
A metric ends the debate about whether a problem exists. The work on why it exists only starts afterwards.
Two further limits deserve mention. First, every published metric changes behaviour: report handling time per person and attention shifts to quick cases while difficult ones are left sitting. Second, person-related reporting touches data protection and, where a works council exists, its codetermination rights for systems capable of recording behaviour or performance. Metrics should therefore relate to a workflow, an area or an order type; assessing a specific case belongs in professional review.
Four weeks to your first metrics sheet
Building a workable metrics sheet is not a project spanning months. By far the largest share of the effort goes into agreeing definitions, not into technology. The following sequence has proved itself in mid-sized companies and needs no additional software purchase, as long as the operational systems allow an export or read access.
Week 1: define the questions
Do not start with metrics but with the three to five questions management wants answered regularly. Only then assign a figure to each question. Questions with no available data basis are noted and set aside.
Week 1: write the definitions
Half a page per metric: start point, end point, unit, filters, exclusions, data source with field names, refresh cycle and responsible person. This page is signed off by everyone involved before anyone starts building a report.
Week 2: check the data sources
For every field needed, clarify whether it is set automatically or maintained by hand, and how completely it has been filled in recent months. Fields with gaps are marked as such instead of quietly bridging the gap.
Weeks 2 to 3: first manual report
Calculate the metrics once by hand for a past period and check them for plausibility with experienced colleagues. Differences between figure and experience are not a problem but the most valuable part of this step.
Weeks 3 to 4: set up automation
Only once the figures are undisputed is the process automated: scheduled queries, a fixed storage location for the result, an as-of stamp per value and a notification when a run fails. Without that notification a stalled value goes unnoticed for weeks.
From week 5: establish the meeting
Fixed slot, same structure, documented measures with owner and deadline. After roughly six months, check which metric has produced no measure in that time — and replace or drop it.
Do not start with metrics but with the three to five questions management wants answered regularly. Only then assign a figure to each question. Questions with no available data basis are noted and set aside.
Half a page per metric: start point, end point, unit, filters, exclusions, data source with field names, refresh cycle and responsible person. This page is signed off by everyone involved before anyone starts building a report.
For every field needed, clarify whether it is set automatically or maintained by hand, and how completely it has been filled in recent months. Fields with gaps are marked as such instead of quietly bridging the gap.
Calculate the metrics once by hand for a past period and check them for plausibility with experienced colleagues. Differences between figure and experience are not a problem but the most valuable part of this step.
Only once the figures are undisputed is the process automated: scheduled queries, a fixed storage location for the result, an as-of stamp per value and a notification when a run fails. Without that notification a stalled value goes unnoticed for weeks.
Fixed slot, same structure, documented measures with owner and deadline. After roughly six months, check which metric has produced no measure in that time — and replace or drop it.
Follow this path and after about four weeks you have a sheet that is produced without manual work and whose figures are no longer disputed internally. That is the foundation for everything else: only once it is measurable where time and quality are lost does the decision about automating individual steps become worthwhile — and only then can you demonstrate afterwards whether it worked.
Related Articles
Generating reports automatically instead of by hand
Monthly report still assembled by hand? How to replace it: fixed data sources, agreed metric definitions, a scheduled run and a controlled distribution.
Shortening lead times: find the waiting, not the working
How to measure and shorten lead times: why waiting dominates, how to reconstruct it from existing timestamps and which three levers work in mid-sized companies.
Verification of payee in payment runs: handling mismatches
Since October 2025, banks check name and IBAN before every credit transfer. How supplier master data, payment blocks and call-backs handle the bank's responses.