Features · Proposals & contracts · E-signature coming soon
Proposals from the design. Signing coming soon.
The same model that computed the coverage and priced the materials writes the proposal and the agreement. E-signature is coming soon: the signing workflow is built but not switched on yet, so customers cannot sign in the product today. Until then, collect signatures the way you do now.
What signing is built to seal
- BOM revision
- the exact bill of materials, by revision id
- SOW sections
- scope content, hashed section by section
- Orders & change orders
- every form included in the deal
- The total
- the number both sides agreed to
Coming soon. One content hash, sealed at signature time and verifiable afterward. Not live yet.
Documents · from the design record
The proposal writes itself from the project
Proposal and scope documents are generated from the design record — the same surveys, device placements, and bill of materials the engines computed — then assembled into agreements in a builder made for contracts, not slideware.
- A customer-facing design proposal generated from the project — coverage, equipment, and scope from the record, not re-typed into a word processor.
- An agreement builder with reusable templates and sections, plus fields placed on the page — signature, initials, date, text, checkbox, dropdown, radio, attachment.
- Coming soon with e-signature: signing routes in sequential, parallel, or conditional order, with signer, approver, viewer, and CC roles.
- Coming soon with e-signature: a finished PDF with the signatures embedded, plus optional certificate and audit-trail pages. DRAFT/COPY watermarks mark a document before execution.
In the builder
- Templates & sections
- reusable contract structure
- Eight field types
- placed where they belong on the page
- Signing order
- coming soon: sequential, parallel, or conditional
- Four roles
- coming soon: signer, approver, viewer, CC
Bulk send, from a template and a recipient list, arrives with e-signature. It is coming soon and not live yet.
Coming soon · identity verification
Know who signed — with the friction you choose
E-signature is coming soon and is not live yet. As built, each signer gets their own verification level: a customer executive and your own counter-signer do not need the same checks, so the authentication method is set per signer, not per document.
- Signing links are single-use tokens — stored hashed, expiring on schedule, re-issued fresh with every reminder. No account required to sign.
- One-time SMS codes: six digits, a ten-minute window, limited attempts, and a lockout — codes are stored hashed, never in the clear.
- Knowledge-based checks: three questions asked, two correct required, answers stored as hashes, with its own attempt lockout.
- Every signature records what happened around it — verification time, IP address, device, and how the signature was made: drawn, typed, or uploaded.
Per-signer verification
- Email link
- single-use hashed token, expiring
- SMS one-time code
- 6 digits, 10-minute window, lockout
- Knowledge questions
- 3 asked, 2 required, hashed answers
- Recorded context
- timestamp, IP, device, signature type
Coming soon. Verification is chosen per signer: friction where it protects, none where it slows the deal.
Coming soon · reminders & tracking
The deal keeps moving without you pushing it
This arrives with e-signature, which is coming soon. As built, an agreement is a workflow, not a PDF in an outbox: every send, view, fill, and signature lands on the agreement's timeline, and the follow-up runs on a schedule instead of on memory.
- A full status workflow — draft, review, out for signature, partially signed, completed — with declined, expired, and voided as first-class outcomes, including a decline reason.
- Reminders two ways: send one manually, or let the daily check nudge unsigned signers automatically — with per-signer reminder counts on the record.
- A daily expiration sweep closes out stale agreements instead of leaving them open forever.
- Bulk send: one template, a list of recipients, individually tracked agreements with batch progress you can query.
On the timeline
- Sent & viewed
- per signer, with timestamps
- Fields filled
- each entry as it happens
- Signed & countersigned
- the signature chain in order
- Reminders & declines
- every nudge and every no, recorded
Coming soon. The activity log is the agreement's history, not a separate report you assemble.
Coming soon · versions & redlines
Redlines tracked like code, not email attachments
Customer redlines start from the signing page, so they arrive with e-signature, which is coming soon. As built, the negotiation happens in the document — proposed edits, decisions, and versions — instead of in a reply-all thread with five conflicting attachments.
- Section-level redlining: the customer proposes new wording on a narrative section, or a comment on the pricing and scope tables — current and proposed text side by side, attributed to the signer who proposed it.
- Every proposal is resolved explicitly — accepted or rejected, by a named reviewer, with a comment.
- Reopening archives the signed version, applies the accepted edits, and resets signatures — each reopen a new version with a per-section diff you can walk in the agreement’s history.
- Signing always targets the current version, so nobody executes a stale draft.
A redline's life
- 01 Proposed customer, current vs proposed text
- 02 Reviewed accepted or rejected, with a comment
- 03 Reopened prior version archived, accepted edits applied, signatures reset
- 04 Signed execution against the current version
Coming soon. Change history stays on the agreement: visible, attributable, and ordered.
Coming soon · certificate & webhooks
When the last signature lands, the record closes itself
This arrives with e-signature, which is coming soon. As built, completion is automatic: the final PDF regenerates with every signature embedded, a certificate of completion is issued, and the frozen snapshot seals what was signed, while webhooks tell the rest of your stack.
- A certificate of completion with a certificate number, hashes of the original and final documents, and the full signature chain — who signed, when, from where, with a hash per signature.
- The frozen snapshot: the BOM revision, SOW section hash, order forms, change orders, and total, combined into one content hash the platform can reconstruct and verify later.
- As built, platform signatures get a cryptographic seal, and the certificate records which method produced each signature. Signed outside the platform today? Attach the signed change order and the customer PO to the change order record.
- Webhooks for eight agreement events, signed with a per-endpoint secret, with a delivery log and a test trigger — so the handoff to external systems is verifiable, not hopeful.
On the certificate
- Certificate number
- issued when the last signature lands
- Document hashes
- original and final, side by side
- Signature chain
- name, time, IP — hash per signature
- Event webhooks
- eight events, secret-signed payloads
Coming soon. Generated automatically on completion: nothing to remember, nothing to assemble.
One record
The agreement is the design record
Most teams quote in one tool, contract in another, and sign in a third, and the three drift. Here the proposal and the agreement are written from the design. E-signature is coming soon; once it is live, the signed record seals the design's exact revision and points back at the model that produced it.
SOW, BOM & estimating
The scope and materials an agreement is built from, derived from the design, not re-keyed.
Learn more
Project lifecycle
The design record the proposal is written from, requirements to as-built.
Learn more
Where the CRM overlaps
How the revenue plane on the design record compares with a PSA.
Learn more
Frequently asked questions
Can my customers sign agreements in the platform today?
Not yet. E-signature is coming soon. The signing workflow on this page is built, but it is not switched on for any plan, so a customer cannot sign in the product today. Until it is live, build the proposal and the agreement here and collect the signature the way you do now.
Will my customers need an account to sign?
No. Signing is built around a single-use link for each signer: the token is stored hashed, expires on schedule, and is re-issued with every reminder. On top of the link you can require a one-time SMS code or knowledge questions per signer, and each signature records its timestamp, IP, and device. This is part of e-signature, which is coming soon and is not live yet.
What does a completed agreement seal?
A frozen snapshot of what was signed: the exact bill-of-materials revision, a hash of the statement-of-work sections, the order forms and change orders included, and the total, combined into one content hash the platform can reconstruct and verify later. The seal is written when the last signature lands, so it arrives with e-signature, which is coming soon and is not live yet.
Can the customer propose changes instead of declining?
That is how signing is built. From the signing page the customer proposes changes instead of declining: suggested wording on any narrative section, or a comment on the pricing and scope tables (those stay comment-only, so accepting a change can never move the priced total). A named reviewer accepts or rejects each proposal with a comment, and reopening archives the prior version, applies the accepted edits and resets signatures. The signing page is part of e-signature, which is coming soon and is not live yet.
Can other systems react when an agreement completes?
Agreement webhooks are built for eight events (created, sent, viewed, signed, completed, declined, expired, voided), with payloads signed by a per-endpoint secret and a delivery log with a test trigger. The signing events only fire once e-signature is live, and it is coming soon, not live yet.
Send the proposal the design already wrote
Bring a project. We will walk from scored design to proposal and agreement without re-keying a line. E-signature is coming soon. Talk to us about what your team needs.