To add a demo to your pricing page, put it below the plan comparison rather than above it, show the
one capability that decides which plan people pick, leave it ungated, and lazy-load the embed so the
page does not get slower. The placement matters more than the production quality, because a visitor
on a pricing page is at a different stage than one on your home page.
Why does the pricing page need a demo at all?
Because it is where the objection lives.
A visitor on your home page is asking "what is this?". A visitor on your pricing page has already
answered that and is asking a harder question: "is this worth that number?". They are looking at a
price with nothing beside it except a feature list — and feature lists are the least persuasive
format in software marketing, because every competitor has a similar one.
An interactive demo answers the worth question in the only way
that reliably works: by letting them see the thing they would be paying for, doing the job, before
they commit anything.
Where exactly should it go?
Below the plan table. This is the placement people get wrong most often.
The instinct is to lead with the demo, because it is the most impressive asset on the page. But
someone who navigated to /pricing came for a number, and putting anything between them and that
number reads as evasion — the same reflex that makes "contact us for pricing" so unpopular. Give
them the plans first.
Directly beneath the table, the demo catches exactly the right moment: they have seen the price,
they are weighing it, and now there is something to weigh it against. A short heading helps —
something like "Here is what you would actually be doing" — because it frames the demo as evidence
rather than decoration.
Two other placements worth considering:
- Inside the plan card, as a small link on the tier where the deciding feature lives. Useful when one capability drives most upgrades.
- Next to the FAQ, if your pricing page has one. People who scroll that far are the most engaged visitors on the page and the least likely to be reached by anything above the fold.
What should the demo show?
The capability that decides which plan someone picks — not a tour.
Work backwards from your own upgrade path. If people move from free to paid for the analytics, demo
the analytics. If they upgrade for the team features, demo two people working. A generic walkthrough
of your product answers "what is this?", which is a question this visitor has already finished
asking.
Keep it short. Five to eight steps is plenty, and shorter is better here than anywhere else on the
site, because you are interrupting someone mid-decision rather than entertaining someone mid-browse.
If you do not have a demo to place yet, the mechanics of
creating one come first — placement cannot rescue a demo built
around the wrong workflow.
Should you gate it?
Not on this page.
A gated demo converts a visitor into a lead. That is a legitimate goal, and on a dedicated landing
page where the visitor arrived from an ad and understands the trade, it works. But on a pricing page
the visitor is already deep in the funnel and moving toward a decision on their own. Putting a form
in front of them at that moment does not accelerate anything — it adds a step, and some of them
leave instead of taking it.
The straightforward split most teams land on: open demo on the pricing page, gated demo on
campaign-specific landing pages, and a shareable link the sales team sends before a call.
How do you actually embed it?
For most tools it is a single script tag plus a container element, dropped into the page wherever
you want the demo to render. The embed guide has the exact markup and its
options, including how to control sizing and how to point the embed at a specific demo.
Two things to check once it is in:
Does it lazy-load? The embed should not fetch the demo until it scrolls into view. Your pricing
page is a conversion-critical page and it should stay fast; measure it before and after rather than
trusting that an embed is free.
Does it work on a phone? A meaningful share of pricing page traffic is mobile, and a demo that
requires precise clicking on a small screen is worse than no demo. Check what yours does at phone
width before you ship it.
Rendemo publishes demos with a one-tag embed and captures the real HTML of your product, so the
demo reflows on a phone rather than being a fixed-size image — and demos are on the
free plan if you want to test the placement idea before committing to anything. If your
pricing page demo needs to be a live sandbox environment, that is a different category of product.
What do you measure afterwards?
Not "did conversions go up", at least not first — pricing pages have too much other traffic
variation to read that cleanly at small volumes.
Measure the demo itself: how many people start it, and where they stop. A demo where most viewers
leave at step two is telling you something specific and actionable, which is more useful early on
than a conversion number you cannot attribute. Then, once you have enough traffic to trust it, look
at whether the visitors who finished the demo convert at a different rate from those who did not.
That comparison is the one worth acting on.
Top comments (0)