Proof library: client results ready before every proposal
A proof library for a service firm: one record per client result, which fields to record, where to start and how to pick proof for a proposal.
How do you stop hunting for client results before every proposal? Build a proof library: record each client result as a separate record, one record per result, not per client. A record holds the situation at the start, what you did, the result before and after, who on the client’s side confirmed it and when, the client’s permissions for the name, a quote and public use, and the project period. Start with your three best past projects. After every win, create an empty record and add the result once the client confirms it. Adopt one rule: only a result with a record and a confirmation goes into a proposal. Pick at most three records closest to the service and the type of client.
In this post I’ll show which fields to record, where to start, when to add results and how to pick them for a proposal.
Client results live in people’s heads, in Slack and in old decks
Before a proposal, someone asks the team: “We had a similar project once. Do you remember what it achieved?” The project manager knows the answer, or it’s in a Slack thread from a year ago, or on a slide in a deck for another client. Nobody knows whether the number is current, whether the client confirmed it or whether you may use their name. In my view, this is exactly how results rounded from memory end up in proposals.
Without recorded results, you can’t write a case study either. In the Content Marketing Institute’s research for 2025 (980 B2B marketers, mostly from North America), 75% of respondents used case studies, and 53% named them among the most effective content types, right after video (58%). So a proof library feeds proposals and case studies at the same time.
One record per result, not per client
A record describes one result for one client. If you did a system migration for a client and, separately, automated their reporting, you create two records. You name the file or row after the result, for example “distributor-month-end-close”.
Before a proposal, you then search by service and problem. The buyer is checking whether you’ve already solved a problem like theirs; the number of clients you’ve served tells them little about that.
Record fields: situation, action, result, confirmation, permissions, period
| Field | What you record |
|---|---|
| Client | the name, or a description without the name that the client approved |
| Service and client type | which service, the client’s industry and size |
| Period | when the project started and ended (for an ongoing retainer: the start date and “ongoing”) |
| Situation at the start | what wasn’t working, in numbers or in words |
| What you did | the scope of work, including what you didn’t do |
| Result | before and after: a number, a range or a description in words that the client approved |
| Confirmation | who on the client’s side confirmed the result (each number separately), when and in what form |
| Permissions | name: yes/no; quote: yes/no; public use: yes/no |
| Reference call | whether the client agreed to talk to a buyer |
| Last updated | when someone last changed or checked the record |
The most important field is “confirmation”. In my view, a result is confirmed only when someone on the client’s side confirms it, ideally by email; after a phone call or a meeting, record who confirmed it and when. The “confirmed” status is set by the person on your team who received that confirmation; no tool sets it automatically. A result you calculated yourselves stays in the record as unconfirmed.
The three permissions are independent of each other. A proposal for a specific client can cite a project even if the client didn’t agree to public use, as long as the confidentiality terms in your contract with them allow it; a case study can’t. If the contract says nothing about it, ask the client. I covered how to ask for permissions in the post on anonymous case studies.
Start with your three best past projects
You don’t have to describe every project right away. Pick three with a result the client noticed, ideally in the services you most want to sell. Three good records will give you more than a folder of thin ones.
For each project, record what you know for certain: the situation, the scope and the period. For numbers, ask the project manager where they come from. If the client hasn’t confirmed them, leave them as unconfirmed, or call the client and ask: “Is this number correct, and may we use it?” You don’t fill in a missing number with an estimate.
You can collect the confirmation and the permissions in one email: “We’re preparing a write-up of the project we worked on together. Is the result [result] correct, and may we refer to it in proposals for other clients? Separately, may we use your company’s name, use the attached quote and publish the description on our website? You can agree to each of these independently.”
After a win, create an empty record and add the result once confirmed
When you win a contract, you create the record right away: client, service, period, situation at the start. You set the permissions to “no” and leave the result field empty, because the project hasn’t produced anything yet.
You add the result once the client confirms it, for example at a quarterly review meeting, when the numbers are on the table anyway. With an ongoing retainer, you come back to the record every quarter. A library full of empty records that nobody revisits stops working, so when you create a record, put the date you’ll come back to it in your calendar.
Only a result with a record and a confirmation goes into a proposal
Every result, number, client name and quote in a proposal must have a record in the library, and the result must be confirmed. If there’s no such record, in the experience section you write what is true: how you work, what experience the team has, which comparable work is publicly available. You don’t describe a result you can’t document.
It’s better to give fewer numbers in a proposal than one you can’t back up. The buyer will quote it back to you in negotiations, and you’ll have to defend it.
Pick at most three records for a proposal
For a proposal, you search the library by service, then by client type, and take at most three of the closest records with a confirmed result. Three results from similar projects are more convincing than eight loosely related ones. Before you write anything, you check the permissions: without permission for the name, you describe the client without it; without permission for a quote, you don’t quote.
Example: a record in a proof library
This is an illustration, not a real project: take a consulting firm that reorganized the month-end close in a distributor’s accounting department.
| Field | Content (illustration) |
|---|---|
| Client | “building materials distributor, 150–250 employees” (description approved by the client) |
| Service and client type | finance consulting; distribution, mid-sized company |
| Period | March–August 2025 |
| Situation at the start | the month-end close dragged on until the middle of the following month |
| What you did | a new close schedule and division of tasks in the accounting department; no change to the accounting system |
| Result | the month-end close finishes in the first week instead of the middle of the following month (described in words, because the client didn’t agree to share numbers) |
| Confirmation | the client’s finance director, email dated 15 September 2025 |
| Permissions | name: no; quote: no; public use: no |
| Reference call | yes, once a time has been arranged with the client |
| Last updated | 15 September 2025 |
This record won’t go into a public case study, because the client didn’t agree to public use. In a proposal for another distributor, it can appear as a description without the name and without a quote, if the contract allows it, and you can offer the buyer a call with the client. The call is a separate permission: before each one, the client decides for themselves whether to talk to that buyer.
Frequently asked questions
A spreadsheet or a folder of files?
Either will do to start; the table in this post gives you the spreadsheet columns. In my view, what matters more than the tool is having one list that the team checks before every proposal.
Who runs the library?
One person, ideally the one who prepares proposals. Project managers provide the situation, scope and numbers, and that person chases confirmations and the dates for returning to empty records.
What about projects from years ago, when there’s nobody left to ask?
The result stays unconfirmed and doesn’t go into a proposal. In a proposal you can describe the project itself: the situation, the scope and the period, without the result.
What if clients don’t want to share numbers?
Record the result in words or as a range the client approved, together with the confirmation. A result like that can go into a proposal too.
Summary
If you search Slack for results before every proposal, start with one list and three records from your best projects, with results confirmed by the client and permissions recorded. After every win, create an empty record with a date to come back to it. In our open repo (files and instructions for an AI agent such as Claude Code), a client result, number, name and quote go into a proposal only from a proof record, and a person marks a number as confirmed (open source).
Every method on this blog also runs as a skill in the open-source B2BForce repo. About the repo