What this is
What is a customer register?
What is a customer register?
A customer register is the master list of every customer supplied, with the facts that other processes depend on: which products they receive, whether their specification is on file and current, whether they conduct their own audits, and whether a defined route exists for a complaint to reach the right person. It is maintained continuously rather than closed out per event.
Who maintains a customer register, and why does it need two functions?
Commercial holds the relationship: account owner, market, channel, contract terms. Quality holds the technical relationship: specification status, audit requirements, complaint routing. Both signatures appear on the record for a reason, an account owner alone cannot certify specification currency, and quality alone does not know when an account has changed hands.
When does a customer register entry get updated?
Whenever an account fact changes: a new specification is issued, an existing one lapses, an audit takes place, a complaint route is redefined, or the account owner changes. The review date and next-review fields exist to catch drift that nobody happened to notice, but the change itself is what should trigger the update, not the calendar.
Scope
When is a customer register required?
This register holds the customer relationship's controlling facts. It does not hold the specification document itself, the complaint record, or the commercial contract terms in full; those live in their own templates and reference this one.
Use this template when
- A new customer account is being set up and needs a Register ID before other records can reference it
- A customer's specification is issued, renewed, or found to have lapsed and the status needs updating
- A customer audit takes place, or the audit frequency and relationship changes
- A customer-specific requirement beyond the standard specification is identified and needs a documented review
- An account owner changes, or a complaint contact route needs to be defined or corrected
Do not use it for
- Product and SKU Register, which holds the products themselves; this register links to it through Products Supplied rather than describing products here
- Customer Specific Requirement Review, which is the actual review record behind Requirement Review ID, not a substitute for it
- Complaint records, which hold the individual complaint and its investigation, referencing this register for the customer rather than duplicating account detail
- Customer Onboarding Record or Customer Master Data and Terms Setup, which handle the commercial and contractual setup process itself, upstream of this register
- Vendor and Contractor Register, which is the equivalent master data for the organisations that supply you, not the ones you supply
Compliance mapping
Which ISO 9001 cl.8.2 requirements does this satisfy?
Customer requirements are a defined clause in most quality management standards, but the clause requires the determination and review to happen, not this particular record. What makes this register defensible is that it is where the standard's requirement is actually evidenced, continuously, rather than reconstructed at audit time.
| Clause | Requirement | Where it lands |
|---|---|---|
| ISO 9001 cl.8.2.2 | Requirements related to products and services are determined, including statutory, regulatory and customer-specified requirements | Customers |
| ISO 9001 cl.8.2.3 | Requirements are reviewed before commitment to supply, and the organisation has the capability to meet them | Customers |
| ISO 9001 cl.8.2.4 | Changes to product, service or customer requirements are documented and communicated to relevant people | Register health |
| BRCGS Food Safety, cl.3.7 | A documented procedure exists for complaint handling, with complaints investigated and communicated to the relevant customer | Customers |
| ISO 9001 cl.9.1.2 | Customer satisfaction is monitored, including information relevant to customer perception of whether requirements were met | Register health |
| ISO 9001 cl.7.5.3 | Documented information is controlled, kept current, and available where and when it is needed | Header |
| ISO 9001 cl.5.1.2 | Customer focus is demonstrated by ensuring customer requirements are determined, understood and consistently met | Register health |
What it does not cover
- Customer Specific Requirement Review, which is the actual assessment behind a Yes in Specific Requirements Beyond Standard, not a substitute for carrying one out.
- Complaint record, which holds the individual complaint, its investigation and its closure, referencing this register for the customer rather than being replaced by it.
- Specification document, which is the technical document itself; Specification Held and Specification Current describe its status here, they do not store it.
- Customer Onboarding Record and Customer Master Data and Terms Setup, which handle the commercial setup, credit terms and contractual detail that precede this register's ongoing maintenance.
- Traceability record, which links product movements to this customer for recall purposes, and depends on this register's Customer Code being correct rather than reproducing it.
Global
Customer Register requirements by country
The duty to know and review what a customer requires is close to universal in quality management, and food and consumer-goods sectors add complaint-handling and traceability expectations on top of it.
FDA FSMA, 21 CFR Part 117 (food); general contract law elsewhere
Customer requirements are addressed through supply agreements and, in food, preventive controls and recall procedures rather than a single named standard.
Without a maintained register, a recall investigation has no fast route from a product lot to the accounts it reached.
BRCGS Global Standards; ISO 9001
BRCGS schemes require documented complaint procedures and customer communication routes as a named clause, not an implied one.
An auditor asks to see the complaint route for a named customer; 'No' against that field is a direct nonconformity.
ISO 9001; General Food Law Regulation (EC) 178/2002
Traceability one step forward and one step back is a legal requirement in food, resting on accurate customer identification.
Stale codes or lapsed specifications weaken the forward traceability step regulators specifically test.
CFIA Safe Food for Canadians Regulations; ISO 9001
Traceability and complaint response obligations under SFCR depend on the same accurate customer identification.
CFIA inspectors expect a recall simulation to reach affected customers within hours, only possible if the register is current.
FSANZ Food Standards Code; ISO 9001
Recall and traceability obligations under the Code require rapid identification of affected customers and products.
Register drift here directly slows a recall's reach, the metric regulators and customers both measure afterward.
ISO 9001 cl.8.2
Certification audits examine whether customer requirements are determined, reviewed and kept current.
This register is the record most organisations designate, so its currency is what the audit actually tests.
How to complete it
How to complete a customer register, step by step
Filling out a new customer row is straightforward. What determines whether the register still means anything a year later is a set of ongoing calls nobody is prompted to make by the form itself.
Specification Held records a filing fact; Specification Current records a judgement that someone has to actually make, on a cadence, rather than defaulting to Yes because a document exists. Assign that judgement to a named function, usually quality, and require a date against it, or the field degrades into an assumption.
A Yes against Complaint Contact Route Defined should mean a named person on each side knows the path a complaint takes, not that a route exists in principle. Untested routes fail exactly when they are needed, during an actual complaint, which is the worst possible time to discover the named contact left eight months ago.
Customers Without An Owner is a register-health metric for a reason: an unowned account is one where a specification lapse, an audit finding or a complaint has nobody positioned to notice it first. Owner reassignment belongs in the same offboarding step as any other handover, not a later cleanup pass.
Specific Requirements Beyond Standard is easy to mark No by default because auditing every customer's stated expectations against your baseline specification is work. The honest answer requires actually comparing the two, and a register full of confident Nos that were never checked is worse than one with open Requirement Review IDs still being worked through.
What auditors find
Most common customer register findings
Findings against a customer register rarely concern a missing row. They concern a row that was accurate when opened and has since diverged from what is actually true of the account.
| Finding | Clause | What fixes it |
|---|---|---|
| Specification shown as held is, on inspection, a superseded version. | ISO 9001 cl.8.2.3 | Reconcile Specification Current against the customer's actual latest issue on a defined cycle, not only when a complaint prompts it. |
| Complaint Contact Route Defined is marked Yes with no named contact retrievable anywhere. | BRCGS Food Safety, cl.3.7 | Require a named contact and date tested against the Yes, not a standalone flag. |
| Account owner shown against a customer left the organisation months earlier. | ISO 9001 cl.5.1.2 | Reassign Account Owner as a mandatory step in the departing owner's own offboarding. |
| Specific Requirements Beyond Standard is marked No without any comparison against the customer's own stated expectations on file. | ISO 9001 cl.8.2.2 | Evidence the comparison, even briefly, rather than accepting a default No. |
| Products Supplied lists items the customer stopped ordering months or years ago. | ISO 9001 cl.7.5.3 | Reconcile against actual order or despatch history on the same cycle as the specification review. |
| Audit Frequency and Last Audit Date are inconsistent with the customer's actual audit history. | ISO 9001 cl.9.1.2 | Update both fields at the point an audit actually occurs, not on a separate administrative schedule. |
| Action Required is marked Yes with no CAPA ID or owner populated. | ISO 9001 cl.8.2.4 | Raise the corrective action record at the point the gap is identified, and enter its reference immediately. |
| Register health counts (specifications out of date, customers without an owner) are not reviewed by anyone on a defined cycle. | ISO 9001 cl.9.1.2 | Assign the register-health section its own review owner and cadence, separate from individual account maintenance. |
| A new customer account was traded against before a Register ID existed. | ISO 9001 cl.8.2.3 | Require the register entry as a precondition of the first order being accepted, not a follow-up task. |
| Second signature (technical) is missing or dated long after commercial sign-off. | ISO 9001 cl.8.2.3 | Require both signatures at the same review point; a commercial-only sign-off has not reviewed the technical requirement at all. |
Case in point
Case in point: the specification that was on file and wrong
A supplier's customer register showed a retail account with Specification Held: Yes and Specification Current: Yes, last reviewed eleven months earlier. The account had been stable for years, ordering the same product line, and nobody on either side had reason to flag anything. The account owner had moved to a different portfolio eight months prior; a successor had been named informally but never updated in the register.
The customer's own technical team revised the specification, tightening a foreign-body tolerance, and issued it through their supplier portal, a channel the supplier's quality function did not routinely monitor because the relationship had always run through the account owner. With no current owner logged in the register, nobody was positioned to notice the portal update, and the supplier continued producing to the superseded specification for four months until a routine customer audit found the discrepancy.
The register had not been falsified or neglected in any visible way; every field had a plausible-looking answer. What had actually happened was that the one field meant to catch exactly this, Account Owner, had gone stale at the same moment the customer changed something, and the register's own health metrics, which would have flagged an unowned account, were not being reviewed by anyone.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
3 sections
- Reference
- FDN-021
- Archetype
- Register
- Record ID
- CUST-2026-000
- Scoring
- Records complete
- Direction
- High is good
- Singleton
- No
- Basis
- ISO 9001 cl.8.2
- Links
- Feeds Complaints, Traceability, Specifications
- Tags
- Registry, Customer
- Sections
- 3
- Fields
- 34
- Follow up fields
- 3
- Repeating sections
- 1
- Links out
- 4
Header
8 fieldsRegister ID*
Auto sequence. Format CUST-2026-000.
The record's own ID. Other templates point at this value.
Status*
Drives who this goes to next.
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Last Reviewed*
Maintained By*
Next Review Due*
Site*
Site ID*
Format SITE-000.
Links to FDN-001 Site ID
Everything Points Back Here
Complaints, specifications, traceability and audit requirements all reference a customer. Holding them once means a change of requirement updates in one place rather than eight.
Customers
Repeats15 fieldsCustomer Name*
Customer Code
Account Owner*
Market*
Channel
Status*
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Products Supplied
Specification Held*
- Yes, current3 pts
- Yes, out of date1 pt
- No0 pts
Specification Current*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Audits Us*
Audit Frequency
- Yes3 pts
- Partly1 pt
- No0 pts
Last Audit Date
Specific Requirements Beyond Standard*
- No3 pts
- Yes1 pt
Requirement Review ID
Links to QUA-112 Review ID
Complaint Contact Route Defined*
- Yes3 pts
- No0 pts
Register health
11 fieldsCustomers On Register*
Specifications Out Of Date*
Customers Without An Owner*
Action Required*
Raise the action record, then enter its reference here.
- No2 pts
- Yes0 pts
Priority
- High0 pts
- Medium1 pt
- Low3 pts
CAPA ID
Format CAPA-2026-00000.
Links to FDN-014 CAPA ID
Action Owner
Commercial*
Signature*
Technical*
Second Signature*
FDN-021 · record IDs look like CUST-2026-000 · Feeds Complaints, Traceability, Specifications
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The register itself is easy to keep accurate on the day of entry. What actually degrades is the ongoing judgement behind it: the specification nobody re-checks, the owner nobody reassigns, the complaint route nobody tests until it's needed.
Cross-checks Specification Current against actual customer-issued documents and flags accounts where the two have quietly diverged.
Watches Specific Requirements Beyond Standard and the linked requirement review, so a marked No is a checked answer rather than a default one.
Reconciles Products Supplied against actual despatch history, surfacing customer rows that still list products no longer shipped.
Tracks account-owner changes across the organisation and raises Customers Without An Owner the moment a reassignment is missed, rather than waiting for the next register-health review.
This template lives in General — control tower. The orchestration layer. Registries and engines every other workspace reads from.
Meet General→Glossary
Customer Register definitions and key terms
- Register ID
- The stable key, format CUST-2026-000, that other templates, complaints, traceability, specifications, link to rather than reproducing customer detail.
- Specification Held vs Specification Current
- Two distinct claims: whether a specification document is on file at all, and whether the version on file is the one the customer currently expects.
- Complaint Contact Route Defined
- Whether a named path exists for a complaint to reach the account owner and quality together, distinct from and additional to having a specification on file.
- Requirement Review ID
- The link to the Customer Specific Requirement Review record evidencing that a stated requirement beyond the standard specification was actually assessed.
- Register health
- The section tracking counts that describe the register's own state, specifications out of date, unowned customers, rather than any individual account, so drift is visible in aggregate.
- Account Owner
- The commercial contact responsible for a customer relationship; an unowned account is a register-health flag because nobody is positioned to notice the next change.
- Records complete scoring
- The scoring basis for this register: high is good, and the score reflects how completely and currently the fields describing each account are populated.
- One step forward, one step back
- The traceability principle that a supplier must be able to trace product to the immediate customer and from the immediate supplier, which depends on this register's customer identification being accurate.
FAQ
Frequently asked questions about customer register
Is a customer register one record per organisation, or can it hold many?+
Many. Despite how some catalogue entries describe registers, this one holds a row per customer account, repeating indefinitely as accounts are added. It is set up once as a workspace and then grows for as long as the business takes on customers, rather than being closed out and replaced.
What is the practical difference between Specification Held and Specification Current?+
Held answers whether a document exists in the file. Current answers whether that document is the version the customer actually expects today. A customer can score Yes on the first and No on the second, and that combination is a common, real state, not a data error, which is why the two are scored separately.
Does every customer need a complaint contact route defined?+
Yes, and it should be tested rather than assumed. A route existing on paper, with a named contact who has since moved on, fails at the exact moment a complaint needs to travel through it, which is the worst time to discover the gap.
Who signs off a customer register entry, and why two signatures?+
Commercial and technical, separately, because the commercial relationship and the technical requirement are genuinely different questions. A commercial sign-off confirms the account and terms; a technical sign-off confirms the specification and audit posture actually reflect what was reviewed, and one cannot stand in for the other.
What should trigger a review of a customer entry, beyond the review date?+
Any change on the customer's side: a new or reissued specification, an audit result, a change of the customer's own contact, or a complaint that reveals the contact route didn't work. The stated review date is a backstop for changes nobody flagged, not the primary mechanism.
Why does register health track customers without an owner as its own metric?+
Because an unowned account is a monitoring gap that produces no visible symptom until something changes on the customer's side and nobody notices. Tracking the count, rather than waiting for an individual account to fail, is what catches the gap before it does.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Used together in Master Data and Foundations
Site and Location Register
Holds every site, building, area and zone your organisation operates
Asset Register
Holds every piece of equipment, machine, vehicle and tool you track
Worker Profile
Holds a record for each worker, including role, department, site and start date
Job and Task Register
Lists the jobs and tasks people perform, so risk assessments and ergonomic assessments can be tied to real work rather than job titles
Vendor and Contractor Register
Holds every supplier, contractor and service provider you work with, including their status and approval level
Chemical and Substance Register
Lists every chemical and hazardous substance held on site, with quantity, location and hazard class
More in Registries
Site and Location Register
Holds every site, building, area and zone your organisation operates
Asset Register
Holds every piece of equipment, machine, vehicle and tool you track
Worker Profile
Holds a record for each worker, including role, department, site and start date
Job and Task Register
Lists the jobs and tasks people perform, so risk assessments and ergonomic assessments can be tied to real work rather than job titles
Vendor and Contractor Register
Holds every supplier, contractor and service provider you work with, including their status and approval level
Chemical and Substance Register
Lists every chemical and hazardous substance held on site, with quantity, location and hazard class
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- ISO 9001:2015 clauses 8.2.2, 8.2.3, 8.2.4, 9.1.2, 7.5.3 and 5.1.2
- BRCGS Global Standard for Food Safety, clause 3.7, complaint handling
- General Food Law Regulation (EC) 178/2002, traceability requirements (EU)
- FDA FSMA, 21 CFR Part 117, preventive controls for human food (US)
- CFIA Safe Food for Canadians Regulations, traceability provisions
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.