Open the CRM of almost any growing software company and count the automated sequences that are switched on. Then ask who owns each one, what it is supposed to change and how anyone would know it had stopped working. The answers are usually "the person who left in March", "more meetings, probably" and silence.
That is not a tooling problem. It is a design problem. A sequence, a campaign or a nurture track is a piece of the go-to-market system that runs every day and touches real customers, yet it is launched with less thought than a minor software release.
CloudNala's view is that a go-to-market play should be built like a small product: specified on one page, owned by a named person, tested against a holdout, and launched with the criterion for switching it off already written down. Teams that work this way run fewer plays and learn far more from each one.
This is Part 6 of the series. Parts 1 to 5 built the foundations: the motion as a system, the GTM engineer's role, revenue data you can trust, signals as hypotheses and a lead score that explains itself. This part is about what the team actually does with those signals and scores.
Lowveld Ledger is fictional, and its systems and figures are illustrative. It is a Mbombela accounting and payroll software company for SMMEs, with about 2,300 paying customers, a nine-person sales and marketing team and one newly hired GTM engineer.
Twenty-three sequences and no answers
When Lowveld Ledger's GTM engineer started, the CRM held 23 active sequences. Some were welcome emails for trial sign-ups. Some were outbound cadences the SDRs had built for different industries. One was a webinar follow-up that still promoted a webinar from the previous year. Two of them could fire at the same contact in the same week.
Nobody had done anything wrong. Each sequence had been a reasonable idea when someone built it. The problem was that nothing in the system required an idea to state what it was for, so nothing could ever say it had failed. Sequences accumulated the way old servers accumulate in a data centre: each one cheap to keep, all of them together expensive to understand.
The cost was real, even if it never appeared on a report. Customers received overlapping messages. SDRs could not tell which follow-ups were theirs. When trial conversion dipped in winter, nobody could say whether any of the 23 sequences had helped, hurt or done nothing.
What a play is, and what it is not
The word "play" is used loosely, so it helps to be precise.
A sequence is a mechanism: a set of timed messages in a tool. A campaign is usually a burst of activity around a date or an offer. A play is a decision about how the business will respond when a specific situation occurs for a specific kind of account, with a stated reason for believing the response will help.
That last part is what makes a play a product. It has a user (the account), a trigger (the situation), a value proposition (the offer) and a measurable effect. A sequence may be one of the mechanisms a play uses, but the sequence is not the play, any more than a database table is the application.
This distinction matters because it changes the conversation. "Should we add a fourth email to the trial sequence?" is a question about mechanism. "Trials that start a test payroll and then stall are our best rescue opportunity, and here is how we will respond" is a question about the business, and it can be tested.
The play specification
Lowveld Ledger now writes every play on one page before anything is built. The page has eight fields.
Audience is drawn from the ideal customer profile written down in Part 3: which accounts this play is for, in terms the CRM can actually filter.
Trigger is the situation that starts the play. It should come from the signal catalogue, which means it already has a hypothesis and an owner. A trigger that is not in the catalogue is a sign that someone is inventing a signal on the fly.
Offer is what the account gets. It must be something of value to them, not a request for their time dressed up as help. "A 20-minute call to finish your first payroll" is an offer. "A quick chat to understand your needs" is not.
Channel and message say how the offer arrives. Keep the message to a sentence at specification stage. If the play cannot be explained in one line, the copywriting will not save it.
Owner separates two jobs that are easy to blur. The GTM engineer builds and maintains the play. A business owner, at Lowveld the head of sales, owns the result and decides whether it continues. A play owned only by the person who built it tends to survive because it works technically, not because it works commercially.
Success metric names one measure and the comparison that makes it meaningful. For Lowveld's flagship play, that is trial-to-paid conversion within 30 days, compared with a holdout group of 20% of eligible trials that receive nothing new.
Kill criterion is the field that most teams leave out.
Write the kill criterion before launch
A kill criterion says, in advance, what result will cause the play to stop. Lowveld's reads: "No lift over the holdout after 200 trials or 8 weeks, whichever comes first."
Writing it before launch matters for a simple reason. After launch, everyone involved has a stake in the play working. The SDRs have spent time on it. The GTM engineer has built it. The head of sales has mentioned it in a management meeting. Once those investments exist, an ambiguous result will almost always be read as "promising, let's give it another month". A criterion agreed in advance turns that negotiation into a check.
Three practical rules make kill criteria useful rather than ceremonial:
- Name a sample size or a time limit, and prefer both. Small companies rarely have the volume for statistical certainty, so the criterion should say what evidence is enough to decide, not what would satisfy a statistician.
- Use a holdout wherever the play is automated. Without a comparison group, any change in conversion could be season, pricing or a new competitor. Lowveld's 20% holdout costs some potential conversions, and that cost is the price of knowing.
- Define "harm" as well as "no effect". A play that increases unsubscribes or complaints should stop even if conversion rises. Part 9 covers how to track this alongside the main metric.
A backlog, not a calendar
Most marketing teams plan by calendar: what goes out in March, what goes out in April. Product teams plan by backlog: a ranked list of things worth building, pulled into work as capacity allows. Plays belong in a backlog.
Lowveld keeps a simple one. Anyone in sales, marketing, customer success or partnerships can add an idea. Each idea needs a sentence stating the situation and a sentence stating the expected effect. Once a month, the GTM engineer and the head of sales rank the backlog on two questions: how much would we learn if this worked or failed, and how big is it to build?
The team also applies a work-in-progress limit: no more than four plays live at once. For a nine-person team with one GTM engineer, that is about as many as can be monitored properly. When a fifth play is ready to launch, one of the four must finish its review first.
The limit feels restrictive at first. In practice it does the opposite. With four plays running, each one gets attention, each one gets reviewed on time and the holdout groups do not overlap so much that results become impossible to read.
The life of a play
Every play at Lowveld moves through the same stages.
Idea is a backlog entry. Specified means the one-page specification is complete, including the kill criterion, and the business owner has signed it off. Pilot runs the play on a small cohort, often 20 to 50 accounts, so that broken automation, poor copy or an overlooked conflict with another play surfaces before it reaches everyone. Live extends it to the full audience with the holdout in place. Review compares the result with the holdout and the kill criterion.
Review has three legitimate outcomes. Scale means the play works and may be extended to a wider audience or a second channel. Revise means the evidence suggests a specific change, and the revised play goes back to a pilot, because a changed play is a new hypothesis. Retire means it stops.
The first review of the "Trial payroll stalled" play is a useful example. The play beat the holdout on trial-to-paid conversion. It also showed that the in-app prompt drove almost all of the bookings while the follow-up email from the AE added little. The decision was to revise: remove the email, move that AE time to accounts that had replied, and run the revised play as a short pilot before scaling it, because a changed play is a new hypothesis even when the change looks obvious.
Retire plays on purpose
When Lowveld reviewed its 23 inherited sequences against the new specification format, 11 could not be given a sensible trigger, offer or metric. They were retired. The remaining 12 were rewritten as play specifications, and only four went live at a time under the new limit.
Retirement deserves the same care as launch. A retired play needs three things: a one-line conclusion recorded in the experiment log described in Part 9, its automations switched off rather than paused indefinitely, and any contacts mid-sequence handled deliberately so that nobody receives the third email of a conversation that no longer exists.
The conclusion is the valuable part. "Industry-specific outbound to construction firms produced replies but no trials, because their payroll is mostly weekly and our weekly-payroll features were weak" is knowledge the company keeps. A sequence that quietly stops sending teaches nobody anything.
Plays and the rules around them
A play that sends messages also has to respect consent, opt-outs and the direct-marketing rules that Part 10 covers. Lowveld's specification template therefore has a ninth line under the eight fields above: "Contact basis confirmed by", with the name of the person who checked that every contact in the audience may lawfully receive this kind of message through this channel. A play cannot move from Specified to Pilot with that line blank.
That one line does more to stop bad plays than any copy review.
Start this week
- Count your live sequences and campaigns. For each, write down the owner, the intended effect and the date it was last reviewed. Expect gaps.
- Pick your most important automated play and write its one-page specification, including a kill criterion and a holdout. If you cannot fill in the success metric, that is the first finding.
- Set a work-in-progress limit that matches the people you have to monitor plays, and retire enough of the existing ones to get under it. Record a one-line conclusion for each.
Next: Part 7, AI personalisation is easy. Relevance is hard. All parts are on the series page.
How CloudNala can help
CloudNala reviews go-to-market systems the way we review software delivery. We inventory the plays, sequences and automations you already run, identify which have no owner, metric or stopping rule, and help you rewrite the ones worth keeping as specifications with holdouts and kill criteria. We also help you set up the backlog and review rhythm, so that new plays are tested and retired on evidence rather than accumulated.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Go-to-Market Systems Review or write to us at consult@cloudnala.co.za