A self-service free trial gets you halfway to PAYG
If you have costed a move to self-serve and pay-as-you-go, you will have found what everyone finds. Pricing decisions, a metering pipeline, invoicing, revenue recognition, and all of it to be agreed with finance before anything ships. That is a programme, not a project, and deciding it can wait another quarter is a reasonable call to make.
There is a smaller piece of it worth pulling out and doing on its own.
A self-service free trial is roughly half that build, and it is the half with no billing, no metering and no financial exposure. It is also the half you keep. The provisioning, the CRM wiring and the usage telemetry all get reused when you do move to pay-as-you-go, so you are building the first part of the bigger thing and getting something usable out of it on the way.
Where enterprise trials have actually got to
We spent a morning in August going through the public trial pages of fourteen enterprise infrastructure vendors across security, observability and DevOps, recording the route each one advertises. Small sample, deliberately chosen, and we measured the advertised route rather than attempting fourteen signups — so treat the counts as an observation rather than a rate.
Nine of the fourteen advertise immediate access without speaking to anyone. Every observability and DevOps vendor we looked at was in that group. The four still routing to a sales conversation were all security vendors, and all four sell to the network or security operations team. Snyk, Wiz and Okta — the security vendors whose buyer is a developer, a cloud team or an identity admin — were already self-serve.
So the pattern is not that enterprise vendors gate their trials. It is closer to this: where the buyer is a developer or a platform engineer, the gate has gone. Our customers and the wider ISV industry are making that shift, and we are enjoying helping them make it count.
What replaced the sales gate
The gate has not so much disappeared as changed shape, and the new shape is easier to miss because the trial page looks self-serve.
CrowdStrike's Falcon trial asks for no sales call and no card. Its own confirmation page is straightforward about what happens next: the request gets reviewed within 24 hours, and access follows by email. Palo Alto puts the same idea more bluntly on its VM-Series trial form, warning that its team cannot review requests submitted with personal email addresses. Different vendors, same mechanism — a person, or a rule standing in for one, deciding whether you are worth provisioning for.
Call that state approved. It sits between gated and self-serve, and it is worth separating out because it behaves differently from either. There is no sales call to book and no credit card to find, which is why it reads as self-serve from the outside. There is also no product until tomorrow.
Approved is a reasonable place to have landed. It is what happens when a company commits to offering a trial before it has automated provisioning and qualification, and it is a real improvement on booking a call. It is also the cheapest state to leave alone, because nothing is visibly broken. The trial works. It just starts tomorrow.
What it costs is the evaluation you never see. A buyer with a free afternoon and three vendor tabs open does not have a free afternoon tomorrow. And the twenty-four hours is doing two jobs at once — screening out low-quality signups, and provisioning an environment. Only one of those needs a human, and it is not the one that takes the time.
Nobody's roadmap has this on it
There is an honest reason this work sits undone in a lot of companies, and it has nothing to do with difficulty.
None of it is a product feature. A registration flow that writes to your CRM, automated provisioning, automated teardown, telemetry flowing back — none of that appears on a roadmap, none of it closes a competitive gap, and none of it wins a prioritisation call against something a customer has asked for by name. It is infrastructure for the buying experience rather than for the product.
Which is why it tends to get scoped as part of some larger PLG programme and then wait for that programme to be funded. Pulled out on its own it is a few weeks of engineering, and it does not need to compete with the roadmap at all.
What a trial is for, and what the build contains
A free trial exists to remove perceived risk. A buyer wants evidence that your product works in their environment before they spend political capital getting it approved. Everything layered on top of that — the lead capture, the nurture sequence, the qualification — is secondary to the one job.
Seen that way, the trial sits at one end of a spectrum of risk reduction. Pay-as-you-go sits further along: a small commitment, but real money. A proof of concept sits at the far end, heavily assisted, expensive to run, and only offered to buyers who have already invested enough of their own time to earn one. The trial is the version with the lowest commitment on either side.

Two things decide whether it does that job:
- The buyer reaches the product without waiting for a person.
- The buyer reaches value on their own data. Seeing their own environment reflected back in your product is what makes it real for them, and it shows your product at its best on the ground it will actually be judged on.
Getting there needs less than the PLG programme it usually gets bundled into. Nobody is being billed, so there is no meter to run, no usage to reconcile, no invoice to dispute and no tax treatment to agree. Take those out and what remains is:
- a registration flow that creates a company and contact record in your CRM
- automated provisioning of a working environment
- automated decommissioning when the trial ends
- usage telemetry flowing back, so sales can see what the buyer actually did
In our experience building these for infrastructure software vendors, that is roughly half the work of a full pay-as-you-go launch. If you are already in the approved state, you have some of it. The registration flow exists and the environment gets built. What is missing is the part that makes it happen while the buyer is still on the page.
What sales gets out of it
The objection we hear most often is that self-service takes the deal away from the sales team. In enterprise it does not, because these deals were never going to close on their own. Designed properly, the trial does the groundwork and hands sales a better starting position than any outbound sequence will.
It is worth noticing that the approved state is the version that serves sales worst. The prospect is sitting in a queue with their interest cooling, and when the rep does make contact there is still no usage data to talk about — so the call opens with "I saw you requested a trial", which is the same cold opening as before, minus a day. The queue costs the rep the one thing a trial was supposed to give them.
Compare that with telemetry wired up. The rep knows which integrations the buyer connected, how far through the product they got, and where they stopped. The conversation starts at a need the buyer has demonstrated rather than one the rep has to go looking for.
That is the trade. Sales gives up the first contact and gets a product-qualified lead in exchange: an account that has deployed your software in its own environment, against its own data, and has formed a view worth responding to. It is worth being honest that a fully unassisted journey is not automatically better, and we have never had a customer who wanted one. Enterprise deals still close through sales. The question is where the gate sits and what sales knows by the time it reaches them.
The decisions with no clean answer
None of these have a universally correct answer, and leaving them open is what produces a poor trial.
How does the trial end? Start from the goal, which is that the buyer reaches value inside whatever limit you set. Work out how long that realistically takes in a customer environment, then set the limit generously against it. Elapsed time is the simplest to build. Usage caps are harder and fairer on a buyer who loses a fortnight to an internal approval process. Reduced functionality is the riskiest, because the feature you held back could be the one that would have convinced them. A trial that expires before anyone could reasonably have got value out of it has cost you the evaluation and taught the buyer something you did not intend.
What happens when it ends? Suspend the account and archive the data for a defined window, or delete it. Either is defensible. Decide, say so up front, and make sure a buyer who converts does not lose the configuration they spent two weeks building. Wiping a customer's trial work at the moment they decide to buy is an expensive own goal.
Where do you offer it? Your own site, Cloud Marketplace, or both. Marketplace reaches buyers who are already in a procurement mindset and gives you a clean route to a paid agreement. Your own site gives you more control over the experience and the data you collect.
What was the twenty-four hours for? If part of the answer is qualification, keep it and automate it. Domain verification and a deny list do most of what a human reviewer does, and they run in a second.
Time to activation is the thing that decides it
The trial mechanics are the easy part. The work that decides whether any of it pays off is getting a buyer from "signed up" to "looking at their own data", and for infrastructure software that is an engineering problem rather than a UX one.
It is also the point where the buyer is quietly answering a second question. Not just whether your product works, but what it is going to be like to live with. If getting to first value needs a cross-account role, a change request and two people from their platform team, they have learned what the rollout will cost them long before they have learned what the product is worth. Activation is the first honest estimate a buyer gets of your total cost of adoption, and they read it as one.
This is the part we, Cloudsoft, spend most of our time on. It usually means solving deployment problems that have nothing to do with your product's value: cross-account access, permissions, agent rollout, ingestion from whatever the customer already runs. We wrote up one example recently, on using IAM temporary delegation to take the access friction out of that first connection.
For one security vendor, automating agent deployment took activation from a job measured in weeks to something close to immediate.
If activation currently needs a solutions engineer on a call to get an agent deployed or a cross-account role assumed, that is the piece to solve first. It also pays back well beyond the trial, because every customer goes through it.
Where to start
Sign up for your own trial, on a laptop you have not used before, with a work email nobody recognises. Time it from the click to the first screen showing your own data.
If the answer is a day, you already know what the next piece of engineering is, and it is smaller than the programme it usually gets attached to. The smallest useful version is a real registration flow, real provisioning, real decommissioning and real usage tracking, with the finance and support edges handled manually while volumes are low.
At the end of it you will know something you currently do not: how far your buyers get when nothing is waiting for them.
We are seeing how this is being solved across a range of ISVs at the moment, and the practices are still forming. If you are working on yours, we would like to hear how you are approaching it — get in touch.