Customer requirements and order review

In plain words

Before you accept an order, you must know what you are promising — and whether you can keep it. That is the core of this clause group, in four moves: communicate with customers in a regulated way (8.2.1), determine the requirements completely (8.2.2), review them before committing (8.2.3 — order review) and carry changes through cleanly (8.2.4).

“Completely” means more than the order text: legal requirements too, delivery and post-delivery duties — and what the customer does not write but presupposes for the intended use. Order review itself is a real look, not a stamp: can we do this — technically, on this date, in this quantity? Differences between offer and order are resolved before you confirm, and the result is recorded.

For a small company this is no battle of forms. On a repeat order the review is a practised triad — revision, date, capacity —, on a new part a genuine feasibility check. Only one thing is decisive: no promise without a review, not even on the phone.

Why this requirement exists

The classic chain of failure begins before production: sales promises, production discovers. What would have cost one query at offer stage costs a complaint, an extra shift or the customer after delivery. The clause forces the cheapest moment of error prevention into the flow: before the commitment.

It also protects against the vague order. Sectors like medical technology in particular expect things that appear in no single purchase order — traceability, certificates, standards references; the expectations of the interested parties (4.2) reach all the way into order review. And 8.2.4 is the everyday sister of planning of changes (6.3): something changes on orders all the time — the question is whether the change passes through the same review as the original.

What good looks like

It is settled who may accept and confirm orders — and what is checked before confirming: on a new part the feasibility (tolerances, material, machines, measuring equipment, date — and: can our partners deliver?), on a repeat order revision level and date. Ambiguities are resolved before confirmation, in writing; the order confirmation documents the result. Verbal orders are confirmed before effort is spent.

Changes have one entrance: whether the change request reaches sales by mail or production by phone — it crosses the same desk, is assessed (feasible? consequences for date and price?), confirmed and carried into the shop papers. The people affected learn of it before they would have to work to it.

What changes as you grow: From around 50 people: a fixed order-review flow in the ERP, an authority rule (who may promise special dates, prices, deviating terms) and checklists per product family. From 100–250 people: contract review for frame agreements — including legal —, formal change orders and defined interfaces between sales and engineering. The core stays the same at every size: first review, then promise.

The minimum to pass

• Per order, a provable review result before the commitment — brief on a repeat order, thorough on a new part.
• Requirements captured completely: order content, delivery and post-delivery duties (certificates!), legal requirements, the unstated.
• Differences resolved before confirming — not negotiated afterwards.
• Verbal orders confirmed before production starts.
• Changes documented and communicated — shop papers updated, affected people informed.

What an auditor asks for

• Purchase order and order confirmation of a real order side by side: do they match — and who reviewed, when?
• On a new part, the feasibility note: what was checked, what was the result?
• A case where a difference was resolved — the mail exchange or note for it.
• An order change followed through: new confirmation, changed job card, informed production.
• The cross-check in conversation: does sales know the duties that appear in no purchase order — certificates, traceability, standards references?

Common traps

• The order is answered only by the delivery. Order in, parts out, never confirmed — in every ambiguity the supplier carries the burden of proof. The most common gap in small companies.
• Repeat order on autopilot. “Same as last time” — but the drawing now carries revision C. The revision check is the cheapest insurance in this clause.
• The verbal yes. Promised on the phone, never confirmed — in a dispute it is word against word. Two lines of mail are enough.
• Changes past the flow. The customer calls production directly, something is changed “quickly” — papers and price know nothing. 8.2.4 exists precisely for this call.
• Overlooking the unstated. The customer presupposes batch traceability — “it wasn’t in the order”. For the intended use it was necessary all the same, and knowing that was the supplier’s duty.
• Feasibility thought only technically. Able, yes — but not by June. Date and capacity belong to the review like the tolerance.

Worked example

A medical-technology customer orders 500 pieces of a familiar turned part from Berger Präzisionsteile GmbH — “as usual”. Order review is routine and still finds something: the drawing sent along carries revision C, the last production ran to B, and the tightened positional tolerance needs the 5-axis machine. Lea checks measurability (the existing equipment is sufficient), Marco the machine load, and the hardening-shop slot is requested before the delivery date is promised. The order confirmation records: production to revision C, delivery in four weeks instead of the requested three — accepted by the customer. On the enquiry, the feasibility note remains: three ticks, one line, one date.

Three weeks later, the change: the customer raises the quantity to 800 and wants delivery a week earlier. The same review, a new result — material for 800 is available, the hardening slot is not. Berger confirms 500 on the promised date and 300 ten days later; a new confirmation, a changed job card, Marco and Lea informed. And one requirement appears in no purchase order at all: the seamless batch traceability that medical customers presuppose (4.2). It sits as a fixed point in Berger’s order-review checklist — so it never depends on remembering.

<!-- easo:worked_example profile=service -->

At Klarwerk GmbH the product is a promise — all the more important to write the promise down. No project starts without a service description: scope, explicit boundaries (“not included”), the customer’s duties to cooperate. The classic difference was defused at offer stage: the customer read “support” as around the clock — resolved before the contract, not at the first call at two in the morning. The vaguer the raw material, the more the order review decides.

← All ISO 9001 topics · To the knowledge hub