Create the Proof and Referral Loop

Completed work becomes commercially useful only when it can be described truthfully to another buyer. Proof does not mean a polished success story. It means evidence that a defined problem existed, a defined process was delivered, and a defined result was accepted, with limits and permission made clear.

Referrals work the same way. A useful referral is not "tell people about me." It identifies a situation where the referrer can credibly introduce you, the role of the person who may need help, and the next step that respects that person's decision.

Build both loops as part of delivery. Waiting until a month later makes permission, specifics, and the buyer's memory harder to recover.

Define What Counts as Proof

Different forms answer different buyer questions:

• Delivered output sample: Can I see the form and standard? The sample may not show how the work was produced or approved.
• Accepted checklist: Was the promised result completed? Acceptance does not prove a financial outcome.
• Client testimonial: What did this buyer value? One opinion is not a universal result.
• Before and after comparison: What changed? The comparison may have other causes.
• Process walkthrough: Can this provider explain the work? An explanation is not independent verification.
• Referral conversation: Who trusts this provider? The new person still decides independently.

A strong proof library usually combines a sample, an acceptance record, and a clearly attributed statement. None alone proves that a similar buyer will receive the same result.

Ask for Permission Before Using the Work

The service agreement should establish what can be shared and for what purpose. Even when a contract allows disclosure, ask the buyer before publishing:

• What may be shown.
• Whether names, logos, files, or quotations may appear.
• Whether the material must be anonymized.
• Where it may be used.
• For how long.
• How permission can be withdrawn.

Keep a consent record with the exact approved version. If the buyer declines, use a generic process example, a synthetic sample, or no sample. Do not assume that removing a logo makes a client unidentifiable, especially in a narrow market.

Build a Proof Record at Delivery

Collect facts before the engagement closes:

• Buyer segment and situation, described without unnecessary personal data.
• Approved problem statement.
• Scope and quantity delivered.
• Delivery dates and acceptance date.
• Checks performed.
• Buyer-reported benefit, clearly labeled as their report.
• Measured process result, if the data is reliable.
• Limitations and what the result does not prove.
• Approved sample or redacted artifact.
• Permission and expiration details.
• Referral introduction path.

For example:

> A workshop operator needed a repeatable way to turn one approved transcript into follow-up drafts. The pilot produced twelve source-checked drafts and a human-review record within the agreed delivery window. The coordinator accepted the files after one included correction round. The operator reported that the workflow made review responsibilities clearer. The pilot did not measure response, attendance, or revenue.

This statement is useful because it names what happened and what remains unknown.

Make Claims Match the Evidence

Use separate language for:

• Delivered: What you produced and handed over.
• Accepted: What the buyer confirmed under the agreed checks.
• Measured: What the available record shows.
• Reported: What a person said they experienced.
• Attributed: What a buyer agreed to say publicly.

Do not combine them into "increased sales by 30 percent" unless the data and attribution support that statement. Do not claim that AI caused an outcome when several factors changed. Do not present a single engagement as a typical result.

Strong proof can sound modest:

> Delivered 12 drafts and an approval record for one workshop cycle. The buyer accepted the agreed files after one correction round.

A careful buyer may trust that more than a dramatic, unsupported transformation.

Turn the Acceptance Record Into a Case Note

A concise case note can have six sections:

1. Situation: Who had what recurring job?
2. Constraint: Why was the existing process difficult?
3. Scope: What bounded result was purchased?
4. Delivery: What was produced and checked?
5. Evidence: What was accepted or measured?
6. Limits: What does the example not show?

Keep the note short enough to be read. Link to a fuller sample only when permission allows. State the engagement date because tools, offers, and processes change.

Do not expose a buyer's internal failures merely to make your work look impressive. Explain the constraint at the level needed to understand the service.

Ask for a Specific Testimonial

Generic requests produce generic answers. Ask after a successful acceptance or at another natural review point:

> Would you be willing to provide a short statement about the part of the pilot that was most useful? These questions may help: What was difficult before the pilot? Which part of the delivered process did you trust? What should another buyer understand about the scope or limits?

Offer a deadline and format. Make clear that the buyer can decline and can review the final quotation.

If the buyer provides a statement, confirm:

• Exact wording.
• Name, role, and company attribution.
• Approved channels.
• Any date limit.
• Permission to edit for length without changing meaning.

Do not rewrite a weak testimonial into a stronger claim the buyer did not make.

Turn a Referral Into a Specific Ask

"Do you know anyone who needs this?" requires the buyer to remember your offer, diagnose another person's problem, and compose a recommendation. Make it easier while preserving the referrer's judgment:

> The pilot seemed closest to event teams that already approve transcripts and have a recurring follow-up deadline. If you know one coordinator with that exact problem, would you be comfortable making an introduction? I can send a two-sentence note you can edit or decline.

The referrer can now recognize the fit and choose whether to act.

A referral message should state:

• Who is making the introduction.
• Why the connection may be relevant.
• One bounded problem.
• That the new person is free to ignore it.
• One low-pressure next step.

Do not ask a client to reveal another person's private data. Do not send repeated reminders to the referrer. Do not treat an introduction as a warm lead that owes you a meeting.

Use Reciprocity Carefully

Referrals do not require a commission or manipulative incentive. The primary exchange is useful attention between people who may solve a problem. If you offer a commercial referral arrangement, check the applicable rules and make the arrangement clear where required.

Do not reward someone for disclosing confidential information or making an endorsement they do not believe. Trust is the asset. A small short-term sale is not worth damaging it.

Build a Lightweight Proof Library

Keep a controlled index:

• Proof identifier.
• Buyer segment.
• Scope and delivery date.
• Accepted result.
• Evidence type.
• Approved public version.
• Permission owner and expiry.
• Sensitive details to exclude.
• Related offer version.
• Review date.

Use one source of truth rather than copying old claims into social posts and proposals. When permission changes or a claim expires, mark the item unavailable.

Create a Referral Loop From Every Good Outcome

A good delivery can create several types of next step:

• A repeat paid cycle with the same buyer.
• A referral to a similar role in another organization.
• A permissioned public case note.
• A testimonial about the process.
• A request for feedback on why a buyer declined.

Not every engagement should produce all five. Choose the steps that fit the relationship and the evidence.

Close the loop by telling the referrer what happened at a level that respects the new person's privacy. "The conversation was useful and they will decide internally" is enough. Do not disclose the prospect's budget, objections, or data.

A Worked Proof and Referral Loop

The following is an illustrative composite. It is not a promise of referrals or revenue.

Nina finishes the workshop pilot. The coordinator accepted the twelve drafts after one correction. The owner says the process was clearer than the manual workflow.

Nina sends a permission request with a short case note that uses no attendee names and no quoted transcript content. The owner and coordinator approve the case note. The coordinator adds:

> The source-note sheet made it much easier to see which claims needed checking before the messages went out.

Nina confirms that quotation and attribution. She keeps the full source sheet private. In the proof library, she records the delivery date, accepted result, permission, and the limitation that no response or revenue outcome was measured.

During the acceptance call, the coordinator mentions a partner organization that runs a similar event series. Nina asks:

> If the partner's event team already has a transcript approval step and a recurring follow-up deadline, would you be comfortable introducing me to the person who coordinates it? I can send a short note that explains the exact pilot and leaves the decision with them.

The coordinator agrees to send the note. Nina does not ask for the partner's contact database or send a direct campaign to unnamed people. She prepares a short introduction using only the information the coordinator chose to share.

The partner asks for the public case note and a twenty-minute diagnostic call. Nina sends both and connects the request back to the original offer. The new organization decides not to proceed because its data policy excludes external drafting. Nina records "fit, data policy" and asks whether a future redaction-only workflow might be relevant. The referral relationship remains intact because the no is handled cleanly.

Review Proof Before Sharing

Ask:

• Is the buyer identifiable despite anonymization?
• Does the note reveal confidential process or data?
• Is each result delivered, accepted, measured, or reported?
• Does the timeframe and scope appear?
• Is the limitation visible?
• Is the public version the approved version?
• Is permission current?
• Would the buyer recognize the description as fair?

A peer who did not deliver the work can catch overclaims and accidental identifiers.

Privacy in Proof and Outreach

Personal data can appear in a sample file, testimonial, screenshot, metadata field, folder name, invoice, or AI transcript. Redact the actual source, not only the visible paragraph. Check screenshots at full resolution and remove hidden comments or file properties when relevant.

If AI helps draft a case note or referral message, give it only approved, minimized information. Verify names, quotations, outcome numbers, consent, and claims against the proof record. Do not paste a private client message into an AI tool to make the testimonial sound better.

Your Chapter Exercise

Using one completed or simulated engagement:

1. Write a six-section case note.
2. Label each statement as delivered, accepted, measured, reported, or attributed.
3. List the limitations.
4. Create a permission request.
5. Draft one specific testimonial question set.
6. Build a proof-library row.
7. Identify one similar role for a referral.
8. Write a referral ask that leaves the decision open.
9. Draft a two-sentence introduction.
10. Ask a peer to find any overclaim or hidden identifier.

Chapter Deliverable

Create a proof and referral kit containing:

• Approved case-note template.
• Claim-labeling checklist.
• Permission request and consent record.
• Specific testimonial questions.
• Public and private proof index.
• Referral fit definition.
• Referral ask and introduction draft.
• Decline and do-not-contact handling.
• Redaction checklist.
• Review and expiration process.

Source and Decision Caution

Publicity, testimonial, referral incentive, endorsement, marketing, and privacy requirements vary by jurisdiction and contract. This chapter is not legal advice. Confirm permission and current rules before publishing a case study, quotation, logo, or incentive arrangement.

AI can fabricate a quotation, combine facts from different clients, or make an anonymized example identifiable. Verify every public claim against the proof record and approved sources. Keep consent records and private samples in controlled locations, and remove them when permission or retention requirements change.

The next chapter turns the repeatable parts of the working delivery into checklists and templates without pretending that every judgment can be automated.