Use past performance in government proposals

Capture evidence, not just project names

For each project, preserve the buyer, dates, scope, contract value where appropriate, team, outcomes, technologies, delivery conditions, reference permissions, and supporting artifacts.

Map similarity honestly

A good reference resembles the target requirement in meaningful ways: buyer environment, scope, scale, risk, users, geography, systems, or delivery model. Explain both the match and any gap.

Prepare for verification

Confirm reference contact details and permission, then align claims with contract records and the people who performed the work. Never invent metrics or imply customer endorsement without support.

Build a project record that survives staff turnover

Create one controlled record for each candidate reference while the underlying evidence is still available. Capture the contracting entity, contract or project identifier when appropriate, period of performance, role as prime or subcontractor, delivered scope, team, delivery conditions, and outcomes that can be supported. Link the record to approved source material rather than relying on one employee's memory.

Distinguish public facts, client-approved statements, internal facts, and confidential material. A proposal team should know which details can be reused, which require renewed permission, and which must stay internal. This avoids both weak generic descriptions and last-minute pressure to disclose information the company is not authorized to share.

• Identify an internal owner for every project record.
• Store the contract, acceptance record, approved case study, or other supporting artifact.
• Record who performed the work and who can validate technical details.
• Date every client-contact and reuse permission check.

Map every proposed claim to supporting evidence

Translate the target solicitation into an evidence map before selecting references. For each evaluated capability, identify the project fact, document, metric, or knowledgeable person that supports it. A reference can be relevant because of similar scope, scale, users, environment, delivery risk, technology, or geography, but the response should explain the actual similarity rather than merely calling a project comparable.

Handle gaps explicitly. If a project supports the service but not the buyer type, or the team has relevant experience that the company itself does not, record that distinction and confirm whether the solicitation permits the evidence. Do not blend multiple projects into a single implied engagement or turn an estimate into a measured outcome.

• Use the buyer's evaluation language to organize the evidence map.
• Keep dates, values, quantities, and outcomes consistent across proposal sections.
• Name the source for every material metric or performance claim.
• Mark unsupported claims for removal, verification, or qualified wording.

Run a reference-readiness check before submission

Contact proposed references through an appropriate company process before listing them when permission or advance notice is needed. Confirm the person's current role, contact information, familiarity with the cited work, and willingness to respond within the buyer's likely review period. Provide a factual reminder of the project without scripting praise or suggesting unsupported statements.

Review the final reference entry against the solicitation's required format and the underlying project record. Confirm that the named entity, dates, scope, and team relationship are accurate. If a reference becomes unavailable, revisit the evaluation requirement and identify a compliant replacement instead of silently substituting a weaker or ineligible contact.

• Verify contact details close to the submission date.
• Confirm the reference can discuss the claims attributed to the project.
• Keep a backup only when it independently meets the buyer's requirements.
• Record the final approved reference version with the proposal file.

Questions

Frequently asked questions