Deep Interpretation of ISO9001 Clause (18) | 8.2 Requirements for Products and Services: Practical Contract Review and Customer Communication

1. Key Points of the Clause

8.2.1 "Customer Communication" requires organizations to communicate with customers on five types of matters: a) Providing information about products and services; b) Handling inquiries, contracts, or orders, including changes; c) Obtaining customer feedback on products and services, including customer complaints; d) Managing or controlling customer property; e) Establishing specific requirements for emergency measures when significant.

8.2.2 Requires organizations to consider four sources when determining the requirements to be provided to customers: applicable legal and regulatory requirements, requirements deemed necessary by the organization, customer-stated requirements (including requirements for delivery and post-delivery activities), and requirements that are necessary for the intended or known intended use of the product or service, even if not stated by the customer.

8.2.3 Clearly states that the review should be conducted before making a commitment to provide products and services. The review should cover the four sources mentioned above and any discrepancies between the contract or order requirements and previous statements, ensuring that the requirements are defined, inconsistencies are resolved, and the organization has the capability to meet the specified requirements. The results of the review and any new requirements should be documented. The clause also adds that when the customer does not provide documented requirements, they should be confirmed before acceptance; when requirements change, the documented information should be updated and relevant personnel should be informed.

2. Interpretation of Intent

8.2 serves as the entry gate for the operation chapter, translating the customer's voice into clear, executable, verifiable, and deliverable requirements within the organization. Subsequent procurement, production, inspection, release, and delivery activities are all based on the requirements list output from 8.2; if this step fails, all subsequent efforts, no matter how standardized, will be directed towards the wrong goal.

The first layer of logic is that the scope of requirements is much broader than what the customer explicitly states. The clause lists four sources because the most contentious issues in practice often arise from "requirements not stated by the customer but must be met": electrical and certification requirements for equipment exports, specific storage and transportation conditions for packaging, and regulatory filing requirements for medical devices. Just because the customer does not mention them does not mean the organization can ignore them.

The second layer of logic is that the critical timing for the review is before the commitment. The standard does not specify the form of the review but is very strict about the timing: once a quote, contract, or verbal commitment is given, the negotiation space and delivery obligations are simultaneously locked. The core criterion for the review is whether the organization has the capability to meet the specified requirements, including production capacity, delivery schedule, technical implementation and testing capabilities, material availability, and regulatory compliance.

The third layer of logic is that inconsistencies must be resolved and changes must be synchronized. When there are discrepancies between the requirements and previous statements (e.g., order specifications do not match confirmed drawings, adjustments in quantity or delivery schedule, customer verbal changes), the clause requires that these inconsistencies be "resolved" and that any changes be documented and communicated to relevant personnel. This is both the starting point of change management (see 6.3, 8.5.6) and a common source of delivery disputes.

The fourth layer of logic is that communication is a two-way closed loop, not a one-way broadcast. 8.2.1 lists customer feedback and complaints, customer property, and emergency measures, indicating that communication must not only convey information but also receive and form a closed loop for handling, while incorporating significant risk management.

3. Practical Implementation

Step 1: Establish a list of requirements from the four sources. For each order or project, list the customer-stated requirements (including delivery, packaging, transportation, installation, commissioning, training, and warranty for post-delivery activities), requirements not stated but necessary for the intended use, applicable legal and regulatory requirements, and requirements that the organization has decided to strengthen. Create an "Order Requirements Confirmation Form" where each requirement can be traced back to a specific basis (drawing number, technical agreement, standard clause, regulatory document name), avoiding vague statements like "as per customer requirements" that cannot be verified.

Step 2: Define review elements, responsibilities, and timelines. Initiated by the contract or sales department, the technical, production, quality, procurement, and finance departments should confirm their respective areas: whether technical requirements can be achieved, whether production capacity and delivery schedules are feasible, whether inspection and testing capabilities are available, whether key materials can be obtained on time, and whether cost and payment terms are acceptable. The review should be completed before the commitment, with records clearly stating the time, participants, and conclusions. For standard products or online sales orders, a product catalog can cover the requirements, and for urgent insert orders, the process can be simplified but must still retain confirmation traces.

Step 3: Implement a mechanism for the five types of communication in 8.2.1. Designate contact persons and response times for inquiries, order acceptance, and order changes. Establish a closed loop for customer feedback and complaints: registration, cause analysis, response, corrective action, and follow-up. Complaint records should be linked to corrective actions (10.2). For customer-provided molds, drawings, and packaging materials, maintain a ledger with clear labeling, protection, and abnormal reporting requirements. For significant customers, develop emergency measures for scenarios such as material shortages, insufficient production capacity, and logistics disruptions.

Step 4: Ensure that requirement changes are truly implemented on-site. Any changes should first update the affected technical documents, work instructions, inspection standards, and material lists, then confirm the changes to the affected positions through change notifications and retain signed receipts. This sequence cannot be reversed, otherwise, there will be two sets of requirements on-site simultaneously.

Step 5: Regularly sample and review. Each month, select three to five actual orders and verify the entire process from "customer requirements—review records—production and inspection documents—release records—delivery feedback" to ensure no requirements are missed, commitments are recorded, inconsistencies are resolved, and changes are synchronized.

4. Auditor's Perspective

Common Finding 1: Missing or superficial reviews. No contract review records can be found, or the review forms have a uniform conclusion of "can meet," with signing dates later than delivery dates, indicating post-facto documentation.

Common Finding 2: Unstated requirements and regulatory requirements not identified. When checking export or special-purpose products, it is found that destination regulations and mandatory certification requirements are not identified, or that these requirements are not re-confirmed after standard updates or certification requirement changes; implicit requirements (such as storage and transportation temperature and humidity, packaging strength) are missing.

Common Finding 3: Customer communication lacks designated contacts and timelines, and feedback does not form a closed loop. Complaints are only verbally addressed by sales, with no registration, cause analysis, corrective actions, or follow-ups; annual satisfaction surveys are used instead of complaint handling.

Common Finding 4: Requirement changes not synchronized to documents and on-site operations. Customer-confirmed specification changes remain in order notes, while drawings, inspection standards, and work instructions are still the old versions. There is no evidence of "ensuring relevant personnel know the changed requirements" as required by 8.2.3.

Common Finding 5: Customer property lacks a ledger, and emergency measures are absent. Customer-provided molds, drawings, and packaging materials are damaged or lost without reporting to the customer; the clause's requirement to "establish emergency measures when significant" is not found in the documents.

Common Misunderstandings: Equating 8.2 with business contract signing and considering it unrelated to the system; treating the review as a formal signing ritual without genuine capability assessment; believing that unstated customer requirements do not constitute requirements; narrowing "the organization has the capability to meet" to "the equipment can produce it," ignoring delivery schedules, testing, and regulatory compliance.

5. Self-Inspection Checklist

• Have you established a list of requirements covering customer-stated, unstated but necessary, legal and regulatory, and organization-defined sources, with each requirement traceable to a specific basis?
• Is the review completed before the commitment, with evidence showing substantive assessments of production capacity, delivery schedules, technical testing, and regulatory compliance?
• Are there any contract or order requirements that differ from previous statements, and have these inconsistencies been resolved and documented?
• Is customer communication clearly assigned to contact persons with response times, and do feedback and complaints form a closed loop with registration, corrective actions, and follow-ups?
• When requirements change, are the relevant documented information updated, and is there evidence of informing the affected positions?

Clarify the requirements first, then the commitment counts.

Knowledge code: 2.1.1

Version: v20260916

Author: QTank QTank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.