What does client approval actually authorize?
Client approval authorizes a specific decision on a specific basis. Accepting a visible finish does not necessarily approve technical suitability, price, or purchasing. State what the confirmation covers, what remains open, and what may happen next so someone outside the meeting can act without guessing.
Identify the decision in plain language. “Client accepts the visible finish in sample A” is more useful than “lighting approved.” It also makes the limit of the approval visible to someone who did not attend the discussion.
A record can link to the relevant drawing, schedule, sample, or proposal. It should not imply that a photograph or verbal preference settles every technical and commercial question.
What belongs in a client approval record?
Record the decision requested, exact item and version, scope of approval, authorized decision maker, confirmation source and date, and next action. Link any superseded decision. The NATA Approval Record below is a working structure for keeping that context together, rather than a substitute for the project’s governing agreement.
| Field | Why it belongs in the record |
|---|---|
| Decision requested | Names what someone is being asked to confirm |
| Item and version | Identifies the exact reference under review |
| Scope of approval | States what is covered and what remains open |
| Decision maker | Records the person authorized for this decision |
| Evidence and date | Links to the confirmation without rewriting its meaning |
| Next action and owner | Makes clear what may happen now |
| Superseded decision | Preserves the connection when something changes |
Limit access to the people who need the information and retain the record within the company’s approved systems. Convenience does not require copying every customer conversation into a new shared file.
Which approval statuses should a design team distinguish?
Distinguish a pending review, preferred selection, approval for specification, authorization for purchase, and a superseded decision when those states lead to different actions. Use labels the team understands and agree what each permits. A short, reliable status list is more useful than many labels nobody can explain.
Does approval of a finish also approve a replacement fixture?
Approval of a finish does not by itself approve a replacement’s dimensions, price, performance, or suitability. A changed fixture needs a record of the new item and the decision now requested. In this illustrative example, a brass-finish selection remains useful history while the replacement is reviewed on its own basis.
The earlier finish preference does not automatically approve the replacement’s dimensions, price, or performance. The change needs a new record identifying the replacement and the decision now requested. The previous selection remains linked so the team can explain the progression.
Before purchasing, the responsible person confirms which approvals the company requires and whether they apply to this version. The record prevents a historical preference from becoming an unintended purchasing instruction.
Where should the current approval status be visible?
Make the governing decision accessible from the schedule or project record used for the next action. Link its evidence and applicable version. A complete record in a forgotten folder cannot help the person placing an order, even when everyone believes the approval has been documented.
Nielsen Norman Group’s usability heuristics include visibility of system status. Applying that principle here means exposing the decision state at the moment someone needs to act, rather than requiring them to reconstruct it from messages.
This does not require a new software platform. A disciplined shared register may be sufficient. The tool becomes inadequate when its actual limits prevent people from keeping decisions reliable and accessible.
How do you check that approval records are working?
Take a small set of decisions and ask someone outside the original conversation to identify the governing version, unresolved questions, and permitted next action. Investigate mismatches between the record and the team’s understanding. The test is whether people can act correctly when a selection changes, not merely whether a status field is filled.
The aim is not to eliminate change. Design develops, availability changes, and clients reconsider. A good approval record lets those changes happen without making their consequences invisible.
Frequently asked questions
Does every selection change need a new software tool?
No. A shared register may be enough if people can identify the current decision, its evidence, and the next action. Consider another tool when the existing arrangement cannot maintain that reliability in actual work.
What should happen when a client changes their mind?
Keep the previous decision linked as history, identify the changed item and version, and make the new decision and its consequences explicit. Do not overwrite the earlier confirmation as though it never existed.
Can a message count as evidence of approval?
A message can be recorded as evidence of what was said. Whether it provides the authority required for the next action depends on the project’s agreed process and governing terms; the register should not expand its meaning.
Sources and case basis
This guide presents a working method, not measured client results. Examples are illustrative unless explicitly attributed. Sources linked in the text support the stated principle or published example; they do not validate the NATA worksheet as an assessed instrument. Prepared and revised November 4, 2026.