Features · Proposals, contracts & e-signature
From design to signature, one unbroken record.
The same model that computed the coverage and priced the materials writes the proposal — and when the agreement is signed, it seals a content hash of the exact design it was signed against. Nothing re-keyed into a signature tool; no drift between what was quoted and what was signed.
What the signature seals
- 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
One content hash, sealed at signature time — reconstructable and verifiable afterward.
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.
- Signing routes that match how deals actually close: sequential, parallel, or conditional order, with signer, approver, viewer, and CC roles.
- A finished PDF with the signatures embedded — plus optional certificate and audit-trail pages, and DRAFT/COPY watermarks before execution.
In the builder
- Templates & sections
- reusable contract structure
- Eight field types
- placed where they belong on the page
- Signing order
- sequential, parallel, or conditional
- Four roles
- signer, approver, viewer, CC
Bulk send runs the same flow from a template and a recipient list, with progress tracking.
Signing · identity verification
Know who signed — with the friction you choose
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
Verification is chosen per signer — friction where it protects, none where it slows the deal.
Lifecycle · reminders & tracking
The deal keeps moving without you pushing it
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
The activity log is the agreement's history — not a separate report you assemble.
Negotiation · versions & redlines
Redlines tracked like code, not email attachments
When the other side wants changes, the negotiation happens in the document — proposed edits, decisions, and versions — instead of in a reply-all thread with five conflicting attachments.
- Track-changes redlining: insertions, deletions, and replacements with the original and proposed text side by side, flagged by who proposed them — including customer-proposed edits.
- Every redline is resolved explicitly — accepted or rejected, by a named reviewer, with a comment.
- Each change produces a new version with a per-section diff — added, removed, modified — and a version history you can walk.
- Signing always targets the current version, so nobody executes a stale draft.
A redline's life
- 01 Proposed either side, original vs proposed text
- 02 Reviewed accepted or rejected, with a comment
- 03 Versioned new version, per-section diff recorded
- 04 Signed execution against the current version
Change history stays on the agreement — visible, attributable, and ordered.
Completion · certificate & webhooks
When the last signature lands, the record closes itself
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.
- Sealing is honest about its strength — platform signatures get a cryptographic seal; an uploaded PDF is labeled best-effort rather than silently claimed as proven.
- 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
Generated automatically on completion — nothing to remember, nothing to assemble.
One record
The agreement is the design record, sealed
Most teams quote in one tool, contract in another, and sign in a third — and the three drift. Here the proposal is written from the design, the agreement seals the design's exact revision, and the signed record points back at the model that produced it.
SOW, BOM & estimating
The scope and materials the agreement seals — 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
Do my customers need an account to sign?
No. Each signer gets a single-use signing link — the token is stored hashed, expires on schedule, and is re-issued fresh with every reminder. On top of the link you can require a one-time SMS code or knowledge questions per signer, and every signature records its timestamp, IP, and device.
What exactly 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 that the platform can deterministically reconstruct and verify later.
What about agreements signed outside the platform?
An uploaded PDF or an external signing record is stored and sealed too — but its seal is labeled best-effort, not cryptographic, because the platform can prove what was uploaded, not what was signed. That distinction is shown honestly instead of silently claiming provenance it does not have.
Can the customer propose changes instead of declining?
Yes. With negotiation enabled, either side proposes redlines — insertions, deletions, replacements — with the original and proposed text side by side. Each redline is accepted or rejected with a reviewer and comment, and every change lands as a new tracked version with a per-section diff.
Can other systems react when an agreement completes?
Yes. Register webhook endpoints per organization for eight agreement events — created, sent, viewed, signed, completed, declined, expired, voided. Payloads are signed with a per-endpoint secret, and a delivery log with a test trigger makes the integration verifiable.
Send the proposal the design already wrote
Bring a project — we will walk from scored design to sealed signature without re-keying a line. Talk to us about what your team needs.