Guides Running the job Feature
Quote, scope, variation, claim — all one record
How the accepted quote becomes the agreed scope, variations get approved by a link and a typed name, and a progress claim freezes exactly what it reported.

Ask a civil contractor where the money leaks and almost nobody says "our rates are too low". They say: the extra work we did in week three that never made it onto a claim, and the argument at the end about whether it was in scope.
That leak lives in the gap between four documents that are usually four separate places: the quote, the agreed scope, the variations, and the claim. Here they are one record.
The lead is the job
There is no moment where a won opportunity gets re-typed into a project. The lead you were chasing becomes the job. It keeps the accepted quote, and it gains a scope of work, its variations, its progress claims and its contract. Winning it creates the site automatically.
This matters because every re-entry point is a place for the numbers to drift. Quote a job at one set of rates, retype it into a project tool at another, and by the third variation nobody can say what was actually agreed.
How does an accepted quote become the agreed scope?
A quote is one live document with a frozen revision for each send. The client opens a share link, reads it, and types their name to accept — no account, no login, no printing and scanning. You get an acceptance receipt.
Accepting it moves the lead's stage, comments the record, and creates the site. Then one action imports the quote into the scope of work: each line's description, quantity, unit and rate becomes a scope line. Re-importing is safe — it only adds lines that are not already there.
How are variations approved?
A variation is scope added or changed after the contract. It starts as a draft you price, then goes to the client for approval.
They get a one-time link, valid for 14 days. They see exactly what changed — the quantity, the rate, the value — and type their name to approve or decline, with a comment. That typed name is their written approval, and it lands on the variation with who decided and when.
Two deliberate details:
Only variations get sent this way. Agreed scope is not re-approved; it was agreed when the quote was accepted. Sending the whole scope back for re-approval is how a simple variation turns into a renegotiation.
Rejections are kept. With the client's comment attached. The record of what they declined, and why, is worth as much as the record of what they approved.
Work counts towards a line
Put a scope line on an assignment or an offer, and every operation recorded through it counts against that contract line. Progress becomes a comparison of what was done against what was planned, and it appears on the contract without anyone maintaining a spreadsheet.
One rule sits underneath, and it is the one that prevents the argument at the end: work is never attributed to a line the client has not approved. If it is not in the scope or in an approved variation, it does not quietly accumulate against the contract.
The claim, and what it deliberately is not
A progress claim answers one question: of the scope you agreed plus the variations you approved, this much has been done, and this is what it is worth.
You can see what the next claim would say before you issue it. Issuing it freezes the lines it reported, so editing the scope later can never rewrite a claim that already went out. Out comes a PDF.
Now the boundary, stated plainly because finding out later is expensive:
The app does not invoice, does not take payments, and keeps no accounting ledger. There is no invoice number, no tax breakdown, no payment status and no balance anywhere in this model. Claims are stored so the next claim can subtract what earlier ones reported. The figures go into whatever you already use for accounting.
That is a real limitation and some businesses should choose a different tool because of it. What you get in exchange is that the claim is built from work actually recorded on site, against scope the client actually approved — rather than from someone's memory on the last Friday of the month.
The chain, end to end
- Lead comes in, quote goes out, client accepts by typing their name.
- Lead becomes the job; the site is created.
- Quote lines import as the scope of work.
- Crew, shifts and operations are planned against scope lines.
- Extra work becomes a variation, approved by link.
- Recorded work rolls up against approved lines.
- Claim reports the difference and freezes it.
Seven steps, one record, no retyping.
Start with one job
Run your next won job through it from quote to first claim. That is the only way to tell whether the model fits the way you contract.
Free up to ten licences, where a licence is one active team member or one active site. Sign in with Google, Microsoft or Apple at app.sitesai.net, or see Running a small civil crew from one app.
Questions people ask
Does this invoice my client?
No. The app produces the claim report and the figures go into your accounting system. There is no invoice number, no tax breakdown and no payment status anywhere in the model, by design.
What happens to a rejected variation?
It is kept, with the client's comment and the name they typed. Contract records are never deleted. A line that already has work recorded against it is voided rather than removed.
Can I edit the scope after issuing a claim?
You can edit the scope, and it will not change a claim that has gone out. Issuing a claim freezes the lines it reported, so history stays fixed while the contract moves on.
How does the client approve a variation?
They get a one-time link that lasts 14 days. They see what changed, the quantity, the rate and the value, and type their name to approve or decline. That typed name lands on the variation with the date and their comment.
Run the job from one app — free up to 10 licences.
Leads, jobs, shifts, dockets, inductions and SOP flows for a small civil crew, on web, iOS and Android. What the SitesAI App does.