Test plan template for B2B SaaS

The test plan with three columns a subscription business needs: which slice of the ideal customer profile the test runs against, where in the funnel it acts, and how long the result takes to become readable.

Everything else is the general test plan, unchanged. One hypothesis with a because in it, one variable, a named control, a minimum run, a read date set in advance and a decision rule for every outcome.

Use it when the outcome you care about arrives a quarter after the change. The lag is what makes testing hard here, and the only workable answer is to name in advance which early signal you will read and to say plainly that it is a proxy.

Use it again to stop the same test being repeated. In a long-cycle business the memory of a result fades faster than the cycle does.

Testing in a business with a long sales cycle is hard for one reason, and it is not sample size. It is that the thing you care about happens months after the change, and by then the account has moved on: the creative has been rotated, the list refreshed, the budget adjusted, the market slightly different.

There is no way to remove the lag. What a test plan can do is make the team honest about it, which is what the result lag column is for. Fill it from your own pipeline — how long from a lead arriving to an opportunity being accepted — and then set the read date from it rather than from when somebody would like an answer.

Where the full lag is longer than anyone will wait, the answer is to name a proxy and say so in the row. A sales-accepted lead is usually readable in weeks and correlates reasonably with what follows. A form fill usually does not correlate with anything. Writing which proxy is being used, and that it is a proxy, is the difference between a cautious finding and a false one.

The ICP segment column earns its place because messages do not travel.

A hook built around the cost of manual work lands on a company big enough for that work to be somebody's whole job, and means nothing to a company where one person does everything. A security-led message lands on a regulated buyer and reads as friction to everybody else. Test a message without recording the segment and the finding will be applied across the account, where it will fail most of the time for reasons nobody connects to the original test.

So the row names the segment, and the finding is written as a statement about that segment. If it matters whether the result transfers, that is a second row.

The funnel stage column prevents a different kind of over-application.

A variant that wins at demand capture — against a buyer who was already searching — says almost nothing about what will work at awareness, where the reader has no problem in mind. The two are different jobs and they are judged on different events. Running one test across both produces an average in which the capture arm, which converts quickly and cheaply, carries the whole result.

Most accounts in this category do not have the conversion volume to detect a small difference, and a plan that ignores that will produce a stream of confident conclusions from noise.

The practical response is to test larger things. The offer — a report against a tool against a working session. The segment — this industry against that one. The whole message rather than a line of it. Those produce effects big enough to read against the volume that exists.

Colour, button copy and minor variations belong to businesses with orders of magnitude more conversions. Running them here consumes the traffic that a real test needed and produces rows that cannot be believed.

In a long test the control is not a fixed thing. Lists get refreshed, sales gets better or worse at following up, a competitor launches, a quarter ends and the pipeline pressure changes.

Two protections help. Run both arms simultaneously rather than sequentially, so that whatever moves in the market moves under both. And write in the notes anything that changed during the run — a list refresh, a pricing change, a sales hire — because at the read date those are the alternative explanations, and they will not be remembered otherwise.

Sequential tests, where the variant runs after the control, are almost never trustworthy in this category. The gap between them contains too much.

There is a variable most plans forget: what happens to a lead after it arrives.

If the variant produces leads that are handled differently — routed to a different rep, called faster because somebody was excited about the test, or followed up with a different sequence — then the test is measuring the handling as much as the creative. This happens more often than anybody admits, particularly when the test is visible internally.

Write into the row that both arms are handled identically, and tell the sales team that. It costs one sentence and removes the most common invisible confound in this category.

A large share of tests here will end inconclusive, because the volume is small and the lag is long. That is not a failure of the plan; it is the honest result.

Record it, and record the reason: not enough accepted leads on either side, the list was refreshed mid-run, a quarter-end distorted the second half. Those notes are what let a future version of the test be designed better, and they stop the same idea being proposed every year as though it had never been tried.

Every row has a hypothesis with a because in it. Every row names one variable, one ICP segment and one funnel stage. The result lag is read from your own pipeline and the read date is set from it. Where an early signal is being used, the row says plainly that it is a proxy. Both arms run simultaneously and are handled identically after the lead arrives. And the decision rule covers the outcome where nothing moves, which here will be the most common one.