ISO 9001 clause 8.2: make customer commitments clear and achievable

What clause 8.2 requires in practice

Clause 8.2 covers the requirements for products and services from the customer's first enquiry to any later change. It has four parts. Clause 8.2.1 deals with customer communication, including product and service information, enquiries, contracts and orders, feedback and complaints, customer property and, when relevant, contingency actions during disruption. Clause 8.2.2 requires the organisation to define the requirements for what it offers, including legal and regulatory ones, and to be able to meet the claims it makes.

Clause 8.2.3 requires a review before the organisation commits to supply. The review covers what the customer stated, what is needed for the intended use when known, what the organisation itself specifies, applicable legislation and any differences from earlier statements. Differences must be resolved, and unstated customer requirements confirmed before acceptance. Documented information of the review and of new or changed requirements must be available. Clause 8.2.4 requires updated information and communication to interested parties when requirements change. The clause does not require a formal review of every order where that is impractical, for instance in online sales, where reviewing the published offering may be enough.

Connect communication with requirement definition

Customer communication includes information about products and services, enquiries and orders, feedback, customer property and relevant contingency matters. Those exchanges can reveal expectations or constraints that need further clarification before the organisation proceeds.

Determining requirements includes relevant statutory and regulatory requirements and those the organisation considers necessary. The business must also be able to meet the claims it makes for its offering. Marketing and sales information therefore need a reliable connection with actual capability.

Review before committing

Clause 8.2.3 requires review of the ability to meet requirements before commitment. Consider customer-defined needs, known intended-use requirements, the organisation's own requirements, applicable law and differences from earlier statements. Resolve differences rather than leaving conflicting versions for delivery staff to interpret.

Where the customer has not supplied a documented statement, requirements need confirmation before acceptance. The standard recognises that some sales models use review of relevant product or service information rather than a separate formal review of every individual order. The arrangement still needs to establish a suitable basis for the commitment.

Why customer commitments matter to the business

Many quality problems start with a promise that was unclear, untested or unrecorded. When the organisation accepts work it cannot deliver, the cost shows up later as rework, disputes, discounts and damaged relationships. A sound approach to requirements aligns sales, delivery and the customer on what will happen, and helps the business say no, or negotiate, before it is committed. It also keeps marketing claims accurate, which protects reputation and reduces legal exposure. When requirements change, clear handling stops teams from working to old instructions. In audits, 8.2 evidence shows whether the commercial side and the delivery side of the business are connected, which is often where weaknesses hide.

How to implement clause 8.2

Link the commercial and delivery sides of the business through a short, clear path from enquiry to acceptance. One way Sterling's teams approach it is to review a recent order that went wrong and ask where the path failed.

1. Describe how customers contact the organisation and which channels carry product and service information, enquiries and feedback.
2. Define the standard offering, with its limits, so that claims and descriptions match what can be delivered.
3. Set a review step before acceptance that covers customer, intended-use, internal and legal requirements, and who joins it.
4. Provide a way to resolve differences between the order and earlier statements, and to confirm unstated requirements.
5. Decide what information to keep from the review, proportionate to the significance of the commitment, so the decision can be explained later.
6. Establish how changes are approved, recorded and communicated to design, purchasing and delivery teams, so nobody works from the earlier requirement.

Illustrative construction example: an ambiguous handover expectation

Illustrative software example: a performance claim

A hypothetical software supplier promotes a feature as supporting a particular customer workflow. During sales review, the team learns that the proposed customer uses a configuration not covered by the existing claim. The account manager cannot assume the general marketing statement settles suitability for that case.

The organisation examines the requirement, obtains relevant technical input and clarifies what it can commit to supply. It may define an additional design or verification activity before acceptance, or limit the offer appropriately. The example shows how accurate claims and capability review protect the delivery relationship; it does not promise that every customer use can be supported.

Keep changes connected with affected people

Changed requirements need relevant documented information updated and communication to relevant interested parties. A change accepted by one person can affect design, purchasing, scheduling and acceptance criteria elsewhere. The information must follow the responsibility.

Do not assume an updated contract automatically reaches operational users. Identify what changed and which decisions need review. A revised customer requirement may also affect a provider arrangement or previously planned test, so the organisation should examine interfaces as well as the main document.

Evidence and frequent failures

Explore each numbered part