Encode what happens, not what should
The documented process and the practiced one differ in every organization. A play built from the documented one is rejected by the people who run the real one.
Produce a written, honest account of how the motion runs today (its real steps, owners and failure points) so the play you build encodes reality rather than the version in the handbook.
Every revenue organization has two versions of its motions: the one in the enablement deck and the one that happens. They are rarely the same, and the gap is not laziness; it is the accumulated result of people adapting to what actually works. A play built from the published version gets rejected by the people running the practiced one, and you will spend the next month arguing about the play instead of the motion.
So start by watching. Take five accounts that recently went through the motion end to end and rebuild what was actually done to each: which step happened, in what order, who did it, how long the gaps were, where it stalled. Work from the record (activity history, notes, the opportunity timeline) rather than from memory. Memory reliably reports the ideal path.
With five accounts side by side, the differences between them are the whole point of the exercise. Every one falls into a bucket, and each bucket has a different destination in the play, which is what turns an audit into a design.
The sort also tells you early whether the motion is ready at all. If almost everything lands under judgment, you are looking at a skill rather than a process, and encoding it will not help yet.
The last column of the audit is the most useful one: for each account, where did the motion lose time? A handoff nobody picked up, a step that waited on research, an approval that sat for four days. These are the points where the play will pay for itself, because they are the ones an agent can prepare in advance rather than leave someone to start from nothing.
Keep the finished audit somewhere durable. Your artifact library is the right home: it is the operating library your agents reference when they generate work, and it is versioned, so in a quarter you will be able to see exactly what the motion looked like before the play existed.

Concretely, the deliverable is one page per account, five accounts, same format. A worked line from one of them: "Day 0: pilot ended, result summary sent by SE. Day 9: AE sent follow-up (nine-day gap: AE was at QBRs). Day 9: no reply. Day 23: second follow-up, different thread, no reference to the first. Day 40: account marked dormant by manager during pipeline review." Every line is a fact from the activity record with a date and an owner, and the gaps are recorded as deliberately as the actions.
Under the five accounts go three lists, one per bucket: the variations you judged to be judgment, with what the person weighed; the drift, meaning the same work done in a different order or at a different time for no reason; and the segment differences, the ones that are real and structural.
Then a fourth list, which is the one that justifies the whole exercise: where each account lost the most time. In the worked line above it is the nine-day gap, and that gap, not the outreach copy, is what the play will fix, because an agent can have the follow-up prepared on day 2 whether or not the AE is at QBRs.
That format is the whole method. If you can produce it for five accounts you have everything the builder will ask you for: the trigger, the sequence, the timing, the owners, and the failure points that justify encoding it at all.
Do this in the product
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.
Judgment becomes an approval step, never a rule. Drift is what the play standardizes and the reason to build it. Segment becomes an eligibility condition or a separate play.
Memory reports the ideal path. The record shows what was actually done, in what order, and where the gaps were, which is what the play has to encode.
The motion is a skill rather than a process. Encoding it will not help yet, because there is no stable sequence to encode.
The documented process and the practiced one differ in every organization. A play built from the documented one is rejected by the people who run the real one.
Write it into your artifact library. Agents reference what you keep there, and next quarter you will want to know what the motion looked like before the play.
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