Customers
Proposals
The same engine employment contracts run on — clauses, merge fields, a signature, an executed copy on file.
A proposal is a document assembled from reviewed clauses, rendered in one or more languages, sent for signature, and filed once it comes back executed. That is precisely what an employment contract is, so it runs on precisely the same engine.
One renderer, not two
The template model, the clause pairing across languages, the page-break rules, the HTML and PDF output and the signing client are all shared. A second renderer would eventually disagree with the first about a page break, about an unresolved merge field, or about which language sits in which column — and the disagreement would first show up in a document a client had already signed.
Templates are kept apart from contract templates
Proposal templates live on their own settings page. Same editor, same clause model, different vocabulary of document types and merge fields.
| Contract templates offer | Proposal templates offer |
|---|---|
| Employment contract, fixed-term, contractor | Proposal, statement of work, master services agreement |
| Offer letter, probation confirmation, amendment | NDA |
| Merge fields from an engagement and a pay record | Merge fields from a deal, a company and a contact |
| Scoped to a legal entity | Issued by the organisation, so no entity |
Nobody issues a client a probation confirmation, and nobody employs somebody on a statement of work. Keeping the lists apart is also what stops a sales document reaching the contract generator: a contract template's id typed into the proposal editor is a not-found, not the wrong form.
Merge fields available
| Field | Fills with |
|---|---|
clientName | The company as everybody calls them |
clientLegalName | The registered name where it differs |
clientAddress | Their address on one line |
contactName, contactJobTitle | The person signing |
proposalTitle, reference | The proposal's own title and your reference |
amount | The price, formatted from integer minor units |
validUntil | How long the price is held |
ourName, preparedBy, today | Your organisation, the author, the date |
An unresolved field is left visible as {{field}} in a preview, which is the point — an obvious placeholder gets noticed, a silent blank where the price should be gets signed. Sending refuses outright while any field is unfilled, and names them.
There are no priced line items
A quote with lines, tax rates and totals is invoicing's job. The deal carries the value and the proposal renders it.
Why
Two pricing engines is how two systems come to disagree about what a client owes, and the disagreement is discovered by the client. Splitting it here means there is one place a price is calculated when invoicing arrives, rather than one that has to be reconciled with this.
The state is worked out, not stored
| It reads as | When |
|---|---|
| Draft | Not sent. Editable and deletable |
| Sent | Out for signature |
| Opened | The client has looked at it |
| Accepted | Signed, or somebody recorded the answer |
| Declined | They said no, with the reason |
| Price lapsed | Past the date the price was held to. Nobody said no |
| Revised | A later version replaces it |
A lapsed price is not a loss
It is shown in amber, described in words, and counted as still open — because the right response is to re-issue it, and colouring it like a loss is how people stop doing that. An accepted proposal that ran past its validity date reads as accepted: the date was a promise about the price, not a deadline for the answer, and reporting otherwise would have the product contradicting a deal you have already won.
Revising keeps both versions
Once a proposal has gone out it cannot be edited. Revising creates a new one chained to the old, and both stay on the record.
Editing something already sent would make this record and the copy the client is holding disagree, with nothing on screen to say so. The validity date is deliberately not carried into the revision — it was a promise about the old price.
Evidence, not status
The panel leads with whether a signed copy is actually on file, and — where somebody outside demanded a hand-signed original — whether the copy on file is a hand-signed one.
Marked as signed is not the same as signed
A proposal flagged as needing a wet signature, with nothing hand-signed on file, is exactly the state discovered when a client asks what they agreed to. The check reads the documents rather than the flag, and says plainly that it is not satisfied.
A proposal signed on paper, or one that predates the system, is uploaded here as an executed copy with no template and no envelope. It needs nobody to re-sign anything.
Sending
- 1
Preview
Rendered from the same builder the envelope uses, so what you print for a wet signature and what the client signs cannot drift.
- 2
Send for signature
Generates the PDF, files it, and raises the envelope in your own DocuSign account. The button is absent with the reason beside it when it cannot work — a button that fails on press teaches people the feature is broken.
- 3
The answer comes back
Envelope status is polled every fifteen minutes. A completed envelope files the signed copy and records acceptance — unless somebody already recorded a decision by hand, in which case the contradiction is left visible rather than silently resolved.
Most proposals are answered on a call or in a reply rather than by countersigning a PDF, so the answer can be recorded directly. A decline asks why and refuses without it; an acceptance asks nothing. Recording either does not move the deal — an accepted proposal on a deal with three others outstanding is not a won deal, and that is not a decision this screen gets to make.
Not built yet
Proposal templates have no sample clauses and never will have — clause text is the one part of this product where a plausible-looking default could do real legal harm. There is also no e-signature of our own: signing goes through DocuSign configured per tenant, and a proposal can always be printed and signed by hand instead.