Project governance
How to Approve Bespoke Works Without Disputes
Learn how to approve bespoke works using clear criteria, evidence and recorded decisions, while keeping scope, authority and acceptance traceable.

A bespoke oak reception desk arrives on site. It looks finished. The client says the colour is warmer than expected, the contractor says the sample was approved, and the joinery workshop has an invoice due.
Someone says, “Sent you the photos on WhatsApp mate.”
Someone else says, “That’s not what we agreed.”
This is precisely where knowing how to approve bespoke works matters.
Approval is not simply a courtesy email or a signature at the end of a programme. On high-value custom work, it is a commercial decision: a recorded confirmation that defined work has met defined requirements, or a clear challenge explaining why it has not.
Done properly, it protects the client from paying for work that falls short and protects the delivery team from completed work being left in limbo.
How to approve bespoke works: begin before manufacture
The final approval is only as reliable as the agreement that came before it.
Bespoke work cannot be assessed fairly against a vague instruction such as “high-quality bronze finish” or “match the existing panelling”. Those phrases may express an intention, but they do not give a project team a dependable basis for acceptance.
Before procurement, manufacture or installation begins, turn the agreed scope into acceptance criteria.
This does not mean trying to write a specification for every possible imperfection. It means identifying the things that will determine whether the work is accepted.
For a specialist joinery package, that may include the approved drawings and revision number, timber species and finish sample, ironmongery, dimensions and tolerances, interfaces with surrounding finishes, operating requirements, installation sequence and snagging standard.
For fabricated metalwork, it may include material grade, weld finish, coating system, shop drawings, setting-out information and visible-face requirements.
The standard should be proportionate to the risk. A concealed bracket and a hand-finished feature staircase do not need the same approval process. But both need clarity about what was agreed, who has authority to approve it and what evidence will be required.
If the client wants a subjective outcome — “warm”, “quiet”, “premium”, “in keeping with the original” — translate it into something that can be reviewed.
A physical sample, signed-off mock-up, reference image, agreed viewing distance or site inspection can all help.
Subjective judgement is not the problem. Unrecorded subjective judgement is.
Set milestones that match real project decisions
A single approval at practical completion is often too late. By then, the cost of correcting a misunderstanding may be substantial and the relationship may already be under strain.
Break the work into meaningful decision points.
For many bespoke packages, these are design approval, material or finish approval, pre-manufacture release, factory inspection where appropriate, delivery, installation, snag completion and final acceptance.
Each milestone should state:
- what is being approved;
- who has authority to decide;
- what evidence is required;
- when the decision is required; and
- what happens if the work is challenged.
This is not bureaucracy for its own sake.
It prevents a changed drawing being treated as approval to proceed, or a site conversation being mistaken for a commercial instruction. It also gives clients visibility before irreversible work has started.
A useful milestone records three things: the agreed requirement, the evidence expected and the decision required.
For example, pre-manufacture release might require the latest approved shop drawings, finish sample reference, interface confirmation and any agreed variation before the workshop commits labour and materials.
That protects both sides.
The contractor is not manufacturing against a superseded drawing. The client is not asked to accept a finished item they did not have a fair opportunity to review earlier.
Submit evidence, not assurances
“Completed as discussed” is not evidence.
Neither is a photograph with no date, location or connection to the approved scope.
Evidence should allow an authorised person to understand what was delivered and compare it with what was agreed.
Depending on the work, this could include dated photographs, marked-up drawings, delivery notes, test results, inspection records, sample references, commissioning information, manufacturer data or records of rectification.
The evidence needs context.
A close-up photograph of a veneer panel may show finish quality, but not whether it is installed in the correct location. A delivery note may show items arrived, but not whether they were undamaged or compliant.
The strongest record connects the evidence to the relevant milestone, scope item and acceptance criterion.
This is particularly important where work will later be covered up.
Services behind ceilings, substrates beneath flooring, fixings within wall linings and structural alterations may be impossible to inspect once subsequent trades have progressed.
Agree the evidence requirement before the work is concealed, not when someone later asks for proof.
It is also important to distinguish evidence of completion from evidence of acceptance.
A contractor can show that work was carried out. The client or authorised representative still needs to decide whether it meets the agreed requirements.
Keeping those actions separate avoids the common confusion between:
“We have done it.”
and
“You have accepted it.”
Make the decision explicit: accept or challenge
A sound approval workflow should make the governed decision explicit.
Where the evidence demonstrates that the agreed requirements have been met, the authorised party can accept the milestone.
Where they have not been met — or where the evidence is insufficient — the milestone can be challenged with a clear basis.
A challenge should identify the requirement in question, the observed issue, supporting evidence, the person raising it and the response required.
“Not happy with this” may be an honest reaction, but it is not a workable project instruction.
If the issue is a mismatch between the approved sample and installed finish, record that. If it is damage, incomplete adjustment, poor alignment or missing documentation, record that instead.
The same discipline applies to the delivery team.
A challenge is not automatically a defect or an admission of responsibility. It may reveal an unclear interface, a late client change, an incorrect drawing issue or an expectation that was never included in the agreed scope.
The record should establish the facts before anyone decides what remedy is appropriate.
Minor outstanding actions should also be recorded clearly rather than buried inside an ambiguous approval.
Define the action, its owner, the evidence required to close it and, where appropriate, its due date. This keeps outstanding work visible without confusing it with the underlying acceptance decision.
Keep variations separate from acceptance
One of the most expensive errors in bespoke projects is allowing a scope change to travel through an approval process unnoticed.
A client may approve a revised aesthetic direction without realising manufacture has already begun. A contractor may treat a site instruction as authority to proceed, only to find that cost and time consequences were never accepted.
When something changes, record:
- what changed;
- why it changed;
- who requested it;
- the effect on cost;
- the effect on programme;
- any change to the acceptance criteria; and
- whether authority to proceed has been given.
If immediate action is necessary to protect the works or maintain the programme, record that urgency and the limited instruction that was actually given.
Do not use final acceptance to settle an unresolved variation.
Acceptance answers whether the delivered work meets the relevant agreed scope.
A variation answers whether the scope itself changed and on what terms.
They are related, but they are not the same decision.
Make approval part of payment readiness
Payment disputes often begin much earlier than the invoice.
They begin when a team cannot show what was agreed, what changed, what has been delivered and whether the right person accepted it.
A payment application should therefore be capable of pointing back to the governed project record: the relevant milestone, evidence submission, decision history, outstanding challenges and any agreed actions.
This does not mean that every project requires payment to wait for every minor snag.
It means the parties can see what has been accepted, what remains open and what commercial decision is being requested.
Bespea is being built around this discipline.
It creates a shared governance record around milestones, evidence, approvals, challenges and changes, designed to sit alongside existing drawings, email and project-management tools rather than replacing them.
Its Decision Passport and Proof Packs are designed to preserve the history behind important project decisions, so authorised parties can review what happened later instead of reconstructing it from fragmented messages, photographs and documents.
Bespea is not escrow, a payment processor or legal advice. It does not decide who is right.
The principle is simpler:
make important project decisions attributable, evidenced and provable.
Give the right people authority to decide
Many approval failures are actually authority failures.
The site manager may confirm that an item can be installed, while the designer believes they are approving appearance and the client assumes a quantity surveyor is dealing with cost.
Later, each person has a different account of what their message meant.
Set approval roles at the start.
Identify who can approve design, materials, variations, installation quality and commercial progression. Identify who may comment but cannot bind the project commercially.
If authority changes, record that change rather than relying on assumption.
Access to a project is not the same thing as authority to make a decision.
And participation in a project should not automatically mean permission to approve every consequence.
The aim is not to slow decisions down.
It is to prevent the wrong decision being treated as final.
A quick, attributable approval is far more useful than a long email chain in which nobody can tell who had authority or which drawing they were responding to.
The best time to make approval clear is when the work is still straightforward to correct.
Set the criteria. Ask for the evidence. Confirm the authority. Record the decision. Deal with challenges while the facts are still visible.
That is how a bespoke project stays commercially intelligible long before anyone has to argue about it.