CRO for B2B SaaS: The Signup Is Not the Sale

You can read a demo request on Tuesday. You cannot read what it was worth until the deal closes or dies, and in this industry that is a quarter away, sometimes two. So every conversion test here is a bet placed on a proxy. The honest version of this service is largely about choosing that proxy with care and stating out loud what it can and cannot tell you.

Volume is the other half of the problem. Pricing pages and demo pages carry the least traffic on a B2B software site, and they are the pages worth testing. The sample-size arithmetic bites harder here than almost anywhere. That arithmetic is worked through with the numbers on the conversion rate optimization page. The first thing we do is run it against your funnel. You then see which hypotheses are affordable before anyone commits budget.

The lag is the design problem

Optimising a form for completions and reporting the result as a revenue lift skips the only step that mattered. So the metrics get agreed before traffic starts. Demo requests is the primary and it is read on the date the sample arrives. Qualified opportunity, and then closed revenue, are read later at dates fixed in advance. The sample is too small to call on its own, and the readout says so. When the two disagree, that disagreement is the finding.

What this rules out is a cadence that bills quarterly revenue impact every month. What it produces instead is a log. Each test, its proxy result on the day, and its pipeline result once the pipeline is old enough to read. A year of that log is the most valuable thing the programme owns, because it tells you which proxies at your company actually predict money.

One buying committee, two variants

Testing tools randomise per visitor or per browser. A software purchase involves an evaluator, a champion, a security reviewer and whoever signs. They arrive separately, often from the same company, sometimes from the same office network, and a visitor-level split scatters them across both arms. The one conversion event, whenever it lands, gets credited to whichever of them happened to fill in the form.

Where your CRM can identify the account, we randomise and analyse at account level. Where it cannot, we say so and treat the result as noisier than the tool’s confidence interval claims. No testing platform applies that correction on your behalf.

Two funnels fighting over one pricing page

A self-serve visitor wants a price, a plan comparison and a button. A sales-led buyer wants evidence you serve companies their size, the compliance paperwork their security team will ask for, and a person to talk to. One page tries to serve both. A change that wins for one motion can lose for the other, the combined number sits flat, and nobody learns anything.

Separating them is usually the largest improvement available. It is a change we would ship outright, because it is too big to fit inside one hypothesis. Distinct paths from the ad and from the search result. A pricing page that carries both and leads with the one matching the segment. Then tests run inside each path, where a result means something.

The fields that lose the test and win the quarter

Take a field off the form and completions rise. That part is well understood and on its own it is useless, because the fields exist to qualify. Company size, use case and timing are what stop two sales people spending a week on somebody who was never going to buy.

So a form test carries two numbers from the day it is designed. Completions now, qualified opportunities later. Sometimes the shorter form wins both, because the qualification was happening inside the CRM anyway. Sometimes it doubles completions and fills the calendar with nothing. Both are real outcomes and only one of them would have been visible on the day the test ended.

The step that decides it happens after the login

For a trial-led product the conversion that pays is activation, and activation happens inside the application. The marketing site can change the promise, the signup flow and who arrives. It cannot change whether a new account reaches the moment the product becomes obvious.

Which means the useful version of this work crosses the boundary. The test spans a marketing page and the first-run experience in the product. That is a different repository, a different release train and usually a different team. We will scope it that way. Or we will tell you the marketing-side test will read flat, because the drop-off sits on the other side of the wall.