# PumpGTM messaging workbook

Use these templates and examples to make an artifact concrete. The language is proposed editorial material. It is not a record of published PumpGTM copy, customer results, or approved commercial promises.

## Reusable brand brief

### Identity and offer

**Speaker:** who is speaking and in what capacity.

**Offer:** the product or service described, using approved facts.

**Audience situation:** the task or decision bringing this reader to the piece.

**Positioning boundary:** what the offer addresses and what remains outside confirmed scope.

**Evidence inventory:** approved product documentation, customer examples, demonstrations, and relevant source material.

### Voice specification

| Trait | Evidence or proposed default | Writing instruction | Context limitation |
|---|---|---|---|

When working from samples, quote only short, exact excerpts and make their origin clear. A requested aspiration such as "more direct" can become a proposed rule, but should not be described as a trait already demonstrated by the samples.

### Message hierarchy

1. Main idea the reader should retain.
2. Mechanism that makes the idea useful.
3. Evidence that supports the explanation.
4. Important qualification or boundary.
5. Appropriate next action.

### Unresolved decisions

Record unknown product facts, commercial promises, voice choices, and visual requirements that would materially change publication. Do not turn every minor stylistic choice into a question for the user.

## Claim register

| Draft claim | Claim type | Supporting material | Limitation | Publication treatment |
|---|---|---|---|---|

Useful claim types include product capability, customer outcome, comparison, forecast, editorial opinion, and illustrative scenario.

Publication treatments:

- Ready: support directly matches the scope of the statement.
- Needs qualification: evidence supports a narrower statement.
- Needs verification: the underlying factual claim remains unresolved.
- Illustrative: clearly labeled as an example, not real performance.
- Remove: the claim is unnecessary and cannot be supported.

An internal label is not automatically enough for publication. If the public artifact needs a qualification to avoid misleading the reader, put that qualification in the artifact itself.

## Before-and-after examples

### Abstract promise to practical mechanism

**Before:** "Unlock the future of growth with intelligent prospecting."

**After:** "Before adding an account to your list, write down the signal that makes it relevant. If you cannot explain the connection to the buyer's job, research it further."

**Why the revision works:** it gives the reader an action and does not imply an undocumented product capability.

### Unsupported outcome to an evidence request

**Before:** "PumpGTM doubles your meetings without extra effort."

**After:** "PumpGTM's positioning centers on finding buyers and starting conversations. To evaluate its impact on meetings, compare qualified outcomes for a defined audience and time window."

**Why the revision works:** it preserves the supplied positioning while removing the unsupported numerical promise. This is an explanatory formulation; a final promotional piece may need a different structure once actual product and outcome evidence exists.

### Generic personalization to a relevant question

**Before:** "I loved your profile and thought we should connect."

**After:** "You mentioned reviewing several sources before choosing accounts. How do you decide when you have enough context to start a conversation?"

**Why the revision works:** it connects a verified professional statement to the job. Use it only if the statement actually exists and is relevant to the recipient.

### Demo number to an accurate description

**Before:** "Our customer booked 24 meetings with this workflow."

**After:** "This demo shows where meeting outcomes appear in the workflow. Its displayed figures are illustrative."

**Why the revision works:** it does not convert a seeded demonstration into a customer case study. Replace it with an actual outcome only when the evidence and permission are available.

## Channel templates

### Short educational post

**Opening:** a specific situation the reader recognizes.

**Useful distinction:** what the reader should look at differently.

**Mechanism:** one action or small example.

**Close:** a useful question or next step.

Illustrative draft:

"An account signal is a starting point for a question.

A hiring post may suggest that a workflow is changing. It does not tell you what the team needs or whether they want a new tool.

Write down the event, your hypothesis, and the question that could prove it wrong. That gives the conversation a useful purpose."

### Product explanation

**Reader and job:** identify who the explanation is for.

**Confirmed workflow:** describe only the current steps that documentation or inspection supports.

**Evidence:** show a real example or clearly labeled demonstration.

**Action:** use the actual available action, such as reviewing a workflow or requesting more information. Do not invent a free trial, demo booking page, or pricing offer.

### Longer educational piece

Frame the question, explain the mistake or tension, show the method, work through an example, state the boundary, and close with the reader's next step. Give each section a distinct purpose. A borrowed topic can be re-examined with original evidence and reasoning; copying another article's narrative sequence and changing words is insufficient.

### Demo script card

| Beat | Viewer question | Visible action | Spoken or written claim | Supporting evidence | Qualification |
|---|---|---|---|---|---|

Check that the visible action actually supports the narration. A research screen does not establish that an entire market was searched; an inbox example does not establish a reply-rate improvement.

## Worked PumpGTM content brief

**Reader:** a founder choosing accounts for a first outreach batch.

**Question:** how can I distinguish a useful account signal from superficial personalization?

**Main idea:** relevance comes from connecting an observable event to the buyer's job, then testing the connection with a question.

**Mechanism to explain:** event -> job hypothesis -> uncertainty -> discovery question.

**Example:** a fictional account's public hiring announcement. Show the event without presenting it as proof of pain or budget.

**Proof needed:** a verified public event if using a real account, plus any current product evidence if the draft shows PumpGTM performing a step.

**Suggested close:** invite the reader to write one event, one hypothesis, and one question for an account they are evaluating.

**Boundary:** this brief teaches a research practice. It does not claim that PumpGTM automates the whole method or guarantees commercial outcomes.

## Editorial review sheet

| Check | Question |
|---|---|
| Reader | Can the intended reader recognize their situation? |
| Meaning | Did the rewrite preserve factual substance? |
| Mechanism | Does the piece explain what to do or how something works? |
| Proof | Does each factual promise have matching evidence? |
| Scope | Are demonstrations, estimates, and customer outcomes distinguished? |
| Voice | Does the tone follow approved guidance or labeled defaults? |
| Originality | Is the explanation independently structured and worded? |
| Action | Is the next step real, relevant, and proportionate? |
| Format | Does the artifact fit the requested channel and length? |

## Maintaining brand context

Update the brief when an approved product fact, audience definition, offer, or voice rule changes. Record the new evidence and the date. Do not promote a one-off campaign preference into a permanent company rule. Keep personal-brand context separate from company context, and use the customer's own brief when writing on a customer's behalf.