How to build an interactive demo: capture, clone or sandbox

An interactive demo works when a visitor can reach one useful moment in your product within a few minutes, on their own, without booking anything. Building one comes down to a short list of choices: how you reproduce the product, which steps to include, what sample data to show, whether to branch, where to embed it, and how you keep it current. This guide takes them in order, then covers what changes when an AI agent asks the visitor who they are first. For the broader question of what any product demo should prove, read how to build a product demo that converts.

What is an interactive demo, and when do you need one?

An interactive demo is a version of your product that a visitor can click through on their own, usually on your website or in an email. You need one when visitors want to see the product before they talk to anyone. If nearly all your deals start in outbound and a founder-led call closes them, a good live demo and a recording are cheaper and probably enough.

A recording plays at the viewer. An interactive demo waits for the viewer to act, so every click needs somewhere to land. That is where the build cost comes from.

Should you capture, clone or use a sandbox?

Choose by how much of the product a visitor needs to touch and how often the product changes. The three approaches sit on one line: the further along it you go, the more freedom the visitor has and the more you maintain.

• Capture. You record real screens as screenshots or HTML snapshots and connect them with steps and hotspots. It is the quickest to build and fits a stable product with one story to tell. The visitor follows the path you laid down, so a click you did not plan for has nothing behind it, and every captured screen goes stale when the UI changes.
• Clone. You copy the interface into something that responds to clicks, so the visitor can wander a little. It takes more work up front. The payoff is that off-script clicks land somewhere sensible, which matters when your product has a lot of surface area. It is still a copy, and a copy drifts.
• Sandbox. A real running instance of the product loaded with sample data. Visitors can do real work in it, which suits technical evaluators and complex products. It carries the most upkeep: seeding the data, resetting it between visitors, and keeping anything private out.

Start with capture if your product is stable and you have a single story. Move to a clone or sandbox when buyers keep asking to try something the capture cannot show.

Which flow and steps should the demo include?

Pick the one flow that answers the buyer's biggest doubt, and write it as four lines before you capture or build anything.

• Start state. What the visitor sees when the demo opens.
• Key step. The one action that moves them toward the proof.
• Proof moment. Where the value becomes obvious: a task moved to done and the dashboard updating, a messy CSV coming out clean.
• End state. What the demo closes on, and what the call to action asks for.

If you cannot write those four lines cleanly, you do not know the demo yet. Anything that does not move the viewer toward the proof moment is filler: login screens, loading spinners, settings pages, navigation that only makes sense inside the live app. Who the viewer is and which objection the flow answers are covered in the product demo guide, so settle those first.

How do you set up steps and hotspots?

Give each step one action and one sentence, and put the hotspot on the control a buyer would really click.

• Hotspot on the real control. A hotspot is the clickable area that advances the demo. Place it on the button, row or menu item the visitor would press in the product. Use a generic Next button only when there is no real action to point at.
• One sentence per step. The caption says why the step matters, not what to click. "Click Reports" is a label. "Finance can see which accounts are at risk without asking anyone" is a reason.
• A plan for stray clicks. Decide before launch what happens when a visitor clicks outside the hotspot. Either nudge them back with a short hint or let the click through when the screen exists. A silent dead click reads as a broken demo.

What sample data should the demo show?

Use made-up company and people names, masked emails and numbers that add up, and keep them the same across screens. If the dashboard says 47 active users, the people list should not show 12 rows.

Keep state consistent too: if step two shows a project as on track, step five should not show it overdue. Check dates. A captured "updated 3 days ago" label reads wrong the day after you capture it, so use fixed dates. And look past the main panel for real data: avatars, comment threads, URL bars and browser tabs leak customer names more often than tables do.

When should you branch the demo?

Branch when two kinds of buyer need different proof, and not before. Branching multiplies the build: a flow with five shared steps and two branches of three steps each is eleven steps to build, caption and test, against five for a single path. Every later UI change touches each branch that shows the screen.

Start with one path and let two things tell you when to split: a pattern in where viewers leave, and what your sales calls reveal about who is watching.

Someone also has to choose the branch. A "which describes you?" menu works, but the visitor is sorting themselves into buckets you defined in advance.

How do you embed it, and where?

Put it where the visitor is already asking whether this does what they need: the pricing page, a feature page, or the homepage next to the product claim. Embed it inline, in a modal or on its own page, and test it on a phone, where a fixed-width layout that clips is the usual failure.

In email, link to a hosted page rather than trying to embed the demo, and for outreach send a link per prospect. How that works for outbound has the details, and the marketing page covers using demos on your site.

On gating, our view is to let the visitor reach the first step before you ask for anything, and to ask for an email after the proof moment, when they have a reason to give it. That is an opinion, not a measured result.

What should you measure?

Track starts, completion, drop-off by step and clicks on the final call to action, and read drop-off by step first. If most viewers leave at the same step, that step is either confusing or filler, so fix it or cut it.

These numbers tell you where people left. They do not tell you who they were or what question they had when they left. A tour has no way to ask.

How do you keep an interactive demo current?

Treat it as a copy of your product, because it is one, and a copy drifts on the next release. The approaches differ only in what each drift costs.

Say you rename "Deals" to "Pipeline" in the sidebar. In a capture, every screen that shows the sidebar needs recapturing. A clone needs the change made in the clone. A sandbox follows the product but its sample data and flows need another look. Four habits keep the cost down whichever you pick.

• Keep a screen inventory. List which steps show which parts of the UI, such as the sidebar or header, so a release tells you what to recheck.
• Store each screen as its own asset. One changed label should mean recapturing one screen, not rebuilding the flow.
• Put it on the release checklist. If a release touches a screen in the demo, someone checks it that day.
• Name one owner and date every review. A demo owned by the whole team gets updated by nobody, and anyone should be able to say when it was last compared with production.

Before launch, and after any release that touches the flow, have someone who did not build it click through cold. Check that every hotspot leads where it should, every label matches the live product, no screen shows a blank or loading state, the images load on a slow connection, and the final call to action points at the right URL.

What changes when an agent qualifies the visitor first?

You stop authoring branches and start authoring what an agent works from. An AI demo agent asks the visitor's role and goal, decides what to show based on the answers, walks them through the product, and answers questions as they come up. The branching menu and the extra variants become the agent's job.

What you build maps to the three stages. For Qualify, choose the two or three things you need to know before the demo starts: role, what they are trying to get done, what they are evaluating. For Guide, name the workflows and proof that go first for each kind of answer. For Convert, decide what counts as ready and what happens then. What the visitor asked, clicked and lingered on goes to sales as buyer intelligence, so the first call starts warm. The how it works page walks through the stages in order.

This does not remove the work above. The agent still needs a proof moment to build toward, sample data that holds together and a product experience that stays accurate. Inkly starts from your existing product materials, key workflows, existing demos and approved messaging, then runs a guided validation before anything goes live. Some buyers also want a person early, so a handoff at the right moment is part of the job.

Where does Inkly fit?

We make Inkly, so weigh this section accordingly. Inkly is the AI demo agent that turns website visitors into buyers. It qualifies the visitor, guides them through the product live, answers questions in context and hands buyer intelligence to sales.

Every plan includes the voice and chat demo agent, and plans are priced by active visitors, where one person counts once a month. Free is $0 for 30 visitors. Pro starts at $150 a month ($120 a month billed yearly) for 150 visitors and adds visitor details, a demo tailored to each prospect and lead qualification. Enterprise is custom and adds the clickable product clone, live product streaming and the CLI. The clone is a clickable copy of your product. Live streaming has the agent drive your real, running product instead. The pricing page has the full table.

If you need one tour on a stable product for one audience, a standalone interactive demo tool or a recording may serve you better. The comparison hub lays out how the categories differ.

FAQ

Can you build an interactive demo without engineers?

A capture can usually be built by a founder or marketer. A clone or sandbox usually needs engineering time for the build and for the sample data.

How is an AI demo agent different from an interactive demo?

An interactive demo shows every visitor the path you scripted. An AI demo agent asks who the visitor is, adapts what it shows and answers questions as they come up.

How is an AI demo agent different from a chatbot?

A chatbot talks about the product, while a demo agent also shows it. The AI demo agent vs chatbot page goes through the difference.

What should you do this week?

Write the four lines for one flow, build it as a capture, and put it on the page where visitors ask whether the product does what they need. Then ship a small UI change and see how much of the demo it breaks. That tells you what upkeep costs in your case. After a few weeks, read drop-off by step and ask your sales team how many of the people who finished it were not the buyer you built it for. If that number is large, it is time to qualify first.

See how Inkly works: how the agent qualifies a visitor, guides the demo and hands sales the context.