Customer, Stakeholder and Regulatory Requirements

Introduction

Quality planning begins before a product is designed or a service is delivered. An organisation must understand what customers value, what other stakeholders require, and what laws, standards, contracts and ethical obligations permit or demand. These requirements are then converted into measurable specifications that can guide design, procurement, production, inspection and improvement.

A central quality-management principle is that quality is not defined only by conformance to internal specifications. A product may conform perfectly to its drawings and still fail because it is inconvenient, unsafe, unaffordable, unavailable or legally non-compliant. Effective quality planning therefore connects external expectations with internal processes through a disciplined chain:

stakeholder need → interpreted requirement → measurable characteristic → specification → process control → evidence of conformity

This chapter explains how to identify customers and stakeholders, collect and analyse the Voice of the Customer (VOC), investigate complaints, identify critical-to-quality (CTQ) characteristics, apply the Kano model, and use Quality Function Deployment (QFD). It also examines the special status of regulatory requirements and the risks of treating customer preference, contractual obligation and legal duty as if they were interchangeable.

Learning objectives

By the end of this chapter, the learner should be able to:

1. Distinguish customers, users, purchasers, regulators and other stakeholders.
2. Select appropriate methods for collecting and validating the Voice of the Customer.
3. Analyse complaints and market evidence without confusing symptoms with underlying needs.
4. Construct CTQ trees and translate qualitative statements into measurable requirements.
5. Use the Kano model to classify customer expectations and support prioritisation.
6. Explain the logic and stages of Quality Function Deployment.
7. Integrate regulatory and contractual requirements into quality planning.
8. Evaluate limitations, ethical risks and implementation challenges in requirements analysis.

1. Customers, users and stakeholders

A customer is an individual or organisation that receives, purchases or is otherwise entitled to receive a product or service. The customer may be external, such as a paying client, or internal, such as a department receiving an output from another department. The user is the person who actually uses the product or experiences the service. The purchaser, user and beneficiary may be different people.

For example, in a hospital procurement decision, the purchasing department may buy a monitoring device, nurses may operate it, patients may be affected by it, biomedical engineers may maintain it, and a regulator may impose safety requirements. Each group has legitimate but different requirements.

A stakeholder is a person or group that can affect, be affected by, or perceive itself to be affected by an organisation’s decision or activity. Relevant stakeholders commonly include:

• customers, users and distributors;
• employees and managers;
• suppliers and outsourced service providers;
• owners, investors and insurers;
• regulators, certification bodies and public authorities;
• local communities and the wider public;
• professional bodies and consumer organisations.

Stakeholder analysis should not be reduced to a list of names. It should identify the stakeholder’s relationship to the organisation, the nature of the requirement, the evidence supporting it, its level of influence, and the consequence of failure.

A useful distinction is between stated requirements, which stakeholders express directly, and latent requirements, which they may not articulate because they assume them or do not know that a solution is possible. Customers may say that they want a “fast delivery,” while the underlying need may be certainty, reduced downtime or the ability to plan labour. Requirements analysis must therefore investigate context rather than merely record words.

Prioritising stakeholders

Not every stakeholder has equal decision authority, but a low-power stakeholder may still have a legally protected interest or the ability to create significant reputational risk. A practical assessment considers:

• influence: ability to affect decisions or outcomes;
• legitimacy: whether the claim is valid and recognised;
• urgency: how quickly the issue requires attention;
• impact of failure: safety, financial, environmental, legal and social consequences.

This assessment supports communication planning, but it must not be used to ignore vulnerable users. Regulatory and safety obligations remain binding even when the affected group has little commercial influence.

2. The Voice of the Customer

The Voice of the Customer is a structured representation of customer expectations, problems, preferences and desired outcomes. VOC is not one particular survey. It is a process of gathering, interpreting, validating and prioritising evidence about customer needs.

Sources of VOC evidence

Common sources include:

• interviews and focus groups;
• observation, contextual inquiry and ethnographic research;
• surveys and structured questionnaires;
• customer-support records and complaint logs;
• warranty returns and product-failure data;
• sales-force reports and distributor feedback;
• website searches, reviews and social-media analysis;
• competitor benchmarking and mystery shopping;
• usage telemetry, where lawful and ethically justified;
• contract reviews and customer performance meetings.

Each method has a different strength. Interviews reveal language and motives but may involve small, non-representative samples. Surveys can estimate prevalence when sampling and question design are sound, but they may miss unspoken needs. Complaints identify failure points, but satisfied customers who remain silent are not represented. Usage data can reveal actual behaviour, but it does not automatically explain why the behaviour occurs.

A professional VOC programme therefore uses triangulation: comparing multiple evidence sources and investigating material differences between them.

Designing useful customer research

A research plan should define the decision to be made, the target population, the sampling approach, the questions or observations required, and how findings will be analysed. Poorly designed research creates false confidence. Leading questions, ambiguous scales, convenience samples, interviewer influence and non-response bias can distort results.

A question such as “How excellent was our fast and convenient delivery?” contains assumptions and encourages agreement. A better approach separates attributes and asks about actual experience, importance and desired improvement. Quantitative results should be accompanied by sample size, response rate, time period, segment and data-collection method.

For a rating question using a numerical scale, the arithmetic mean may be calculated as:

Here, xᵢ is respondent i’s rating, n is the number of valid responses, and x̄ is the sample mean. The formula is applicable when ratings are being treated as approximately interval-scaled and when the mean is an appropriate summary. For ordinal categories, such as “poor,” “fair,” “good” and “excellent,” the median or distribution of responses may be more defensible than the mean.

A simple response percentage is:

where k is the number of respondents meeting a defined condition and n is the number of valid respondents. The denominator must be stated clearly; excluding “not applicable” responses can change interpretation.

From verbatim comments to need statements

Customer language should first be preserved in a verbatim record. Analysts then interpret it into a concise need statement without embedding a particular solution. For example:

The better statements describe an outcome, not an assumed design. This preserves creative options during solution development.

3. Complaint analysis and service recovery

A complaint is both a failure signal and a source of requirements information. It should not be treated merely as an administrative case to close. Complaint analysis asks:

1. What happened from the customer’s perspective?
2. What requirement was unmet?
3. Was the requirement stated, contractual, regulatory or assumed?
4. Is the event isolated or systemic?
5. What immediate containment is necessary?
6. What causal action will prevent recurrence?

The symptom is the visible problem, such as a late delivery or leaking package. The cause may lie in demand forecasting, packaging design, supplier variation, information transfer or an inadequate control plan. A root cause is a sufficiently fundamental, evidence-supported cause whose removal prevents recurrence under the relevant conditions.

Useful tools include stratification, Pareto analysis, process mapping, the five-whys method, fault-tree analysis and cause-and-effect diagrams. The five-whys method is not a ritual of asking exactly five questions; it is an iterative inquiry that must stop when evidence identifies a controllable cause rather than a vague conclusion such as “operator error.”

Complaint metrics should be defined carefully. For example, a complaint rate per 1,000 shipped units can be expressed as:

where c is the number of valid complaints in the defined period and q is the number of units shipped in that period. The measure is meaningful only when the complaint definition, time window, product mix and reporting practices remain comparable. A fall in complaints may indicate improvement, but it may also reflect reduced reporting or poor access to support.

Complaint handling also includes service recovery: acknowledgement, respectful communication, risk assessment, correction, investigation and feedback to the customer. Organisations should never discourage legitimate complaints because this damages learning and may conceal safety or compliance failures.

4. Critical-to-quality trees

A CTQ tree converts a broad need into operational requirements. It normally has three levels:

1. Need: the customer’s desired outcome.
2. Driver: a controllable factor that influences the outcome.
3. Measure: a quantifiable characteristic with a target or acceptance limit.

For example:

Need: “The online payment should feel secure.”

Drivers: authentication, transaction integrity, privacy, recovery from failure.

Measures: proportion of transactions using approved authentication controls, unauthorised-transaction rate, encryption configuration, time to detect and respond to incidents, and availability of a recovery channel.

A CTQ measure should be operationally defined. “Fast service” is not measurable until the start point, end point, population, unit, sampling method and target are specified. A complete requirement might be: “For standard orders received before the published cut-off, 95% shall be dispatched within one working day, measured monthly from the order-management timestamp to the carrier handover scan.”

Good CTQs are:

• relevant to a validated need;
• measurable with an identified method and instrument;
• controllable or influenceable by the process;
• expressed with a target, tolerance or decision rule;
• traceable to a source and revision;
• balanced against safety, cost, sustainability and other requirements.

A target is not automatically a specification. A customer preference may be optimised, whereas a safety or legal limit may be mandatory. Measurement-system capability must also be considered: a specification that cannot be measured reliably cannot support trustworthy acceptance decisions.

5. The Kano model

The Kano model classifies product or service attributes according to their relationship with customer satisfaction. The classic categories are:

• Must-be (basic) attributes: their absence causes strong dissatisfaction, but their presence is often taken for granted and produces limited additional delight.
• One-dimensional attributes: satisfaction generally increases as performance improves, while dissatisfaction increases as performance declines.
• Attractive (excitement) attributes: their presence can delight customers, but their absence may not cause dissatisfaction because they were not expected.
• Indifferent attributes: performance has little effect on the target customer’s satisfaction.
• Reverse attributes: providing the feature may reduce satisfaction for some segments.

The model is dynamic. An attractive feature may become a basic expectation as competitors and technology change. For example, online order tracking was once distinctive for many markets but is now expected in numerous sectors.

Kano research commonly asks paired functional and dysfunctional questions: how a respondent would feel if a feature were present, and how they would feel if it were absent. Responses are classified using a Kano evaluation table. Results should be segmented because a feature can be attractive to one market and irritating or irrelevant to another.

Kano analysis supports prioritisation but does not replace regulatory review, risk analysis or economic evaluation. A delightful feature cannot compensate for an unsafe or non-compliant product. Nor should organisations remove basic requirements merely because customers do not mention them.

6. Quality Function Deployment

Quality Function Deployment (QFD) is a structured method for translating customer requirements into technical characteristics, component requirements, process controls and production or service plans. The first matrix is often called the House of Quality, although QFD is broader than that single diagram.

A typical first-phase QFD includes:

1. customer requirements, often called the “WHATs”;
2. importance ratings and customer segments;
3. technical characteristics, or “HOWs”;
4. a relationship matrix linking WHATs to HOWs;
5. technical correlation, sometimes called the roof;
6. competitive or benchmark information;
7. target values and priorities;
8. responsibility and follow-up actions.

Relationships are often coded using values such as 9 for strong, 3 for medium, 1 for weak and 0 for no relationship. These values are conventions, not universal scientific constants. The team must define them consistently and avoid pretending that the resulting priority score is an exact measurement.

A simple technical priority score is:

where Pⱼ is the unnormalised priority of technical characteristic j, wᵢ is the importance weight of customer requirement i, rᵢⱼ is the assigned relationship strength between requirement i and characteristic j, and m is the number of customer requirements. The score is dimensionless when the weights and relationship codes are dimensionless. It is useful for relative prioritisation only when the scales and weighting approach are applied consistently.

Worked QFD example

An illustrative team is planning a reusable delivery container. Three customer requirements have importance weights of 5, 4 and 3:

• W₁: contents remain undamaged;
• W₂: container is easy to carry;
• W₃: container is easy to clean.

The technical characteristics are wall impact strength, empty mass and internal surface cleanability. Using relationship scores 9, 3, 1 and 0, the team records:

The priorities are:

• Impact strength: (5 × 9) + (4 × 1) + (3 × 0) = 49
• Empty mass: (5 × 1) + (4 × 9) + (3 × 1) = 44
• Surface cleanability: (5 × 0) + (4 × 0) + (3 × 9) = 27

The result suggests that impact strength deserves the greatest technical attention, followed by empty mass and surface cleanability. It does not prove that impact strength is more important in every sense. The team must still consider legal safety requirements, feasibility, cost, environmental effects, interactions among characteristics and verification methods. For example, increasing wall thickness may improve impact strength but increase mass, illustrating why the correlation section and cross-functional review matter.

QFD should continue through subsequent phases: product or service design, parts or resource deployment, process planning and control planning. Requirements can be traced from customer language to design features, process parameters, inspection methods and records.

7. Regulatory, statutory and contractual requirements

Regulatory requirements are obligations established by law or an authorised public body. Statutory requirements are imposed by legislation. Contractual requirements arise from an agreement and may be stricter than the law. Voluntary standards become binding when adopted by contract, regulation, certification arrangement or organisational policy.

Examples include product safety rules, food and pharmaceutical controls, environmental permits, occupational health requirements, accessibility obligations, consumer-protection law and privacy or data-protection rules. The applicable requirements depend on jurisdiction, product classification, intended use, market, technology and organisational activity.

A compliance process should include:

1. identifying applicable jurisdictions and authorities;
2. maintaining an authorised register of laws, regulations, standards and contracts;
3. interpreting each requirement into an internal obligation;
4. assigning ownership and evidence requirements;
5. designing controls and verification activities;
6. monitoring revisions and expiry dates;
7. conducting compliance evaluation and corrective action.

Legal interpretation may require qualified specialists. Quality personnel should not assume that a general internet search or an old copy of a standard is sufficient. Requirements should be controlled by version, effective date, scope and responsible authority.

Regulatory requirements may be expressed as outcomes, prescriptive rules, performance limits, documentation obligations, reporting duties or approval conditions. They must be incorporated into design inputs and control plans early. Compliance cannot be inspected into a product after an inherently unsafe design has been released.

Ethical and governance issues

Requirements analysis involves power and information. Organisations may manipulate surveys, suppress complaints, collect excessive personal data, design for an average user while excluding people with disabilities, or prioritise profitable segments over safety. Ethical practice requires informed participation where appropriate, privacy protection, fair treatment, accessibility, honest reporting and escalation of serious risk.

Data used for VOC should have a defined purpose, controlled access and an appropriate retention period. AI tools may assist in classifying comments, detecting themes or identifying complaint trends, but automated classifications require human validation. Models can reproduce language, cultural and sampling biases; confidential information should not be entered into an unauthorised system. A human remains accountable for regulatory interpretation and safety decisions.

8. Integrated requirements-planning process

A robust process can be organised as follows:

Scope and context: define product, service, users, markets and intended use.

Stakeholder identification: map affected parties and their authority, vulnerability and impact.

Evidence collection: combine interviews, observation, surveys, complaints, operational data, contracts and legal sources.

Need interpretation: separate needs from solutions and identify hidden assumptions.

Requirement definition: write clear, testable and traceable statements.

CTQ development: identify measurable characteristics, methods, targets and limits.

Prioritisation: use risk, Kano, customer importance, QFD, feasibility and compliance status.

Design and control translation: connect requirements to specifications, processes, inspection and records.

Validation: confirm that the solution meets intended use and stakeholder expectations.

Review and change control: monitor complaints, regulations, technology, competitors and changing expectations.

Requirements should be uniquely identified and linked to their source, owner, verification method, status and revision. Traceability reduces the risk that a customer promise disappears during handover from marketing to design or from design to operations.

Illustrative case: reducing failures in a cold-chain delivery service

Background

A fictional regional healthcare distributor delivers temperature-sensitive medicines to clinics. Customers complain that deliveries are sometimes late and that temperature-monitoring reports are difficult to interpret. The distributor initially proposes buying faster vehicles.

Problem

Complaint records show 38 complaints in one quarter, but the count alone does not reveal whether the main issue is transport speed, dispatch scheduling, packaging, data visibility or clinic receiving practices. Regulatory obligations also require documented temperature control and product traceability.

Analysis

The team interviews pharmacists, drivers, receiving clerks and procurement officers; reviews delivery timestamps and sensor records; observes receiving operations; and examines applicable regulatory and contractual requirements. It discovers three distinct needs:

• medicines arrive within the agreed delivery window;
• product temperature remains within the specified range throughout custody;
• receiving staff can quickly determine whether a shipment is acceptable.

A CTQ tree produces measures such as on-time delivery percentage, proportion of shipments with complete temperature records, excursions beyond the validated range, and time required to make a release decision. The team finds that many “late” deliveries were actually waiting at a clinic because the delivery appointment was unclear. Other failures were caused by sensor reports being uploaded after the receiving decision.

Approach and solution

QFD links the needs to technical characteristics: route-planning accuracy, appointment confirmation, packaging thermal performance, sensor availability, data-upload latency and report readability. Kano interviews show that basic temperature integrity and reliable records are must-be attributes, while a proactive exception alert is attractive but not a substitute for the basics.

The organisation revises appointment confirmation, validates packaging for seasonal conditions, introduces a controlled sensor-report workflow and creates a concise receiving status display. It also establishes escalation rules for excursions and reviews supplier and carrier controls.

Outcome

After three months, the organisation reports fewer missed appointments, faster receiving decisions and improved traceability. The result is not attributed solely to faster vehicles; it comes from translating stakeholder needs into coordinated process and technical requirements. The organisation continues to monitor the measures because a short observation period cannot prove permanent improvement.

Learning points

1. A complaint symptom may conceal several different requirements.
2. Regulatory evidence must be designed into the process, not reconstructed later.
3. Customer, user and purchaser perspectives can conflict and must be reconciled.
4. QFD helps coordinate decisions but does not replace validation or risk management.
5. Measures need definitions, owners, data quality checks and review rules.

Challenges and limitations

Requirements work is difficult because stakeholders may disagree, needs change, and evidence is incomplete. Important limitations include:

• customers may not be able to describe latent needs;
• stated preferences may differ from actual behaviour;
• survey ratings can conceal subgroup differences;
• complaint data overrepresents people who report problems;
• QFD scores may create false numerical precision;
• regulatory language may require specialist interpretation;
• optimisation for one CTQ can damage another;
• rapid innovation can make specifications obsolete;
• excessive requirements can increase cost, complexity and environmental burden.

These limitations are managed through segmentation, triangulation, risk-based prioritisation, cross-functional review, pilot testing, usability validation, controlled change management and periodic revalidation.

Best-practice checklist

• Identify purchasers, users, beneficiaries, maintainers and affected third parties.
• Record both expressed and inferred needs, but distinguish evidence from assumption.
• Use more than one VOC source for important decisions.
• Preserve customer language before translating it into requirements.
• Define CTQs with units, measurement methods, targets and acceptance rules.
• Treat safety, legal and contractual requirements as distinct requirement classes.
• Use Kano to understand satisfaction dynamics, not to override compliance duties.
• Use QFD for cross-functional translation and traceability.
• Check measurement-system suitability and data quality.
• Protect personal information and provide channels for vulnerable users.
• Validate requirements with representative users and intended-use conditions.
• Review requirements when technology, law, customer behaviour or risk changes.

Chapter Summary

Quality planning must begin with a systematic understanding of customers, users and stakeholders. The Voice of the Customer combines interviews, observation, surveys, complaints, operational evidence and market research; no single source is sufficient for every decision. Customer statements should be translated into outcome-focused needs, then decomposed through CTQ trees into measurable characteristics with defined targets and verification methods.

Complaint analysis distinguishes symptoms from causes and uses evidence to identify systemic improvement opportunities. The Kano model explains how basic, performance and excitement attributes influence satisfaction, while recognising that expectations change over time and across segments. QFD provides a cross-functional method for translating customer requirements into technical characteristics, design priorities, process controls and traceable evidence. Its numerical scores support structured discussion but are not exact measures of value.

Regulatory, statutory and contractual requirements must be identified, interpreted, controlled and verified alongside customer needs. Legal compliance, safety, privacy, accessibility and ethical responsibilities cannot be traded away for customer delight or commercial convenience. An effective requirements system is therefore evidence-based, measurable, risk-aware, inclusive, traceable and continuously reviewed.

Key Terms

Customer: A person or organisation that receives, purchases or is entitled to receive a product or service.

User: The person who actually operates, consumes or experiences a product or service.

Stakeholder: A person or group that can affect, be affected by, or perceive itself to be affected by an activity or decision.

Voice of the Customer: Structured evidence about customer expectations, problems, preferences and desired outcomes.

Latent requirement: A need that is not directly stated but is inferred from context, behaviour or assumed expectations.

Complaint: An expression of dissatisfaction associated with a product, service or process.

Root cause: An evidence-supported underlying cause whose removal prevents recurrence under relevant conditions.

Critical-to-quality characteristic: A measurable characteristic that is important to achieving a customer, safety, regulatory or business requirement.

CTQ tree: A structure that decomposes a broad need into drivers and measurable requirements.

Kano model: A framework classifying attributes by their effect on customer satisfaction.

Must-be attribute: A basic attribute whose absence causes dissatisfaction and whose presence is often taken for granted.

One-dimensional attribute: An attribute for which increased performance generally increases satisfaction.

Attractive attribute: An unexpected attribute that can create delight when present.

Quality Function Deployment: A method for translating customer requirements into technical, design, process and control requirements.

House of Quality: The commonly used first QFD matrix linking customer requirements to technical characteristics.

Regulatory requirement: An obligation established by law or an authorised public authority.

Contractual requirement: An obligation created by an agreement between parties.

Traceability: The ability to follow a requirement through its source, implementation, verification and records.

Triangulation: Comparison of evidence from multiple sources or methods to improve confidence in findings.

Review Questions

Short Answer Questions

1. Distinguish a customer, a user and a stakeholder, using an example.
2. Why should customer needs be written as outcomes rather than proposed solutions?
3. What are the three main levels of a CTQ tree?
4. Define a must-be attribute in the Kano model.
5. State two reasons why regulatory requirements must be controlled by version and scope.

Long Answer Questions

1. Explain how an organisation can design a VOC programme using interviews, surveys, complaints and operational data.
2. Describe the stages of QFD and explain how the House of Quality supports cross-functional quality planning.
3. Compare the Kano model and CTQ analysis, including the different decisions each supports.
4. Explain how complaint analysis can move an organisation from service recovery to systemic corrective action.
5. Discuss the ethical and governance issues involved in collecting and analysing customer data.

Analytical / Application Questions

1. A customer says, “The service is unreliable.” Construct a CTQ tree with at least two drivers and two measurable CTQs, including definitions of the measurement methods.
2. A new feature is strongly preferred by one customer segment but disliked by another. Explain how Kano analysis, segmentation, risk assessment and QFD could be used to decide whether and how to implement it.
3. A product meets its internal design specification but violates a newly revised legal requirement. Develop an appropriate requirements-management response, including containment, review, traceability, verification and change control.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a user from a purchaser?

A. The user always has greater legal authority than the purchaser.

B. The user operates or experiences the product, while the purchaser acquires it.

C. The purchaser is always an internal stakeholder.

D. There is no meaningful distinction between them.

Correct Answer: B. The user operates or experiences the product, while the purchaser acquires it.

Question 2

Which is the strongest example of a measurable CTQ?

A. The service should be excellent.

B. The product should look modern.

C. At least 95% of eligible orders shall be dispatched within one working day.

D. Customers should feel valued.

Correct Answer: C. At least 95% of eligible orders shall be dispatched within one working day.

Question 3

What is the main purpose of triangulation in VOC research?

A. To replace all qualitative research with surveys.

B. To compare evidence from multiple sources or methods.

C. To ensure every respondent receives the same complaint outcome.

D. To convert every requirement into a legal obligation.

Correct Answer: B. To compare evidence from multiple sources or methods.

Question 4

In the Kano model, an attractive attribute is one that:

A. Must be legally present in every product.

B. Causes dissatisfaction when performance increases.

C. Can delight customers when present but may not dissatisfy them when absent.

D. Has no effect on any customer segment.

Correct Answer: C. Can delight customers when present but may not dissatisfy them when absent.

Question 5

In QFD, the relationship score links:

A. A customer requirement to a technical characteristic.

B. A complaint to a regulator only.

C. A supplier invoice to a financial account.

D. A law to an employee appraisal.

Correct Answer: A. A customer requirement to a technical characteristic.

Question 6

Using Pⱼ = ∑wᵢrᵢⱼ, what is the priority for a technical characteristic with weights 5, 4 and 3 and relationship scores 9, 1 and 0?

A. 14

B. 45

C. 49

D. 72

Correct Answer: C. 49

Question 7

Why is “operator error” often an inadequate root-cause conclusion?

A. Operators can never make mistakes.

B. It may describe a symptom without investigating system conditions and controls.

C. It is always a regulatory term.

D. It proves that training is unnecessary.

Correct Answer: B. It may describe a symptom without investigating system conditions and controls.

Question 8

Which requirement source is normally mandatory because it is established by law or an authorised public body?

A. A personal preference

B. A voluntary suggestion

C. A regulatory requirement

D. An informal benchmark

Correct Answer: C. A regulatory requirement

Question 9

What is a key limitation of QFD relationship scores?

A. They cannot be used by cross-functional teams.

B. They are exact scientific measurements of customer value.

C. They may create false precision and depend on consistent team judgement.

D. They eliminate the need for design validation.

Correct Answer: C. They may create false precision and depend on consistent team judgement.

Question 10

A complaint rate is calculated as r = (c/q) × 1,000. If c = 12 complaints and q = 4,000 shipped units, what is r?

A. 0.3 complaints per 1,000 units

B. 3 complaints per 1,000 units

C. 30 complaints per 1,000 units

D. 300 complaints per 1,000 units

Correct Answer: B. 3 complaints per 1,000 units