Preserve Rejected Proposals Without Reusing Old Terms

A rejected proposal can still be useful evidence. It shows which scope was discussed, what the buyer declined and why a later version changed. The problem is not retaining it. The problem is leaving it in a place where someone can mistake it for the current offer.

Use a proposal version register to separate historical preservation from active use. The register should make one question easy to answer: which exact document, if any, is currently authorized for the next commercial conversation?

Give versions identities and meanings

A file name containing “final” is not a reliable status system. Assign a stable proposal ID and a distinct version identifier. Record who prepared each version, its scope, its approval state and its relationship to the previous version. Keep “approved for issue,” “issued,” “rejected,” “superseded” and “accepted” separate. They describe different events.

W3C's PROV overview describes provenance through the entities, activities and people involved in producing information. The practical register below applies that general idea editorially; it is not a required PROV implementation or a document-management product specification.

Completed register for proposal P-31

This fictional example concerns an offer to redesign an internal reporting handoff. All organizations, dates and commercial details are illustrative.

• P-31 v1, 7 October: Scope: discovery plus implementation across three teams. Status: issued, then rejected by the buyer on 9 October because the proposed scope was broader than requested. Historical file retained read-only under the team's normal retention policy. Not authorized for current use.

• P-31 v2, 12 October: Scope: discovery for one team, with implementation excluded. Status: approved for issue by commercial owner Lea and issued to buyer coordinator Jo on 13 October. Buyer response pending. This is the current issued offer, not an accepted agreement.

• P-31 v3, 15 October: Scope: v2 plus an optional second workshop. Status: internal draft, awaiting delivery review. Prepared by account owner Arun. It does not replace v2 merely because it has the highest version number.

• Current-version pointer: P-31 v2. Basis: latest version approved and issued for the current conversation. Verified by Lea on 15 October against the issue record and unchanged document contents.

• Historical relationship: v2 replaces the rejected three-team proposal for current discussion. v3 is a proposed revision of v2. No version is marked accepted.

• Known stale reference: Internal opportunity summary still links to v1. Correction owner Arun must replace that active reference with v2 and label v1 as historical in the version register.

Check the places where old terms escape

Review the opportunity's proposal link, shared decision note, handoff packet and any unsent message attachments. Opening the main folder is not enough; a colleague may work from a copied URL or an old email attachment. Make the document's version and status visible within the document where your editing and retention process permits.

Do not silently overwrite the bytes behind an already-issued version identifier. That can make it impossible to establish what someone actually received. Create a new version and preserve the relationship. If an active shared link resolves to changing content, record that behavior and use an appropriately controlled issue copy for material terms.

In the example, Arun corrects the internal opportunity link to v2 and withdraws an unsent message containing v1. No message is sent automatically. If someone already received misleading current-version guidance, the account owner prepares an authorized clarification that identifies the superseded document without suggesting that the recipient has accepted the replacement.

Handle the tempting exception

Suppose the buyer asks to revisit v1's three-team scope. Do not reactivate it by changing a status label. Its staffing assumptions or pricing may no longer be valid. Use it as a historical reference, obtain the relevant reviews and issue a newly identified proposal if appropriate.

The buyer-champion support guide emphasizes material a buyer can use without your narration. Version control serves the same practical need: the reader should recognize the current proposal and its limits without guessing which “final” attachment your team meant.