Assigning a crew to a project creates a pending assignment. The crew lead sees the brief — project, customer, address, building type, phases, dates, what the crew stands to earn — and signs with a typed name plus a drawn signature, which flips the assignment to active. Declining records reasons instead.
Also called: crew signs for the job · sub agreement · crew lead signature · project acceptance
The crew signs for the job before the job starts
Assigning a crew creates a pending assignment. The crew leader reviews the brief and either signs — typed name plus a drawn signature — which makes the assignment active, or declines with reasons on the record. A crew that walks off a build halfway through agreed to nothing you can put in front of anybody, and that is the situation this exists to end.
Your agreement, in your words, versioned
You write the crew agreement text yourself. Editing saves a new version and retires the previous one rather than overwriting it, because every signature points at the version that was signed and that history has to stay readable. Tokens fill in the project, the customer, the date and the labour amount from the approved estimate at signing time.
They see the job and what they earn — never the customer's total
The brief carries the project, customer, address, building type, phases, dates and what the crew stands to be paid. The only money it renders is the crew's own. Pay is transparent to the men doing the work; your margin is not, and neither is what the customer agreed to.
The signed record is frozen the moment it is signed
The signature stores the fully rendered agreement text with its tokens already filled, a snapshot of the project as it stood, the signer's details, the IP address and the user agent — and no write path edits it afterwards. Change the template next month and what somebody signed last month still reads exactly as it did.
A refusal becomes a record instead of a phone call nobody logged
A crew declining picks from sixteen reasons — pay against scope, schedule conflict, too many jobs back to back, site prep not ready, scope outside their skill set, concerns about the client — with room for detail. The same crew turning work down for the same reason three times is a pattern worth being able to see.
- 1createInitialAssignment inserts a project_crew_assignments row in status pending when the project starts.
- 2The crew lead opens it from Team, the project modal, or the emailed deep link.
- 3Signing snapshots the rendered agreement body, the signer, the drawn signature, the project state, IP and user agent, then flips the assignment to active with accepted_at.
- 4Declining marks the row declined with a reason, and the project needs a new crew.
- 5Every state transition appends a row; nothing is updated in place once an assignment is ended.
A crew that walks off a job halfway through leaves the builder holding a promised date and nobody to hit it, and a verbal yes from a crew lead is worth nothing at that point. Every crew assignment is a document the lead signs before the work starts: a personal commitment to the job, responsibility for the men under his direction, reporting, safety compliance, and a clause requiring any incoming lead to sign the same agreement before taking over. Nothing is edited in place — each change of state adds a record and signatures are permanent — so months later there is still a defensible answer to who agreed to what.
- Crew commitments existing only as a verbal understanding.
- No record of who accepted a job or on what terms.
- Reassignments with no handoff paperwork.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →