How to Prepare a Proof Packet a Customer Can Accept
Why this matters
The request always arrives with a deadline attached. A commercial customer's procurement team wants your credentials before they will issue the purchase order, a general contractor will not let your crew on site without a prequalification file, or a homeowner's insurer wants to know who performed the work before they pay a claim. The shop that can answer in a day wins work the shop that needs a week does not, and the difference between them is almost never diligence. It is whether somebody assembled the packet before it was asked for.
A proof packet is also where shops accidentally hand over things they should not. Knowing what to leave out is as much of this skill as knowing what to include.
Step 1: Identify the audience, because they are protecting against different things
Four audiences, four different fears, four different subsets:
| Audience | What they are protecting against | What they actually need |
|---|---|---|
| Homeowner | Hiring someone unlicensed or uninsured | License status, insurance certificate, entity name matching the contract |
| General contractor or prime | Their own liability and their prime contract obligations | License, insurance with the endorsements their contract requires, bond, safety record, workers compensation |
| Commercial procurement | Vendor risk and audit trail | Everything above plus entity good standing, tax documentation, and named individual credentials |
| Inspector or authority | Whether the work was performed under valid authority | License of record, permit, and the credential of the individual who performed the gated act |
Sending a general contractor's packet to a homeowner is not thoroughness, it is confusion, and it invites questions about documents that were never relevant. Sending a homeowner's packet to procurement gets you a second request and a lost week.
Step 2: Build the master set once
Assemble the superset in one place, each item current, each item captured at its source:
- Entity license, with a dated capture of the authority's own lookup showing status, class, and expiry
- Individual credentials for anyone who performs gated work, same treatment
- Certificate of insurance for general liability, and auto and workers compensation where relevant
- The specific policy endorsements a contract commonly asks for, as separate pages
- Surety bond confirmation from the surety, in the form the requesting party accepts
- Entity good-standing evidence from the business registry
- Local business registrations for the jurisdictions where you work
- Federal or program certifications your scopes require
- The completed tax identification form the customer's accounts payable will ask for
Build this once and the subsets are a matter of selection rather than of chasing.
Step 3: Cut the audience subset, and cut it down
Include what the request names plus what the audience obviously needs, and stop. A packet with twelve documents where six were asked for reads as either padding or as carelessness with your own information. Where the request is vague, ask what the packet is for; procurement will tell you, and the answer usually removes items rather than adding them.
Step 4: Apply a freshness rule so nothing goes out stale
Stale documents are the most common reason a packet gets bounced, and the bounce costs more than the refresh would have.
- Certificate of insurance: issued within the last 30 days for any general contractor or procurement request. Homeowners rarely care about the date, contractors always do.
- License lookup capture: pulled within the last 14 days. It costs minutes and it is the item a reviewer is most likely to independently re-check.
- Good standing evidence: within the current filing period.
- The whole packet: re-cut every 90 days while a prequalification is active, and immediately whenever any item's status changes.
Those intervals are starting points to tune to your customers' requirements, but commit to numbers rather than to "recent." A packet with no freshness rule ages into a document that quietly misrepresents you.
Step 5: Redact before it leaves the building
Four things that should not go out in a proof packet:
- Personal identifiers of employees. Social security numbers, home addresses, dates of birth, driver license numbers. A credential verification does not require any of them, and a request for them should be questioned rather than fulfilled.
- Complete insurance policies. A certificate plus the specific endorsement pages answers every legitimate version of the question.
- Anything about a matter under dispute. Send status, not history you were not asked for.
- Other customers' information, which slips in through sample documents and reference letters more often than anyone expects.
Step 6: Push back on the three requests that deserve it
"Send us the full policy." Offer the certificate plus the specific endorsements. Complete policies contain your limits, your loss history hooks, and your other operations, and almost no reviewer actually reads them.
"Add us as additional insured and waive subrogation." These are real, common, negotiable contract terms and not paperwork. They change your coverage, they may require an endorsement your carrier has to issue, and agreeing on a form before your broker has seen it can leave you promising something the policy does not deliver. Route it to the broker, then answer.
"Send us employee credential files." Send what the individuals hold and their status. Personnel files are not proof of qualification and are not theirs to review.
Push back in one short paragraph offering the alternative, not with a refusal. Almost every request of this kind is a template somebody inherited, and the substitution is accepted more often than it is challenged.
Step 7: Deliver as one indexed, versioned file
One file, with a cover index listing each item, its issue date, and its expiry. Name the file with your entity name and the date. Every item in the same order as the customer's request list, so a reviewer can tick their own list without hunting.
The index is what makes a packet feel professional and, more usefully, it is what makes a missing item visible to you before it is visible to them.
Step 8: Log what you sent and to whom
Record the recipient, the date, the version, and the expiry of the shortest-lived item in it. That last field is the one that matters: when the earliest item expires, the packet in that customer's hands has gone stale, and proactively sending a refreshed one is a small move that reads as competence.
A prequalification with nine items and one bad request
A general contractor's prequalification portal listed nine required items with a submission deadline eight business days out.
Six came straight from the master set the same morning: entity license capture, two individual credential captures, good standing evidence, local business registration, and the tax identification form.
Two required issuance. The contract demanded a specific additional insured endorsement the shop did not already carry for that project type, which the broker issued in three business days, and a bond confirmation in the contractor's own form, which the surety returned in five business days.
One was the bad request: a complete copy of the general liability policy. The shop replied the same day offering the certificate plus the endorsement pages covering the terms the contract actually specified. The contractor's risk reviewer accepted the substitution in two business days without comment, which is the usual outcome.
Six plus two plus one accounts for all nine. The packet shipped on business day five, gated entirely by the bond confirmation, which was the slowest item and the one the shop started last because it looked like the easiest. That is the sequencing lesson: start the items that other people have to issue on day one, and assemble your own material while you wait.
Worth noting what the eight-day deadline hid. Only two of the nine items had any lead time at all, so a shop with a maintained master set could have shipped in five days regardless of when it started. A shop without one would have spent the first three days pulling license captures and hunting for the registration, and would have started the bond on day four, which lands on day nine and misses.
Verifying the packet before you send it
Does the entity name match everywhere? License, insurance certificate, registration, and the contract must all name the same legal entity. A trade name on one document and the registered entity on another is the single most common reason a packet gets bounced, and it looks worse than it is.
Is anything in it expired or expiring inside the job? Check every expiry against the last day of the work, not against today.
Would you be comfortable if this file were forwarded? It will be. Packets get emailed onward, uploaded to portals, and stored for years. Anything you would not want in a stranger's inbox should not have gone in.
Does the index match the contents? An index listing an item that is not in the file is worse than no index, because it tells a reviewer you did not read your own submission.
References
- The state or local licensing board's public lookup, as the source for dated license status captures
- Your insurance broker and surety, for certificates, endorsements, and bond confirmations in the requesting party's required form
- The secretary of state or equivalent registry, for entity good standing evidence
- See related: The Credential Proof Packet SOP; The Certificate of Insurance a Customer or GC Asks For; Why You Need a Certificate of Insurance From Every Sub