DEV Community

Jacob Gargaro
Jacob Gargaro

Posted on Originally published at rendemo.com

How to Personalize a Sales Demo Without Rebuilding It

To personalize a sales demo, change the data and the vocabulary — the record names, the field labels,
the units the buyer actually uses — and leave the rest alone. That is the part that makes someone stop
translating your example into their own world. The logo in the corner is cheap theatre, and buyers
worked that out years ago.

The harder question is not how to personalize one demo. It is how to personalize without ending up
with fourteen variants that all go stale on the same Tuesday.

What is actually worth personalizing?

Two things, in order.

The data. A demo of an invoicing product showing "Acme Corp — $1,200" is a demo about software. The
same demo showing three suppliers from the buyer's own industry, with amounts in the right currency
and the right order of magnitude, is a demo about their job. This is the highest-leverage change
available and it is almost always the one skipped, because it takes real effort to find out what a
plausible record looks like in someone else's business.

The vocabulary. Every industry has its own word for the same object. If your product calls it a
"deal" and their team calls it a "matter", every screen makes them do a small translation. Enough
small translations and the demo becomes work.

Both of these come out of discovery. If you have not done discovery, you do not have the raw material
to personalize with — which is the honest reason most "personalized" demos are just a logo swap.

Which parts should stay generic?

The cosmetic layer. Their logo in the corner, their brand colour on the button, their company name in
the welcome step.

None of this is harmful and it costs almost nothing, so do it if the tool makes it a text field. Just
do not count it as personalization, and do not let it consume the time that should have gone into the
data. A prospect who sees their logo on a workflow that has nothing to do with them concludes you ran
a mail merge, which is worse than a clean generic demo.

Also leave the narrative alone unless discovery told you to change it. The temptation is to
restructure the whole demo per account. Structure is the part you have tested and the part that
works; the buyer's context should change what is on the screens, not the order you show them in.

How do you personalize without rebuilding the demo?

This is where the capture method of your tool decides what is possible.

If the demo is built from screenshots, the text in it is pixels. You can lay new text on top of the
image, but you cannot change what is inside the product view — so meaningful data personalization
means re-taking the screenshots for every variant. That is why on screenshot tools, personalization
in practice collapses to the cosmetic layer.

If the demo is built from your product's real HTML, the text is text. Names, labels and values can
be edited after capture without going back to the recording, which is what makes a per-industry
variant a ten-minute job instead of a re-shoot.

The second lever is variants built into the tool rather than into copies. Persona variants let one
demo show a different path depending on who is watching; branching lets the viewer choose. Both are
on Rendemo's Pro plan at $39/mo flat for the whole workspace. It is worth knowing what
this costs elsewhere before you assume it is standard: Storylane puts A/B testing on
its Growth plan at $625/mo, and its per-seat model means the people building variants each carry a
licence. Storylane also does things Rendemo does not — sandbox demos, visitor account reveal — so if
those decide your evaluation, the price comparison is not the whole story.

What does personalization cost you later?

Every variant is a maintenance multiplier, and this is the part nobody puts in the sales deck.

One demo, one re-record when the product changes. Twelve variants, twelve re-records — except it is
worse than twelve, because nobody remembers which twelve exist or which ones a rep sent last quarter.
The library that felt like sophistication in month two is the reason the whole programme is abandoned
in month nine, when someone opens a demo mid-call and it shows a navigation bar that no longer exists.

Two habits keep this survivable.

Build a variant only when the content differs, not when the account differs. A variant for
"healthcare" earns its place because the data and vocabulary genuinely change. A variant for
"Northwind Health specifically" usually does not.

And attach every variant to the same review trigger as the original — this is the whole subject of
keeping a demo up to date, and variants are where that
discipline breaks first, because they are the ones nobody feels ownership of.

When is a generic demo the better call?

Whenever you do not actually know who is watching.

A demo embedded on your pricing page is seen by strangers. There is nothing to personalize with, and a
guess is worse than nothing — a demo pitched at the wrong persona reads as a demo for someone else.
Put your strongest, broadest workflow there and let it do the qualifying. That is the standard-issue
walkthrough discussed in demo automation for sales, and it is
supposed to be generic.

Personalization earns its cost at exactly one point in the cycle: after discovery, before the
technical evaluation, when you know enough about the account to change the data with confidence and
the deal is worth the half hour. Before that you are guessing. After that, the buyer is talking to
your engineers and no longer cares what the sample records are called.

If you are building the underlying demo now, get the structure right first —
how to create a product demo covers choosing the one job it
should show. A personalized demo of the wrong workflow is still the wrong demo, in the buyer's own
vocabulary.

Top comments (0)