Sales referral email: a clear paragraph to share

“Know anyone who needs this?” leaves the connector to write the pitch and decide whose name it uses. Give them a short request and a separate paragraph they can evaluate.

The packet produces a request and an exact forwardable description for fictional handbook editor Drew. The builder inserts only a sender-supplied contact, keeps Morgan out of the endorsement wording, and labels unresolved contact or version review clearly. It sends nothing and records no real permission.

Sales referral email: a clear paragraph to share
Sales referral email: a clear paragraph to share
Open the full example ↗

Work through the example

The baseline blurb says Drew helps small teams clarify instructions in their own draft. Enter drew@example.com as an illustrative contact and Build paragraph to replace the visible placeholder. The status still says wording review pending. Select Revise description to inspect a stronger guarantee claim; the page flags the change for fresh support and review rather than carrying any earlier approval across.

Keep the forwardable paragraph separate from internal version notes and the request to Morgan. Permission to share wording does not establish endorsement. Record any actual name-use or joint-introduction agreement in its own field, and treat changed wording as a new review version. A supplied contact makes the draft more concrete but does not establish that it was approved, forwarded or read.

This original example uses fictional handbook editor Drew and fictional connector Morgan. No real contact, customer outcome, permission, forwarding event, or reply has been recorded. Confirm Drew's service description and contact before using the paragraph.

Ask the connector for one manageable action

Drew wants a person who is considering a handbook discussion to have a way to learn more. Morgan knows Drew, but the example gives no evidence that Morgan endorses Drew's work or knows an interested recipient.

HubSpot's referral introduction section illustrates messages passed through a third party. That handoff is the relevant context here; we are not adopting its sample endorsements or response-rate claims. HubSpot's referral introduction templates.

Write the request to Morgan, not to an imagined buyer. Ask whether sharing the specific description would be comfortable. Give Morgan a clear way to decline without supplying someone else's private contact information.

R1: the introduction request

Subject: Could you pass along a handbook-editing introduction?

Hi Morgan,

Would you be comfortable passing the short description below to someone who chooses to learn more about handbook editing?

I have kept it brief so you can share the wording without writing a pitch. Please use only the version we approve, and do not add an endorsement or use your name as a recommendation unless we separately agree on that wording.

You do not need to send me anyone's private contact details. If no one comes to mind, or you would rather not share it, that is fine.

If a joint introduction would be useful, we can check the proposed wording and each person's willingness to be introduced first.

Thanks, Drew

This fictional request asks about a possible handoff. It does not say Morgan has already agreed, someone is waiting for a call, or a meeting has been booked.

B1: the forwardable description

Blurb ID: B1
Author version: 1
Approval date: [TO CONFIRM]
Actual wording approval: [TO CONFIRM]

I am Drew, a handbook editor. I help small teams clarify instructions in their own draft. If you would like to discuss your handbook, you can contact me at [SENDER-SUPPLIED CONTACT].

That paragraph is the exact fictional B1 text for review. It explains a service and provides a possible next step without invented results, customer names, prices, availability, or an implied recommendation from Morgan. Confirm the sender's actual service description and supplied contact before operational use.

Keep the metadata outside the forwardable paragraph. Morgan should not have to guess which sentence belongs to the message and which is an internal approval note. The contact placeholder is unresolved; it is not a functioning address.

Approval attaches to the exact version. If Drew changes “clarify instructions” to “guarantee error-free handbooks,” B1's earlier wording approval cannot be carried over. Treat the change as a new version needing fresh review, including whether the new claim is supportable.

Recreate this example

Build one self-contained responsive HTML example titled “Sales referral email: a clear paragraph to share” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.

Fictional Drew is a handbook editor; Morgan a connector. Show complete R1 request asking whether Morgan would be comfortable passing the exact approved description, with an easy decline and no private-contact demand. B1 exact description: I am Drew, a handbook editor. I help small teams clarify instructions in their own draft. If you would like to discuss your handbook, you can contact me at [SENDER-SUPPLIED CONTACT]. Labeled contact input and Build paragraph replace only contact. Blank retains placeholder. Revise description changes clarify instructions to guarantee error-free handbooks and flags unsupported stronger claim/new version. No approval, endorsement, forwarding or interest is inferred.

Use a correspondence drafting desk with complete message copy and separate internal review status design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.

Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.

Fictional drafting controls do not send mail or establish permission, forwarding or recipient interest. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.

Review the prepared copy in NOS

Give the connector the exact paragraph and the option to decline. For an HTML review of R1 and B1, NOS can display the packet and support visual changes to eligible static instructions. Keep the eventual email and any exact-version permissions in the native correspondence record.

Keep reading