7. Customer Requirements, Design and Service Quality

Introduction and Context

Quality is ultimately judged by the extent to which a product or service fulfils requirements that matter to its users and other relevant stakeholders. An organization may comply with internal procedures, achieve low defect rates, and operate efficiently, yet still fail if it misunderstands customer expectations or designs an offering that is difficult to use. Customer requirements therefore provide the starting point for quality management, while design converts those requirements into operational and technical characteristics. Service quality then determines whether the promise embodied in the design is consistently delivered.

This chapter examines the connected quality-system activities through which customer expectations are identified, interpreted, specified, designed, verified, validated, changed, and supported after delivery. Particular attention is given to the voice of the customer (VOC), quality function deployment (QFD), acceptance criteria, design and development controls, complaints, and service-quality measurement. These activities are central to a process-based quality management system because they connect the external environment with organizational processes and measurable outputs.

The topic is especially important in complex products and services. Customers frequently express needs in subjective terms such as “easy to use,” “reliable,” “responsive,” or “safe.” Engineers, service managers, and quality professionals must translate these statements into measurable requirements without losing their original meaning. The challenge is not merely technical translation; it involves prioritization, negotiation, risk management, ethical judgment, and continuous learning.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the relationship between customer needs, requirements, specifications, acceptance criteria, and quality outcomes.

2. Apply VOC methods to identify explicit, implicit, latent, and stakeholder requirements.

3. Describe and use QFD, including the House of Quality, for structured requirements translation and prioritization.

4. Distinguish design verification from design validation and explain their role in a quality management system.

5. Develop useful acceptance criteria and manage design changes through controlled processes.

6. Evaluate complaints and service-quality performance using appropriate measures and analytical methods.

7. Identify managerial, ethical, regulatory, technological, and organizational risks in customer-focused design and service delivery.

From Customer Voice to Quality Requirements

A customer need is an expected benefit or outcome, whereas a requirement is a stated, documented, and testable condition. A specification provides a more precise technical or operational description of the requirement. Acceptance criteria define the conditions that must be met for an output to be accepted by a customer, regulator, project sponsor, or internal process owner.

For example, a customer may say, “The online payment process should be fast and dependable.” This is a need, not yet a complete specification. A requirements analyst may translate it into requirements such as: the payment page shall load within two seconds under defined conditions; the transaction shall provide confirmation or a clear failure message; duplicate charges shall be prevented; and the system shall protect payment information. Acceptance criteria may then specify a maximum response time, a permitted transaction-error rate, and successful completion of defined security tests.

Requirements may be classified in several ways:

• Explicit requirements are directly stated by customers, contracts, regulations, or service agreements.
• Implicit requirements are not always stated because customers assume that competent providers will meet them. Safety, basic reliability, accuracy, and legal compliance often fall into this category.
• Latent requirements are needs customers may not be able to articulate but value when they experience them, such as intuitive navigation or proactive service updates.
• Mandatory requirements are conditions that must be met, often because of law, safety, or contract.
• Performance requirements describe desired levels of capability, such as delivery time or battery life.
• Delighter requirements can create strong satisfaction when present, although their absence may not initially produce dissatisfaction.

The Kano model is useful for distinguishing basic, performance, and attractive requirements. Basic requirements are taken for granted; their absence causes dissatisfaction, but their presence may not create enthusiasm. Performance requirements generally improve satisfaction as performance improves. Attractive requirements generate disproportionate satisfaction when provided. The categories are not permanent. As markets mature, yesterday’s delighter may become tomorrow’s basic expectation. Quality managers should therefore revisit customer assumptions periodically rather than treating a requirements catalogue as static.

Requirements also come from stakeholders other than direct customers. Employees, suppliers, owners, regulators, communities, distributors, and service partners may influence quality. A medical device, for example, must satisfy patients, clinicians, procurement departments, regulators, maintenance personnel, and healthcare institutions. A design that serves one group while creating unacceptable risks for another is not a complete quality solution.

Discovering the Voice of the Customer

The VOC is not a single document or a simple list of complaints. It is the systematic collection, interpretation, and prioritization of information about customer expectations, experiences, problems, and desired outcomes. Effective VOC work combines qualitative insight with quantitative evidence.

Common sources include interviews, focus groups, observation, contextual inquiry, surveys, online reviews, complaint records, warranty data, customer-service transcripts, social-media analysis, sales information, field studies, and direct-use testing. Internal employees who interact with customers are also valuable sources, although their views must be distinguished from direct customer evidence.

Qualitative methods are particularly useful during discovery. Interviews can reveal why a customer behaves in a certain way, while observation may expose workarounds that customers do not mention. A focus group can generate diverse perceptions, but group dynamics may suppress minority opinions. Surveys permit broader measurement, yet poorly worded questions can create misleading results. Digital text analytics can process large volumes of feedback, but sentiment scores do not by themselves explain the seriousness, context, or legitimacy of a concern.

A disciplined VOC process normally involves the following sequence:

1. Define the customer segments, use situations, and decisions to be supported.

2. Collect information from multiple sources and avoid relying only on the most vocal customers.

3. Separate statements of solution from statements of need. “I want a larger button” may reflect the deeper need for easier operation.

4. Group similar statements into themes and identify contradictions or differences among segments.

5. Convert themes into clear, testable requirements.

6. Prioritize requirements according to importance, risk, regulatory significance, and organizational capability.

7. Confirm the interpretation with representative customers or stakeholders.

8. Maintain traceability from the original voice to the requirement, design feature, test, and outcome.

A frequent error is to confuse customer requests with customer needs. Customers may propose a particular feature because it is familiar, but the feature may not be the best means of achieving the desired outcome. The quality professional must listen respectfully while investigating the underlying purpose. Another error is averaging all customers into one “typical” customer. Segmentation is essential where needs, risks, willingness to pay, or patterns of use differ significantly.

Quality Function Deployment and the House of Quality

Quality Function Deployment is a structured method for translating customer requirements into technical, operational, and organizational responses. QFD encourages cross-functional participation and makes trade-offs visible early, when changes are less expensive. Its best-known instrument is the House of Quality, although QFD can extend through several linked matrices from customer needs to parts, processes, and production controls.

A House of Quality commonly contains:

• customer requirements, often called the “WHATs”;
• importance ratings for those requirements;
• competitive or benchmark information;
• technical characteristics, or the “HOWs”;
• a relationship matrix showing the strength of each technical characteristic in satisfying each customer requirement;
• a roof showing positive and negative correlations among technical characteristics;
• technical priorities, targets, and comparative performance information.

The relationship matrix forces a team to ask whether a proposed technical characteristic genuinely affects a customer requirement. A strong relationship may be scored higher than a moderate or weak relationship using an agreed scale. The numerical values are not scientific truths; they are decision aids. Their value depends on the quality of discussion, evidence, and assumptions behind them.

Suppose a parcel-delivery organization identifies “delivery when promised,” “easy tracking,” and “undamaged package” as important customer requirements. Technical characteristics might include route-planning accuracy, scanning frequency, system availability, packaging-strength specifications, and delivery-window control. The roof may reveal that more frequent scanning improves tracking but increases operational workload, while stronger packaging improves protection but may increase cost and weight. Such tensions should be resolved consciously rather than discovered after launch.

QFD has several managerial benefits. It creates a common language between marketing, design, operations, procurement, and quality. It supports prioritization, prevents technically attractive but low-value features from dominating decisions, and preserves traceability. It also reveals missing ownership: a requirement cannot be effectively controlled if no function is responsible for it.

Nevertheless, QFD has limitations. Ratings may be subjective, matrices can become unwieldy, and teams may treat the method as a paperwork exercise. Customer needs can also change faster than a formal deployment cycle. QFD should therefore be used as a living decision process supported by evidence, not as a one-time form completed to demonstrate compliance.

Designing for Quality

Design and development determine many later quality outcomes. Once a product architecture, service process, interface, material, or technology platform has been selected, the organization may have limited ability to eliminate risk economically. Design quality therefore differs from conformance quality. Conformance asks whether the output matches the specification; design quality asks whether the specification itself represents a suitable and valuable solution.

A controlled design-and-development process usually includes planning, input definition, design activities, review, verification, validation, output approval, and change control. The precise sequence varies by industry, but the underlying logic is consistent: requirements must be clear, risks must be addressed, responsibilities must be defined, and evidence must support decisions.

Design inputs

Design inputs include customer requirements, functional and performance requirements, applicable legal and regulatory obligations, previous lessons, standards, interface requirements, environmental conditions, usability needs, and risk-control requirements. Inputs should be complete, unambiguous, and internally consistent. Conflicting inputs must be resolved rather than passed silently to designers.

Risk-based methods such as failure mode and effects analysis (FMEA), hazard analysis, fault-tree analysis, and misuse analysis help identify what can go wrong and how design controls can reduce the likelihood or consequence. Risk management should begin before detailed design and continue through service experience. A low-probability event may still require strong controls if its consequences are severe.

Design reviews

A design review is a structured examination by competent participants to evaluate whether the design can meet requirements and to identify problems early. Effective reviews include relevant functions, not only designers. Manufacturing, procurement, service, usability, cybersecurity, regulatory, and customer-support perspectives may reveal risks that a purely technical review misses. Reviews should produce decisions, actions, owners, and due dates rather than merely attendance records.

Verification and validation

Verification asks: Have we designed the product or service correctly according to specified requirements? It may involve inspection, calculation, simulation, code review, document review, or testing against defined criteria.

Validation asks: Have we designed the right product or service for its intended use and users? It generally involves realistic conditions, representative users, operational trials, pilot delivery, or field evaluation. A system can pass verification and still fail validation. For example, software may satisfy every documented functional requirement but prove unusable for older customers or unsuitable in a low-connectivity environment.

Verification and validation should be planned, objective, and documented. Test environments, samples, assumptions, measurement methods, and deviations must be controlled. Where safety or regulatory consequences are significant, independent review and formal approval may be necessary.

Design outputs and acceptance criteria

Design outputs include drawings, models, bills of material, software specifications, process instructions, service scripts, training requirements, inspection plans, and maintenance information. Outputs must be suitable for purchasing, production, delivery, and support. They should identify characteristics critical to safety, function, fit, reliability, and customer experience.

Acceptance criteria convert expectations into an observable basis for decision. A strong criterion is specific, measurable, feasible, relevant, and time-bound where appropriate. “The service should be responsive” is weak. “Ninety-five percent of priority customer calls shall be answered by a trained agent within 30 seconds during published operating hours” is more useful, although it still requires definitions for priority, measurement, exclusions, and data integrity.

Acceptance criteria should be agreed before evaluation whenever possible. Defining them after seeing results creates a risk of biased acceptance. For complex projects, criteria may address functionality, performance, usability, reliability, security, accessibility, legal compliance, documentation, and transfer to operations.

Change Control and Configuration Integrity

Design change is inevitable. It may result from customer feedback, supplier discontinuation, defects, regulatory revision, cost pressure, technology evolution, or improvement opportunities. The objective of change control is not to prevent change but to ensure that change is understood, evaluated, authorized, implemented, and verified.

A change request should describe the proposed change, its rationale, affected requirements, risks, documents, interfaces, suppliers, processes, training, inventory, service commitments, and validation needs. A cross-functional review determines whether the change is minor, major, urgent, or safety-critical. Authorization should reflect the significance of the change; not every change requires the same level of governance.

Configuration management maintains the identity and status of approved design items and their relationships. Without it, different teams may use different versions of a specification, software release, service script, or work instruction. After implementation, the organization should verify that the intended change occurred and examine whether unintended effects emerged. Customer communication may be required, particularly when performance, safety, privacy, contractual terms, or maintenance is affected.

Common mistakes include approving changes informally through email, failing to update downstream documents, overlooking obsolete stock, and treating emergency changes as exempt from later review. Emergency action may be necessary, but retrospective documentation and evaluation remain important.

Service Quality: Promise, Process, and Experience

Service quality is the customer’s evaluation of the quality of an intangible or partly intangible performance. It depends not only on the final outcome but also on the process through which the outcome is delivered. A technically correct service can be judged poor if access is difficult, communication is unclear, or the customer feels disregarded.

The SERVQUAL tradition identifies five commonly examined dimensions: tangibles, reliability, responsiveness, assurance, and empathy. These dimensions are useful as diagnostic categories, but they should not be treated as universal or fixed. In a digital service, system availability, privacy, usability, and transparency may be especially important. In healthcare, clinical safety, dignity, continuity, and informed consent are central. Measurement must reflect the service context and customer segment.

A service blueprint maps customer actions, front-stage employee interactions, back-stage activities, support processes, and physical or digital evidence. It helps identify fail points and handoffs. For example, a customer may experience “late delivery,” although the root cause lies in inaccurate inventory records, an uncommunicated carrier change, or an order-entry defect. Service-quality analysis therefore requires an end-to-end process view rather than evaluating only the employee who faces the customer.

Useful service measures include first-contact resolution, response time, waiting time, abandonment rate, on-time performance, complaint recurrence, customer effort, customer satisfaction, retention, and service-level compliance. Measures should be interpreted together. A short call duration may indicate efficiency, but it may also indicate that agents are ending calls prematurely. A high satisfaction average may conceal severe dissatisfaction among a vulnerable segment. Disaggregated analysis by channel, location, product, customer type, and issue category is often more informative than a single overall score.

Complaints, Recovery, and Organizational Learning

A complaint is both an indication of dissatisfaction and a source of information about process performance. A mature quality system does not encourage defensive treatment of complaints or measure success by making complaint numbers disappear. Fewer complaints may mean improvement, but it may also mean that customers have abandoned the organization or find reporting difficult.

Complaint handling normally includes acknowledgement, classification, containment, investigation, communication, resolution, and learning. Immediate recovery may involve correction, replacement, refund, explanation, or escalation. Root-cause analysis then asks why the failure occurred and why existing controls did not prevent or detect it. Corrective action should address systemic causes, not merely instruct an individual to “be more careful.”

Service recovery has a dual character. It must restore the customer’s practical outcome and rebuild confidence through fair, timely, and respectful treatment. Employees require authority, information, and clear escalation rules to recover service effectively. At the same time, compensation policies should not encourage inconsistent or unethical decisions.

Complaint data should feed management review, design changes, training, supplier improvement, risk reassessment, and preventive action. Personal data must be protected, and allegations involving discrimination, safety, fraud, or misconduct require appropriate investigation and governance.

Illustrative Case: Redesigning a Municipal Digital Permit Service

Background

The fictional city of Northbridge introduced an online building-permit service intended to reduce office visits and processing time. The system passed technical acceptance tests and was launched across the city.

Situation and problem

Within three months, completion rates were below target. Contractors complained about repeated data entry, residents reported confusing status messages, and staff received a large volume of telephone calls. The project team initially proposed adding more help pages, but complaint analysis suggested that the problem was broader than insufficient information.

Analysis

A cross-functional team collected customer interviews, call transcripts, web analytics, accessibility feedback, and process data. VOC analysis identified four major needs: confidence that applications were complete, clear visibility of status, minimal repeated entry, and accessible language. Segmentation showed that occasional residents struggled more than professional contractors, while mobile users experienced a higher abandonment rate.

The team used a simplified House of Quality. “Know whether the application is complete” was linked to field-level validation, a completion checklist, and a clear submission confirmation. “Track progress” was linked to status definitions, event-based notifications, and staff workflow integration. The analysis also exposed a negative correlation: adding every possible form field to one screen reduced staff rework but increased customer confusion.

Verification confirmed that revised functions worked against documented requirements. Validation involved residents and contractors completing representative applications on mobile and desktop devices. It revealed that users interpreted “under review” as a final decision rather than an intermediate status. The wording and status design were therefore changed.

Approach and solution

The city introduced progressive disclosure, saved drafts, plain-language status messages, accessibility improvements, and a visible checklist. Acceptance criteria included successful completion by representative users, defined response times, no loss of saved data, and accurate status transitions. A change-control board reviewed the effect on training, records, privacy, and staff procedures. Complaint categories were standardized so that future trends could be monitored.

Outcome

The redesigned service reduced avoidable contacts and improved completion in pilot testing. More importantly, the city established a repeatable process linking customer evidence, requirements, design decisions, validation, and operational learning. The case does not claim that one redesign eliminates all service problems; rather, it demonstrates how quality improves when customer experience is treated as an end-to-end system.

Learning points

The case illustrates that technical verification is insufficient without user validation; that customer needs must be translated into measurable design characteristics; that changes affect people and processes beyond the software; and that complaint data becomes valuable when classified and connected to corrective action.

Challenges, Risks, and Professional Judgement

Customer-focused design contains several recurring risks. Sampling bias may cause organizations to design for highly engaged or easily reached customers while ignoring silent, vulnerable, or infrequent users. Customers may express contradictory needs, requiring transparent prioritization rather than arbitrary selection. Requirements can become excessive and increase complexity, cost, or security exposure. Overreliance on numerical satisfaction scores may conceal serious qualitative concerns.

There are also organizational risks. Marketing may promise features that operations cannot reliably deliver. Engineering may optimize measurable technical performance while neglecting usability. Quality departments may focus on documentation rather than learning. Suppliers may control critical design knowledge without adequate oversight. Poorly defined ownership can cause requirements to fall between departments.

Ethically, organizations must not manipulate VOC research, suppress complaints, design confusing consent processes, or use customer data beyond legitimate purposes. Accessibility and inclusion should be considered in requirements, validation, and service recovery. Safety-critical information must not be hidden by commercial priorities. Artificial intelligence may help classify feedback or predict service failure, but automated decisions require attention to bias, explainability, privacy, human oversight, and the risk of treating statistical patterns as individual truth.

Regulatory and contractual obligations should be incorporated into design inputs, not added at the end. Depending on the sector, these may concern product safety, data protection, accessibility, financial controls, environmental requirements, professional licensing, or records retention. Compliance is a minimum condition; it does not automatically establish customer value or excellent service.

Digital Tools, Analytics, and Emerging Practice

Digital platforms increasingly connect requirements management, product lifecycle management, configuration control, test evidence, complaint systems, and customer analytics. Traceability dashboards can show whether every critical requirement has an owner, design response, verification result, validation evidence, and post-launch indicator. Process mining can reveal delays and rework in service journeys. Text analytics can classify complaints and detect emerging themes, but human review remains necessary for ambiguity, severity, and context.

Digital twins, simulation, remote testing, and continuous delivery can shorten design cycles and support earlier validation. In software-enabled products, however, frequent releases make configuration integrity and cybersecurity essential. Customer experience may change after deployment because algorithms, interfaces, or external services change. Consequently, validation is not only a pre-launch event; monitoring and reassessment must continue through the product or service life cycle.

Current practice is moving toward co-design, inclusive design, outcome-based requirements, and continuous discovery. Customers and frontline employees are increasingly involved in prototypes and pilot services. Organizations are also combining operational measures with experience measures to understand both what happened and how it was perceived. The strategic implication is that quality is becoming a dynamic capability: the organization must repeatedly sense changing needs, translate them into decisions, and learn from actual use.

Best Practices for Managers and Quality Professionals

Effective practice can be summarized in several principles:

• Begin with customer outcomes and stakeholder risks, not with predetermined features.
• Use multiple VOC sources and validate interpretations with representative users.
• Distinguish needs, requirements, specifications, and acceptance criteria.
• Involve marketing, design, operations, procurement, service, quality, and compliance early.
• Use QFD or a comparable method to make priorities and trade-offs explicit.
• Build verification and validation into the design plan from the beginning.
• Define objective acceptance criteria before testing whenever practicable.
• Maintain traceability from customer need through design, test, delivery, and feedback.
• Control changes according to risk and update all affected documents, systems, and people.
• Treat complaints as evidence for improvement, while protecting confidentiality and fairness.
• Combine customer-experience measures with operational, risk, and financial indicators.
• Reassess requirements after launch because expectations, technologies, and contexts change.

Chapter Summary

Customer requirements are the foundation for designing quality, but customer statements must be interpreted and translated into clear, testable requirements. VOC methods reveal explicit, implicit, latent, and stakeholder needs, while the Kano model helps explain how different requirements influence satisfaction. QFD and the House of Quality provide a cross-functional means of connecting customer requirements with technical characteristics, priorities, targets, and trade-offs.

A controlled design-and-development process uses sound inputs, risk analysis, design reviews, verification, validation, documented outputs, and acceptance criteria. Verification establishes whether the design conforms to specified requirements; validation establishes whether it is suitable for intended users and use conditions. Change control and configuration management preserve the integrity of approved designs while allowing necessary improvement.

Service quality depends on both outcome and delivery experience. Service blueprints, operational indicators, customer measures, and complaint analysis help organizations identify failure points and improve recovery. Digital analytics and AI can strengthen insight, but they require governance, privacy protection, human judgement, and continued validation. The central lesson is that customer-focused quality is an integrated organizational process linking listening, designing, delivering, measuring, and learning.

Key Terms

Acceptance criteria: Defined conditions that an output must satisfy to be accepted.

Design validation: Evidence that a product or service meets the needs of intended users in intended conditions.

Design verification: Evidence that design outputs conform to specified design inputs.

Design input: Requirement or constraint used as a basis for design and development.

Design output: Documented result of design activities, such as specifications, drawings, or process instructions.

Explicit requirement: A requirement directly stated by a customer, contract, standard, or regulation.

House of Quality: A QFD matrix linking customer requirements with technical characteristics and priorities.

Implicit requirement: An unstated condition that users reasonably expect the provider to fulfil.

Kano model: A model classifying requirements as basic, performance, or attractive in relation to satisfaction.

Latent requirement: An unarticulated need that becomes apparent through observation or experience.

Quality Function Deployment (QFD): A structured method for translating customer needs into design and operational requirements.

Quality specification: A precise description of a required characteristic, limit, or performance level.

Service blueprint: A map of customer actions, employee interactions, support processes, and service evidence.

Stakeholder requirement: A requirement originating from a party affected by or able to affect the organization.

Voice of the customer (VOC): Systematic information about customer expectations, experiences, problems, and desired outcomes.

Configuration management: Control of the identity, version, status, and relationships of approved design items.

Complaint: An expression of dissatisfaction requiring a response or resolution.

Traceability: The ability to connect a requirement with its source, design response, test evidence, and outcome.

Review Questions

Short Answer Questions

1. Distinguish between a customer need, a requirement, a specification, and an acceptance criterion.

2. What is the purpose of the voice-of-the-customer process?

3. Explain the difference between design verification and design validation.

4. What information is normally represented in the House of Quality?

5. Why should complaints be treated as inputs to organizational learning?

Long Answer Questions

1. Explain how an organization can translate ambiguous customer statements into measurable and traceable quality requirements.

2. Describe the QFD process and critically discuss the benefits and limitations of the House of Quality.

3. Discuss the major stages of a controlled design-and-development process, including risk analysis, review, verification, validation, and output approval.

4. Explain how service blueprinting and service-quality measurement can reveal the causes of customer dissatisfaction.

5. Discuss the role of change control and configuration management in preserving quality throughout the product or service life cycle.

Analytical / Application Questions

1. A bank’s customers describe its mobile application as “inconvenient and unreliable.” Develop a VOC plan and propose at least five measurable requirements and corresponding acceptance criteria.

2. A manufacturer has achieved excellent laboratory test results, but customers report that its product is difficult to install and maintain. Use the distinction between verification and validation to diagnose the failure and recommend an improvement plan.

3. A hospital receives fewer formal complaints after introducing an automated chatbot, but social-media dissatisfaction and patient switching have increased. Analyze possible explanations and design a balanced measurement and governance approach.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes design validation from design verification?

A. Validation checks conformity to internal documents, while verification measures customer satisfaction only.

B. Validation evaluates suitability for intended users and use conditions, while verification checks conformity to specified design inputs.

C. Validation occurs before requirements are defined, while verification occurs only after launch.

D. Validation concerns suppliers, while verification concerns customers.

Correct Answer: B. Validation evaluates suitability for intended users and use conditions, while verification checks conformity to specified design inputs.

Question 2

A customer says, “I need the application to be easy to use.” Which is the most appropriate next step in requirements translation?

A. Accept the statement as a complete technical specification.

B. Replace the application with a feature selected by the design team.

C. Investigate the underlying need and define measurable usability requirements and acceptance criteria.

D. Ignore the statement because ease of use cannot be measured.

Correct Answer: C. Investigate the underlying need and define measurable usability requirements and acceptance criteria.

Question 3

In a House of Quality, the relationship matrix primarily shows:

A. The relationship between customer requirements and technical characteristics.

B. The reporting relationships among project team members.

C. The relationship between suppliers and financial budgets.

D. The relationship between complaints and employee attendance.

Correct Answer: A. The relationship between customer requirements and technical characteristics.

Question 4

Which situation is the clearest example of a latent customer requirement?

A. A contract explicitly specifies a delivery date.

B. A regulator requires a safety label.

C. Customers request a particular model number.

D. Users do not ask for error prevention but strongly value a system that prevents accidental data loss.

Correct Answer: D. Users do not ask for error prevention but strongly value a system that prevents accidental data loss.

Question 5

Why is defining acceptance criteria before testing generally preferable?

A. It guarantees that every test will produce a passing result.

B. It reduces the risk of changing the basis of acceptance after seeing the results.

C. It eliminates the need for customer validation.

D. It prevents all future design changes.

Correct Answer: B. It reduces the risk of changing the basis of acceptance after seeing the results.

Question 6

A product passes every documented functional test but is consistently rejected by intended users because they cannot operate it safely. This most strongly indicates inadequate:

A. Design verification.

B. Configuration identification.

C. Design validation.

D. Supplier payment control.

Correct Answer: C. Design validation.

Question 7

Which action best reflects effective complaint management?

A. Remove complaints from reports to protect the organization’s image.

B. Resolve the individual case and investigate systemic causes and failed controls.

C. Compensate every complainant without investigating the issue.

D. Transfer all complaints to marketing without operational involvement.

Correct Answer: B. Resolve the individual case and investigate systemic causes and failed controls.

Question 8

A design change affects software, training materials, service procedures, and customer privacy notices. What is the most appropriate quality-system response?

A. Approve it informally because the software change is technically small.

B. Evaluate cross-functional effects, authorize the change according to risk, update affected items, and verify implementation.

C. Delay all changes indefinitely.

D. Update only the software version number.

Correct Answer: B. Evaluate cross-functional effects, authorize the change according to risk, update affected items, and verify implementation.

Question 9

Which measurement interpretation is most appropriate?

A. A shorter call duration always proves better service.

B. A high average satisfaction score proves that no customer segment has a problem.

C. Operational and experience measures should be examined together and, where useful, segmented by customer group or channel.

D. Complaint volume is always an accurate measure of actual defect frequency.

Correct Answer: C. Operational and experience measures should be examined together and, where useful, segmented by customer group or channel.

Question 10

What is a major governance risk when AI is used to classify customer feedback?

A. It may process information too quickly to be useful.

B. It eliminates the need for any data protection controls.

C. It may introduce bias or misinterpret context, requiring human oversight and review.

D. It makes traceability impossible in every application.

Correct Answer: C. It may introduce bias or misinterpret context, requiring human oversight and review.