Work orders — pricing extra work

A work order is a piece of work you've agreed with a client that isn't in the original scope — a change request mid-build, the next job on an ongoing account, a favour you're doing for nothing.

It exists because a project could previously express one price for the whole job, but nothing could say "the client rang and asked for SSO, we said £2,400, it's outside the spec".

Two axes, kept separate

Origin — why it exists: Change request, Ad-hoc, or In scope.

Billing — whether you're charging: Billable or Absorbed.

These are deliberately independent. Scope creep you swallow is still scope creep, and folding it into "not billable" is exactly what loses the post-mortem. An absorbed order still records what the work was worth and how long it took, so you can see what you gave away.

Pricing

• Fixed — one number.
• Estimate — a range ("6–8 hours"), which is what people actually say. Storing 7 would throw away the honest part.

Prices can be in money or hours. A work order can also exist unpriced, in scoping — "I need a day of research before I can quote this" is a real state. Once you add a price it moves to proposed automatically.

Every price change writes a revision — what it was, what it became, who changed it and when. What matters at the end is the sequence, not the current number.

Agreeing one

Draft the tasks you intend to do as plain lines on the order. They aren't real tasks yet — deliberately, so unsold work can never appear on a board as though it were scheduled.

When the client says yes, Agree it: pick a phase for each draft and Waymarq creates them as real tasks through the normal machinery — proper references, board positions, audit rows, watchers. Absorbed work has its tasks marked non-billable automatically.

Agreeing is implicit and instant; nothing is sent and no approval is waited on. Agreeing twice is a no-op.

Lifecycle

Scoping → Proposed → Agreed → In progress → Delivered → Billed, or Declined.

A work order becomes ready to bill once it's complete — which is derived from its tasks all being done, not stored as a flag, so it can't disagree with the board.

Promoting to a project

If an "extra" turns out to be a body of work in its own right, promote it to its own project — but only before its drafts have become tasks. Once work is on a board it carries codes, dependencies and logged time belonging to the original project; moving that is a migration, not a button.

Then what

Delivered, billable work orders show up as ready to bill and become lines on a statement.