Key takeaways
- Assign a proposal ID and version; do not let filenames, inbox order, or “final-final” identify the offer.
- Separate reusable claims from deal-specific scope, pricing, assumptions, approvals, and expiry.
- Preserve a comparison between the approved, sent, redlined, and signed versions.
- Make the signed artifact and its commitments available to delivery without copying private documents into every system.
01
The wrong PDF can be beautifully on brand
A seller changes a timeline after finance approves the discount. A colleague sends the earlier attachment from email. The buyer signs a version that nobody recognizes as current, and the CRM still links to an editable document. Every screen looks polished; the commercial record is broken.
Create a durable proposal ID, version, opportunity, customer legal entity, offer owner, currency, pricing basis, scope, assumptions, exclusions, delivery dates, evidence-backed claims, approvers, approval time, validity window, and artifact hash or immutable reference.
Swipe to compare every column
| Artifact | State | Rule |
|---|---|---|
| Working draft | Editable and incomplete | Never customer-ready by default |
| Approved version | Commercial and claim review complete | Changes create a new version |
| Sent version | Exact artifact delivered to buyer | Record recipient and time |
| Redline | Buyer or legal changes visible | Preserve lineage and owner |
| Signed version | Authoritative accepted artifact | Immutable and linked to delivery |
02
Make approval match the thing being approved
Finance may own price and payment terms, legal may own deviations, security may own security representations, product may own capability, and delivery may own feasibility. Approval is not a generic green check. Tie each approval to the relevant fields and version so a later edit cannot inherit authority it never received.
Set thresholds for discounts, custom work, liability, data terms, service levels, start dates, and non-standard claims. Let low-risk standard proposals move quickly; route the exceptions to named people with the context needed to decide.
03
Show the buyer what changed
Generate a human-readable comparison for material changes: price, term, scope, dependencies, timetable, acceptance, and exclusions. Cosmetic reflow should not bury a commercial change. Record who requested it, who approved it, and why.
W3C’s provenance model is useful beyond data science: a proposal is an entity produced by activities and people. Preserving that lineage lets operations assess which version is trustworthy instead of reconstructing history from timestamps and attachment names.
04
Hand over the commitments, not just the document
The signed proposal may contain sensitive commercial detail, so control access. Extract an implementation brief containing the commitments delivery must act on, linked back to the authoritative clause or section. Keep customer-approved scope distinct from internal selling notes.
Measure superseded versions sent, post-approval edits, unsigned work starting, expired proposals accepted, manual corrections, and implementation disputes caused by proposal mismatch. The purpose of version control is not cleaner storage. It is one shared understanding of what was offered and accepted.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
