
A purchase order confirms a transaction, not every later design decision.
Technical review, cost acceptance and formal instruction are separate acts.
The named approver must have authority for the consequence being accepted.
The manufacturer confirms the proposed product configuration and factory information.
Every accepted change needs one current document set and a superseded trail.
No changed work should proceed from an informal or ambiguous approval.
On a hypothetical resort project, the team orders a group of outdoor saunas, then asks for a different control before production. Procurement accepts the extra cost in an email. The architect assumes the email also accepts the revised interface, while the electrician is still reviewing it. The factory now has a commercial yes, an open technical question and two document versions that look current.
The person who can approve your sauna change after procurement depends on the consequence being accepted and the authority granted by the project. Product feasibility, project design, cost, programme and formal instruction may belong to different named parties. The manufacturer can confirm its selected configuration and revised factory information, but cannot assume client authority or the appointed designer's project-specific responsibility. Release the change for the affected work only when the required reviews, approvals and current documents agree.
Procurement creates the commitments written into the order and related documents. It doesn't automatically give the buyer's contact authority to redesign the project, accept every technical consequence or instruct work outside the agreed route. Read the appointment, contract and change procedure instead of guessing from a job title.
For building work in England, current Building Safety Regulator guidance describes separate client, designer and contractor duties and competence expectations. That is an England-specific regulatory example. It isn't universal sauna law, a European approval hierarchy or legal advice for your project.
The practical lesson travels more widely than the jurisdictional example. Name the decision being requested, then match it to the party appointed to make it. A procurement manager may accept a price. That commercial acceptance doesn't prove that an altered opening, service or control arrangement has been technically reviewed.
My manufacturer judgement is that an order should freeze a reference configuration, not freeze honest technical discussion. A late proposal can still be useful. It becomes safe to act on only after the right people have reviewed its consequences and one authorised instruction replaces the earlier baseline.

The ledger keeps commercial acceptance separate from technical, design and instruction authority. A completed cost decision cannot turn an open technical review into PASS.
Keep four questions visible: whether the product can be supplied, whether the revised design works, who accepts the consequences and who issues the instruction. One person may hold several authorities, but the record should still show each decision separately.
Decision | Typical evidence | Authority to name |
|---|---|---|
Product feasibility | Selected configuration and factory information | Manufacturer for its supplied product |
Project design | Revised interfaces and discipline review | Appointed competent designer |
Cost and programme | Quoted effect and accepted consequence | Client-side commercial authority |
Instruction | One numbered change and current document set | Party authorised by the project procedure |
Commercial acceptance isn't technical acceptance.
A proposal isn't an instruction.
Name the decision before naming the approver.
One accepted change needs one current document set.
These lines are short because the distinction must survive email, meetings, site pressure and later handovers.
The trade-off is speed versus separation. A single informal yes feels efficient, while four recorded decisions can look slow. The better shortcut is a compact authority chain with parallel reviews. It keeps the decisions distinct without turning every modest change into a committee.
Use one change record with four fields: proposer, affected consequences, required authority and superseded document set. Add the proposed wording, linked evidence, named reviewers, decision date and release status. If a field isn't relevant, record why instead of leaving a silent blank.
Compare the current proposal against the purchased baseline, not against memory. Our companion article How Should a European Hotel Compare Two Outdoor Sauna Quotes? helps teams normalise scope before purchase. The same discipline makes a post-order difference visible rather than letting it hide inside revised attachments.
Ask “Who Can Approve Your Sauna Change After Procurement?” before naming the approver.
Decision: “Approve change [change reference] for the revised configuration, accepted cost and current drawings listed below.” The record must identify every required reviewer, the named project authority and the earlier documents that no longer control.

The instruction shows the four components needed to release changed work. With technical review or formal instruction open, the overall result remains HOLD.
Approval should change the controlled baseline. Mark the new document status, identify superseded files, distribute the instruction to every affected party and confirm receipt. The manufacturer updates only the product and factory information within its scope. Project designers and installers update their own controlled information.
A hypothetical hotel approved a control upgrade because the price and delivery date were acceptable. Production used the revised selection, while the site team retained an earlier connection drawing. Nothing failed in the email chain. The failure was allowing two different baselines to remain active after the decision.
In that hypothetical, the team recovers by reopening the change, naming the technical reviewers and issuing one document index. The manufacturer reconfirms the selected factory configuration. The appointed electrical designer resolves the project connection information. The client-side authority then accepts the clarified cost and programme effect.
STOP: don't release changed work when authority is unnamed, a technical review is open, the instruction is ambiguous or the current documents are unknown. Procurement urgency doesn't close those gaps.
Only if the project's appointments and change procedure give that person every relevant authority, which should be explicit rather than assumed. Cost acceptance may sit with procurement while technical design and formal instruction sit elsewhere. Record each required decision even when one person legitimately makes more than one.
No. Manufacturer confirmation can cover the selected product configuration, manufacturability and factory information within the supply scope. It doesn't approve local electrical design, foundations, fire strategy, permission or completed installation. Those decisions remain with the competent parties appointed for the project and jurisdiction.
It can only do so when the project's authorised procedure allows that format and the email clearly contains the required decision. The safer test is practical: can every affected party identify the change, authority, evidence, status and superseded documents without reading an informal conversation differently?
Keep the cost decision conditional and don't release changed work until the technical review is complete. If the review changes scope, reopen the commercial decision. Parallel review can save time, but a fast price acceptance shouldn't be presented as acceptance of unknown technical consequences.
The project's named authorities approve the consequences within their granted scope. The manufacturer confirms its product and factory information, appointed designers review project-specific design, commercial authority accepts cost or programme effects, and the authorised party issues the instruction. If any required authority is unclear, stop and clarify it.
Written by
Follow Giedrius to see new posts in your feed, on your phone or by email.
More from
Giedrius Patlaba →When Does Your Sauna Change Need a New Technical Review?
Key Takeaways A new technical review starts when a change invalidates an accepted assumption. Product, safety, service and physical-interface changes deserve explicit trigger tests. The reviewer should match the affected discipline, not the loudest job title. The manufacturer…
How Should Your Team Review a Proposed Sauna Substitution?
Key Takeaways A substitute should be compared with the selected product against explicit project requirements. Review declared performance, function, interfaces, appearance, documentation and commercial effect separately. Record every difference, including an improvement that…
How Should Sauna Drawings Be Checked Against the Final Order?
Key Takeaways Compare the final order and the current drawings line by line before production release. Match identifiers, dimensions, orientation, openings, finishes, components and interfaces. Give each discrepancy one owner, disposition and resulting document revision. A…