Selling the work
The thing the client owes you is never written down anywhere enforceable.
Access to the environment. The data extract. A decision by the eleventh. A person for three days a week. All of it agreed, all of it in a paragraph headed “client responsibilities”, and none of it with a date or an owner.
Then the project slips, and the conversation about whose fault it is has no evidence on either side.
What it holds
Twenty-one sections, and five of them are lists rather than prose.
The commercial header, thirteen narrative and governance sections as real fields, and five collections: the deliverables, the payment schedule, the team with its rates, the money lines — and the client's own obligations, each with an owner and a deadline.
That last one is the difference between a document and a contract you can actually manage against.
- Payment terms are structured, not prose —
Cadence, net days, a retainer amount, a ceiling for time-and-materials work, and how expenses are billed.
- Numbered under a lock —
Two simultaneous creates serialise rather than colliding.
- Versions are taken before an edit —
So the stored snapshot is the state as it was — and the reason is written down: the version that was signed is the last one taken before the signature. What counts as a material change is computed rather than declared.
- A template library, from your own documents —
Clone a preset, or snapshot a statement of work you have already written into a reusable one.
Before it goes
Three refusals, each naming what is wrong.
At least one milestone. Every milestone date inside the engagement's own window, with the offenders named. And on a fixed price, the billing milestones must equal the total to the penny — with the difference reported, not just the fact of a mismatch.
Two softer checks log rather than block: empty assumptions, and empty client responsibilities. Those are warnings because a document can legitimately not need them; the three above cannot.
- The client signs through a link, and the document is re-hashed —
Rendered and hashed when the invite goes out, then re-rendered and re-hashed at the moment of signing — a mismatch refuses the signature. A document edited after the link went out cannot be signed against terms the client never saw.
- Only a hash of the link is stored —
And a new invite revokes the outstanding ones; signing revokes the rest.
- Countersignature is real, and order-agnostic —
Whichever side signs second completes it.
- A failed send is reported, not swallowed —
The response says whether the invite actually went, so somebody can hand over the link instead of assuming.
- An offline signature is recorded as one —
In the same ledger, marked as captured by hand, so the trail distinguishes it.
›Can it be edited after it is signed?
No. A signed document is superseded by a change, not edited. Void is the only exit before signature, and a converted document refuses to be voided with a message pointing at the project.
›Does the rate card on the document set the project's rates?
Not today — the day rate captured on the team plan is printed and not used to price the work. Rates come from the bookings. Worth knowing when you write the card.
›Can a quote become a statement of work?
The reference is stored and the lines are not imported. Treat them as two documents that know about each other.