Sales Playbook Template: One Play per Account Change

Most sales playbooks get read twice. Once by the person who wrote them, and once by a new rep in their first week, sitting next to a stack of onboarding slides. After that the document lives in a shared drive, linked from a wiki page nobody opens, while the team goes back to working the list the way they always have.

That is not because the playbook is badly written. The usual template is thorough: an overview of the company, the ideal customer profile, two or three personas, the stages of the sales process, discovery questions, objection handling, a competitor section and some email templates. Every one of those sections is accurate. The problem is that none of them answers the question a rep has at 9am on a Tuesday with two hundred names in front of them: which of these accounts should I work today, and what do I say when I do?

A playbook organised by stage and persona tells a rep how to behave once a conversation exists. It says almost nothing about how a conversation starts. This article is a template for a different shape of playbook, one organised around the account changes that start conversations, with one play per change and a clear bar of evidence a rep must clear before running it.

Why the standard sales playbook template goes unread

Look at where the standard template puts its effort. Stage definitions, exit criteria, discovery frameworks and objection scripts all assume a buyer is already talking to you. That is the expensive half of the motion, so it is natural to document it carefully. But it is not where most rep hours go.

Salesforce's research on this is blunt. Its State of Sales survey of 7,775 sales professionals found that reps spend just 28% of their week actually selling, with the rest going to deal management, data entry and the work around the sale. A large share of that non-selling time is the research and list work that comes before anyone picks up a phone. A playbook that is silent on that work is silent on most of the job.

There is a second reason the stage-and-persona template fails, and it is more important. It treats every account in a segment as equally ready to buy. The persona section says the VP of Operations at a 500 person logistics company cares about cost per shipment. Fine. There are four hundred such companies on the list. The persona does not tell you which three of them have a reason to care this quarter.

That missing reason is why so many well-run deals still stall. Matt Dixon, describing the research behind his work on buyer indecision in an interview with CustomerThink, put it this way: "anywhere between 40 and 60% of all deals are actually lost to the customer doing nothing." A buyer with no reason to change does nothing. A playbook that starts a conversation without a reason is setting up that outcome on purpose.

The reason test: the one rule every play depends on

Before rebuilding the template, it helps to state the rule the new shape is built on. Call it the reason test. A name on your list is worth contacting when you can answer three questions about the account:

• What changed? A specific event at the company: a new leader, a funding round, a hiring push in one function, a new market, a product launch, a public complaint about a process you fix.
• Where did you see it? A source a buyer could check: a press release, a job posting, an earnings call transcript, a LinkedIn announcement, a regulatory filing.
• When did it happen? A date, recent enough that the change is still being acted on.

No reason, no call. That rule sounds harsh until you notice that it is what your best reps already do by instinct. They do not work a list top to bottom. They skim it for the accounts where something moved, and they open with the thing that moved. The reason test just writes the instinct down so the rest of the team can run it too.

If you have read our piece on trigger events in sales, this will look familiar. The difference here is that the reason test becomes the organising principle of the playbook itself, not a tip buried in the prospecting chapter.

The template: one play per account change

Here is the structure. Keep the parts of the standard template that still earn their place (ICP, personas, stage definitions, objection handling) in an appendix. The front of the playbook becomes a short library of plays, and each play is keyed to a change you can observe at an account.

Every play has the same seven fields:

Field	What goes in it	Why it is there
The change	One observable event, stated narrowly. "New head of finance in the last 90 days", not "leadership change".	A narrow change can be checked. A broad one becomes a guess.
Why it matters to us	The specific problem this change tends to create or expose, in terms of what you sell.	Stops reps from treating every signal as a reason to pitch everything.
Evidence required	What the rep must have in hand: the source link, the date, and the named person.	This is the reason test made concrete. No evidence, the play does not run.
Who to contact	The role most affected by the change, and the role that usually owns the budget.	The person who caused the change is often not the person who feels it.
What to pitch	The one capability that maps to the problem. One, not the whole product.	A focused offer is easier to say yes to than a tour.
Opening line	A first sentence that names the change and the source, written so a rep can adapt it in a minute.	The opener proves you did the work. It is the part buyers read.
Expiry	How long the change stays relevant before the play goes stale.	A reason from eight months ago is not a reason now.

Most teams can cover the bulk of their pipeline with six to ten plays. More than that and reps stop remembering them, which brings back the original problem.

A worked example play

Say you sell a tool that automates expense auditing for mid-market finance teams. One play might look like this:

• The change: The company hired a new CFO or VP of Finance in the last 120 days.
• Why it matters to us: New finance leaders usually review spend controls early, and expense policy is one of the first places they find leakage.
• Evidence required: The announcement (press release or the leader's own LinkedIn post), its date, and the leader's name.
• Who to contact: The new leader, plus the controller or head of accounts payable who will run any review.
• What to pitch: Policy checks on every claim, not a full spend platform.
• Opening line: "Saw your announcement on the 14th that you joined as CFO. New finance leaders we talk to often start with a look at expense policy, so I wanted to share how other teams audit every claim instead of a sample."
• Expiry: Six months after the start date.

Notice what this does. A rep scanning a list now has a filter: which of these accounts has a finance leader who started in the last four months? That is a question with a yes or no answer, and the answer comes with a source. The rest of the play tells them exactly what to do with a yes.

Plays most B2B teams can start with

The right changes depend on what you sell, but these come up across most B2B motions:

1. Hiring push in the function you serve. Five open roles in customer support says the support team is growing or struggling. Either one is a reason if you sell to support.
2. Funding round or acquisition. New money usually arrives with a plan, and the plan usually names the areas getting investment.
3. Expansion into a new region or segment. New markets bring new compliance, language, tooling and staffing needs.
4. Public statement of a problem. An earnings call, an interview or a job posting that describes the exact process you fix.
5. Competitor contract approaching renewal or a public switch. See our guide to competitive displacement strategy for how to run this one without spamming every account on a technographic list.
6. A champion moved to a new company. Someone who bought from you before is now somewhere that has not.

Each of these is a buying signal only relative to what you sell. A hiring push in engineering means nothing to the expense tool above. That is why each play has a "why it matters to us" field, and why a generic signal feed rarely helps a rep decide what to do.

How to build your first change-based playbook in a week

This does not need a quarter-long enablement project. A small group can draft it in a few working sessions.

1. Pull your last 20 to 30 closed-won deals. For each one, ask the rep who closed it what was happening at the account in the 90 days before first contact. Write down the change, not the pitch.
2. Group the changes. You will usually find four to six patterns that cover most of the wins. Those are your first plays.
3. Write the "why it matters to us" line for each. If you cannot write one sentence linking the change to a problem you solve, drop the play.
4. Set the evidence bar. Agree what counts as proof for each change and where reps should look for it.
5. Draft opening lines with your best reps. Have them write what they actually said, then tidy it. Lines written by enablement alone tend to read like marketing.
6. Set expiry windows. Use the deal data. If wins came 30 to 120 days after a change, a play that runs on a two year old change is noise.
7. Run it on one list. Pick a list a rep already owns and run the reason test on every name by hand. Count how many pass. That number is your first honest measure of list quality.

The last step is the one most teams skip, and it is the most useful. Running the reason test by hand on a real list of two hundred names usually shows that a small fraction of them have a live reason, and that finding those few takes hours of research per rep per week. That is the cost the old playbook hid: it gave reps a script for the conversation but left them to discover, alone and unpaid for, which conversations were worth having.

Where the research for each play comes from

A change-based playbook moves the hard part of selling forward. Instead of the rep improvising at discovery, the rep has to find the change, check the source, note the date and identify the right person before the first touch. Done by hand, that is roughly what a good pre-call research checklist asks for, multiplied by every name on the list.

There are three ways teams handle that load:

• Reps research by hand. Highest quality per account, lowest coverage. Most lists never get fully worked.
• A signal feed. Broad coverage, but feeds report events without judging whether they matter to what you sell, so reps still have to filter.
• Research done against the playbook. Every account is checked for the specific changes your plays depend on, and each finding comes back with its source and date.

The third option is what PitchSmart does. You describe what you sell, and it researches every lead on your list against it, returning a plan for each one: who to contact, what to pitch, why now and what to say, with a source on every claim. In playbook terms, it runs the reason test on every name and fills in the play fields for the ones that pass, so the rep starts from the evidence instead of hunting for it.

Whichever route you take, the playbook shape is the same. If you want more on the method itself, our piece on signal-based selling covers how teams prioritise once the signals are in hand.

Keeping the playbook alive after launch

A change-based playbook decays in a different way from the stage-based kind. Stage definitions rarely go out of date. Plays do, because the changes that predict buying shift as your product, market and competitors move.

Three habits keep it current:

• Tag every opportunity with the play that started it. One field in the CRM. After a quarter you will know which plays produce pipeline and which only produce activity.
• Review plays monthly, not yearly. Retire the ones with no wins. Add new ones when reps report a pattern the playbook does not cover.
• Keep the opening lines fresh. When a line stops getting replies, rewrite it from whatever the latest winning reps said.

The test of whether it is working is simple. Ask a rep why they called the last account they called. If the answer names a change, a source and a date, the playbook is doing its job. If the answer is "it was next on the list", the list is not the problem. The missing reason is.