Skip to content
Build and run your first RevPlay
ReadLesson 1 of 12Choose a motion worth encoding

What makes a motion repeatable

Decide whether a motion your team runs today belongs in a RevPlay, or whether it should stay a judgment call a person makes each time.

5 minIntermediate
Part 1 of 4

Repeatable, not merely frequent

The instinct on a first play is to encode the busiest motion on the board. Busy is the wrong criterion. What earns encoding is a motion where the same trigger produces the same steps and the same definition of finished, whoever picks it up and whichever account it lands on.

That bar is higher than it sounds. Five reps chasing stalled opportunities are running five different motions that share a name: frequent, and not repeatable. Encode it and you get a play everybody argues with, because you have standardized a sequence nobody agreed on. Settle the sequence on paper first. The builder is for motions you have already decided.

  • Observable trigger — the play starts from a condition in the data, not from someone remembering
  • Stable sequence — the steps hold across accounts, not just across one quarter
  • Account-independent finish — you can say what "done" looks like without naming an account
Part 2 of 4

One motion per play

A RevPlay is deliberately narrow: eligibility decides which accounts enter, a timeline carries each one through, and actions execute at the autonomy you set. That one object replaced four older surfaces (campaigns, sales plays, sequences, lead flows) and it only holds together while a play means one thing.

The test is the name. If you cannot say what the motion does in one sentence without an "and", you have two motions. A play that re-engages dormant accounts and onboards new logos pulls its eligibility in two directions and leaves half the enrolled accounts sitting on steps that do not apply to them. Split it. The two run side by side quite happily.

The RevPlays library in RevTech: repeatable GTM plays and their enrolment.
The RevPlays library: repeatable GTM plays, the accounts enrolled in each, and the actions they generate. Screenshot of the RevTech application; sample data.
The RevPlays library. One row per motion, with the accounts enrolled in each and the actions it has generated, which is the honest measure of whether a play was worth encoding.
Part 3 of 4

What to leave to people

Encoding a motion is not the same as encoding every decision inside it. The steps that belong in a play are the ones with a stable shape: assembling the context, preparing the outreach, checking the account is covered, opening the renewal conversation. What to concede, whether this account is really ready, how hard to push: those stay with whoever the action routes to.

A play that reaches for the last mile is not more automated. It is wrong more often, and it teaches your team to distrust the queue, which costs you far more than the step was worth.

A correction prepared by RevTech, with the reasoning behind it.
A prepared correction shown with the reasoning that produced it, the KPI it affects and a confidence score, awaiting a human decision. Screenshot of the RevTech application; sample data.
A correction the agent prepared, with its reasoning, waiting on a person. The assembly is done and the judgment is not. That division is what a play encodes and what it must not try to encode.
Part 4 of 4

A worked example: three candidates, one survivor

Suppose your team has three motions on the whiteboard as candidates for a first play. Run each through the three tests rather than debating them in the abstract.

Candidate one: "executive outreach when a big deal stalls." The trigger fails the first test. "Stalled" and "big" are judgments someone makes, not conditions in the data, and two managers will disagree about the same deal. Encode it now and the play fires on deals people do not consider stalled. It needs a definition (no stage movement in N days above a value threshold) before it is a candidate at all.

Candidate two: "welcome sequence for new enterprise logos." Observable trigger (closed-won, enterprise segment), but ask five people what the steps are and you get five answers, because onboarding has never been agreed. The sequence fails the second test. This one needs a working session before it needs a builder.

Candidate three: "re-engage accounts that finished a pilot without converting." Observable trigger, a sequence your team already runs the same way from a shared doc, and "done" is definable: the account either re-engaged or was closed out with a reason. This is the one to encode first. Not because it is the biggest, but because it is the one where the builder standardizes an agreement that already exists.

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 are the three tests that a motion is repeatable?

It starts from an observable condition rather than someone remembering; the sequence of steps holds across accounts rather than just across a quarter; and you can describe what "done" looks like without naming a specific account.

Five reps run the same motion weekly, each starting it on a different signal. Encode it?

Not yet. That is frequent, not repeatable. Encoding it produces a play everyone argues with, because it standardizes a sequence nobody agreed on. Settle the sequence on paper first.

What to take away

  • Busy is the wrong criterion. Encode the motion your team already runs the same way, not the one they run most.
  • Five reps chasing stalled deals are running five motions that share a name. Settle the sequence on paper before you open the builder.
  • Encode the motion where the builder standardizes an agreement that already exists.
  • If the name needs an "and", build two plays.

Teach this lesson

The argument in 4 slides, for presenting it to your team
Slide 1 of 4

A RevPlay is one motion, not a program

Eligibility decides which accounts enter it. A timeline carries each account through it. Actions execute at the autonomy level you set.

  • One object replaces the old Campaign, Sales Play, Sequence and Lead Flow surfaces
  • Account-centric: the unit moving through the play is an account, not a contact
  • Accounts keep entering after activation, as they become eligible
Slide 2 of 4

Three tests for repeatability

  • It starts from an observable condition, not from someone remembering
  • The sequence of steps holds across accounts, not just across a quarter
  • You can describe "done" without naming a specific account
Slide 3 of 4

Frequent is not the same as repeatable

A motion five reps run weekly from instinct is frequent. If each of them starts it on a different signal and finishes it differently, there is nothing yet to encode.

Slide 4 of 4

If the name needs an "and", it is two plays

A play that both re-engages dormant accounts and onboards new logos will have eligibility fighting its timeline. Split it.

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