Slide 1 of 4
Start narrower than feels right
A first play that enrolls thirty accounts teaches you what is wrong with it. One that enrolls three thousand teaches you nothing, expensively.
Build and run your first RevPlay
DoLesson 8 of 12Define eligibility
Building your eligibility set
Write and refine the conditions for your own play, starting deliberately narrow and widening only once the motion has proven itself.
26 minIntermediate
Part 1 of 4
Deliberately narrow, first time out
The most common mistake on a first play is enrolling too much. It feels like caution to launch against the whole addressable segment (you are not leaving value on the table) but it is the opposite. A play that enrolls thirty accounts produces a volume of prepared work your team can actually read, which means the defects in your instructions surface in days and get fixed while everyone still remembers the design. A play that enrolls three thousand produces a queue nobody works, and the feedback you needed is buried.
Narrow does not mean arbitrary. Add a condition that genuinely predicts fit for the motion (a tier, a region, a single product line) rather than capping the number, so the accounts you learn from are representative of the ones you will eventually add.
Part 2 of 4
Check your conditions against reality before activating
Two checks catch most of the errors people make here, and both take a few minutes.
The first is the named-accounts test. Before you look at any count, write down three accounts that obviously belong in this motion and two that obviously do not. Then check your conditions against them. When the definition disagrees with your own judgment about a specific account, the definition is what is wrong, and it is far cheaper to learn that now than from the queue.
The second is a maintenance check on the properties themselves. A condition is only as reliable as the field it reads. Filtering on a property that no one has updated since the last migration produces a play that quietly matches nothing, or matches the wrong accounts, with no error anywhere. If the field you want is not maintained, either fix that first or filter on something that is.
Part 3 of 4
Widening comes later, and on evidence
Widening is a separate exercise, done on evidence rather than on launch day. Let the narrow set run a full cycle of the motion, long enough for the last timeline step to land, and read what happened, particularly what got rejected and why. Then relax one condition at a time.
One at a time is the discipline that makes this work. Relax three conditions together and the enrollment doubles, the rejection rate moves, and you have no way to attribute either. Relax one and the change is legible.
Part 4 of 4
A worked run of the named-accounts test
You have drafted conditions: mid-market segment, pilot completed, pilot ended 30–120 days ago, no open escalation. Before looking at the count, you write down three accounts that obviously belong, say Meridian Foods, Calloway Logistics and Brightline Health, all pilots that went quiet last quarter, and two that must not enter: Ostrander Group, mid-renewal negotiation, and Vantage Retail, which has a live escalation.
Check each against the conditions. Meridian matches. Calloway does not — its pilot was recorded under a legacy stage name your condition does not include, which is a data inconsistency you have just found for free. Ostrander, alarmingly, matches: you wrote the escalation exclusion but forgot the renewal-negotiation one. Two condition fixes later, all five names resolve the way your judgment says they should. That is ten minutes of work, and it caught one data problem and one missing exclusion that no amount of staring at a count of 47 would have surfaced.
Do this in the product
Write your eligibility conditions
- Reopen your draft play and move to step 3, Eligibility.
- Write the segment conditions first — the structural filter for who this motion is for.
- Add the lifecycle stage conditions, so the play only applies where the motion belongs.
- Add the signal condition that makes now the right time to work these accounts.
- Add your exclusions: active renewal negotiations, open escalations, and accounts enrolled in competing plays.
- Run the named-accounts test — three that should match, two that should not — and correct the conditions where they disagree with you.
- Tighten one further condition so the first run enrolls a set your team can genuinely read through.
Key questions
You should be able to answer each of these from memory before opening it. Recalling the answer is what makes it stick; recognizing it when you read it does not.
What is the named-accounts test, and when do you run it?
Before looking at any count, write down three accounts that obviously belong and two that obviously do not, then check the conditions against them. When the definition disagrees with your judgment about a specific account, the definition is wrong.
Why relax only one condition at a time when widening?
Relax three together and enrollment doubles while the rejection rate moves, with no way to attribute either. One at a time keeps the change legible.
What to take away
- Name three accounts that must be in and two that must be out, and test the definition against them before you look at any count.
- The named-accounts test finds data problems for free. A pilot recorded under a legacy stage name never shows up in a count.
- Enrol narrowly the first time. Small sets surface defects while the design is still fresh.
- Widen after a full cycle, one condition at a time, so the effect stays attributable.
Teach this lesson
The argument in 4 slides, for presenting it to your team
Slide 2 of 4
Widen on evidence
- Run the narrow set for a full cycle of the motion
- Read what got rejected, and why
- Relax one condition at a time so you can attribute the change
Slide 3 of 4
Prefer properties that stay true
Conditions built on fields nobody maintains will silently stop matching. Check that the properties you are filtering on are actually kept current.
Slide 4 of 4
Test the definition against known accounts
Name three accounts that should obviously be in, and two that should obviously be out. If your conditions disagree, the conditions are wrong.
Demo
Try the demo.
See agents carry the repeatable work of GTM across sales, marketing, customer success, and RevOps. Every action prepared, reviewed, and recorded. Fictional data, real product.
Explore the demo