# Sales Proof Library Template A template for organizing proof across customer, product, operational, market, founder, traction, and third-party categories — with honest limitations, current status, and visible gaps. **Target question:** How do I organize proof for sales and fundraising? **Last updated:** 2026-07-16 Proof used in sales and fundraising conversations tends to live in scattered decks, old emails, and individual memories. This template organizes it into categories with clear fields for source, limitations, and where it can be used — so proof stays traceable, approved, current, and appropriate for the context it is used in. ## What a proof library is A proof library is a maintained set of records for every piece of evidence a company uses to support a claim — in sales conversations, investor updates, or marketing materials. Each entry states what the claim is, where it came from, how confident the company can be in it, and where it is appropriate to use. ## Why ad hoc proof fails Without a shared library, proof lives in individual heads and old slide decks. Reps round numbers up because they cannot remember the exact figure. A founder cites a customer result in an investor update that the sales team has never heard of. A piece of proof that was true six months ago gets repeated after it has quietly become false. - Different team members cite different versions of the same claim. - Proof that was true at one point continues circulating after it stops being accurate. - No one can quickly answer 'where did that number come from?' when asked. ## The seven proof categories **Customer** : Direct evidence from a named or referenceable customer — a quote, a documented outcome, a usage pattern. **Product** : Evidence about what the product actually does, based on its current, shipped capabilities rather than the roadmap. **Operational** : Evidence about how the company runs — response times, delivery process, security or compliance posture. **Market** : Evidence about the market or problem space — sourced research or credible third-party context, not internal assumptions dressed up as fact. **Founder** : Relevant founder background or prior experience directly connected to why this company can execute on this problem. **Traction** : Evidence about company progress — usage, pipeline, retention — stated precisely and without rounding or extrapolation. **Third-party** : Evidence originating outside the company — press, analyst commentary, partner statements — used only when it can be sourced. ## Required fields for each entry - Claim — the exact statement the proof supports, written precisely rather than paraphrased loosely. - Source — where this evidence actually came from, specific enough that someone could verify it. - Current as of — the date this proof was last confirmed accurate. - Confidence — verified, directional, or anecdotal; stated honestly rather than implied. - Where usable — which contexts this proof is appropriate for: sales calls, investor materials, public marketing, or none of these yet. - Status — active, expired, or needs review. ## Limitations and confidence, stated honestly Not all proof carries the same weight, and a proof library should say so rather than presenting everything with equal confidence. A single anecdote from one customer conversation is real evidence, but it is not the same as a pattern confirmed across many customers — and both are different from a claim about product capability that the team can verify directly. **Verified** : Confirmed directly, with a source that could be checked if asked. **Directional** : A reasonable signal, but based on limited data or a small sample. **Anecdotal** : A single instance or observation — useful context, not a pattern. ## Matching proof to context The same piece of proof is not automatically appropriate for every audience. A directional internal observation might be reasonable to mention in an internal sales conversation with proper framing, but inappropriate to state in public marketing without qualification. An investor update has a different bar for precision than a one-line sales talking point. The 'where usable' field exists so this judgment is made once, deliberately, rather than left to whoever is speaking in the moment. ## How to build the library 1. List every claim currently being made in sales calls, investor conversations, and marketing materials. 2. For each claim, identify the actual source — and mark anything that has no traceable source as unsupported rather than approved. 3. Assign a category, a confidence level, and a current-as-of date to each supported claim. 4. Decide where each entry is appropriate to use, and where it is not. 5. Flag categories with no current entries as open gaps rather than leaving the absence unaddressed. 6. Set a review cadence so entries are reconfirmed or retired as the underlying facts change. ## Worked example entry ### Proof library entry - Category: customer, product, operational, market, founder, traction, or third-party? - Claim: the exact statement this proof supports. - Source: where this came from, specifically. - Current as of: when was this last confirmed accurate? - Confidence: verified, directional, or anecdotal? - Where usable: sales, investor, marketing, internal only, or not yet approved for use? - Status: active, expired, or needs review. ## Recognizing expired or weak proof - The underlying product capability has changed since the claim was recorded. - The customer or context the claim came from is no longer representative. - The confidence level was never actually verified, despite being repeated as if it were. - No one on the team can currently explain where the number or claim originated. > **Warning:** When proof is expired or weak, retire or downgrade it rather than letting it keep circulating because it sounds good. ## Identifying gaps instead of filling them with guesses An empty category is useful information — it tells the team exactly where a claim is currently being made without support, or where a category of proof simply does not exist yet. The correct response to a gap is to flag it and, if appropriate, go gather real evidence — not to fill it with an estimate presented as fact. - [ ] Every proof category has at least one current entry, or is explicitly marked as a known gap. - [ ] No sales, marketing, or investor material relies on a claim that has no corresponding library entry. - [ ] Entries flagged 'needs review' are actually reviewed on a set cadence, not indefinitely. ## Traceable, approved, current > **Tip:** Three tests for every entry: can it be traced to a real source, has it been approved for the context it is used in, and is it still current? An entry that fails any one of these should not be in active use. ## Common mistakes - Building the library once and never revisiting it as facts change. - Skipping the confidence field, so anecdotes get treated with the same weight as verified data. - Using investor-only proof in public marketing without checking it is appropriate for that audience. - Rounding numbers up 'because it's close enough' instead of stating the precise, sourced figure. - No process for retiring entries once they stop being accurate. ## Keeping proof consistent across the company TrueCompanyOS helps founders maintain one approved version of this proof so sales, investor, marketing, and team communication do not drift. ## FAQ ### What counts as usable proof for an early-stage company with limited customers? Even a small number of specific, honestly-labeled data points — a single customer's documented outcome, a founder's directly relevant prior experience, or a clearly stated product capability — are usable proof as long as they are precise and truthfully framed as limited rather than presented as broad patterns. ### Should investor proof and sales proof be kept in the same library? They can live in the same library as long as each entry's 'where usable' field distinguishes the contexts it is appropriate for. Keeping them in one place, rather than separate documents, is what prevents contradictory versions of the same claim from circulating to different audiences. ### How do I handle a claim I believe is true but cannot fully source yet? Mark it as directional or anecdotal with an honest confidence level and a note on what would be needed to verify it, rather than either omitting it entirely or presenting it as verified. The confidence field exists specifically so partially-supported claims can still be tracked and used appropriately. ## Related resources - [Sales Objection Handling Framework](https://truecompanyos.com/resources/sales-objection-handling-framework) - [Startup Positioning Framework](https://truecompanyos.com/resources/startup-positioning-framework) - [Startup Sales Readiness Checklist](https://truecompanyos.com/resources/startup-sales-readiness-checklist) --- TrueCompanyOS helps founders maintain approved company truth so sales, investor, marketing, and team communication do not drift. Canonical source: https://truecompanyos.com/resources/sales-proof-library-template