Skip to main content
Log inGet started

Agreeing the job · Guide · For builders

Do not rely on one ambiguous click

An accepted project should give you a dependable baseline. It should not create false confidence.

If the customer clicks ‘Accept project’ but the screen never explained the scope, price basis, legal package, funding state or start conditions, the record may prove that a click occurred without proving the shared meaning you need.

Propose a complete package

Before sending the plan, check:

  • correct contracting business and customer parties;
  • project address;
  • complete scope and exclusions;
  • fixed and variable price basis;
  • assumptions and allowances;
  • milestone amounts and criteria;
  • drawings and specification versions;
  • customer decisions and deadlines;
  • responsibilities;
  • payment structure;
  • applicable project rules, contract and notices.

Acceptance cannot repair information that was absent or contradictory when presented.

Treat the button as the final sentence

The words immediately above the action should explain its effect.

The customer should not need to infer whether clicking:

  • confirms receipt;
  • accepts the project baseline;
  • enters a payment obligation;
  • requests work to start;
  • authorises an order;
  • funds a stage.

If several consequences genuinely occur, name them clearly. If they are separate, give them separate actions.

Do not accept conditions in comments

If the customer writes “approved if...” or “accepted except...”, do not rely on the approval state.

Return the package for revision. Incorporate the agreed clarification and obtain acceptance of the new exact version.

The accepted plan should be the agreement, not an agreement plus a chain of side messages needed to understand it.

Confirm the person can bind the party

Your customer contact may not be the only contracting customer. Your estimator may not be authorised to accept on behalf of your company.

Record:

  • required project parties;
  • authorised actor;
  • represented party;
  • scope of authority;
  • exact version accepted.

Do not treat login access, site attendance or an email address as complete authority evidence.

Acceptance is not funding

Do not commit labour, subcontractors or major procurement because the plan says accepted if the relevant funding or order authority is still outstanding.

Use visible states:

  • project accepted;
  • first milestone funding required;
  • procurement decision required;
  • start prerequisites incomplete;
  • ready to start.

That protects cashflow without misrepresenting the customer's commitment.

Keep early-start consent separate

Where a consumer cancellation period applies, a request to begin during it needs approved wording and evidence. Do not bury it inside project acceptance or assume attendance on site is enough.

Preserve the version history

After acceptance:

  • do not overwrite the baseline;
  • propose a variation or amendment;
  • show price and programme consequences;
  • obtain the required acceptance;
  • preserve the old and new versions.

That protects you from scope creep and protects the customer from silent rewriting.

Assurr boundary

Assurr currently freezes the proposed plan hash and records each required party's decision. One change request reopens revision and the accepted version remains immutable through the ordinary service path.

The complete live-money contract product and consumer-notice package is not yet fully pinned. Until it is, do not represent plan acceptance alone as completing every legal and payment condition.

General guidance, not legal advice
Was this useful?

In the same moment

Related terms