Your approval-workflow page promises fewer back-and-forth emails. But a buyer reading it still can’t answer a basic question: what happens when a manager sends a request back for correction? That’s a good reason to embed a demo. Having a spare product tour isn’t.
To embed an interactive demo on your SaaS website, create a focused walkthrough and add it to the relevant page using your demo platform’s supported embed method. Place it beside the claim it demonstrates, provide a direct-link fallback, and test the published experience on desktop and mobile. Measure whether visitors understand the workflow and take a useful next step—not just whether they click through.
Dale, the interactive demo platform, lets teams capture product screens without code, turn them into self-guided demos, and embed them on websites or landing pages. The harder decision comes before publishing: which part of the product deserves a visitor’s attention?
Which page should you embed an interactive demo on?
I’d usually start with a feature or use-case page, not the homepage. The narrower the promise, the easier it is to show something convincing.
A homepage visitor might be researching the category, checking your credibility, or looking for the login button. Someone reading about approval routing has already given you more context. Show them a request moving through that process, including what happens when it doesn’t go as planned.
| Page | Question to answer | Demo scope |
|---|---|---|
| Feature page | How does this actually work? | One workflow and its result |
| Campaign landing page | Can you deliver what the ad promised? | The use case named in the campaign |
| Industry page | Does this fit our process? | A workflow with relevant terminology and constraints |
| Homepage | Is this relevant to my team? | A brief introduction or clearly labeled audience paths |
Don’t distribute the same general tour across every feature page. That transfers the work to the buyer: they now have to hunt through your walkthrough for the capability they came to see.
What should your embedded demo show?
Write the buyer’s question before capturing screens. “Show approval management” is a topic. “Can a manager return an incomplete request without losing the discussion?” is a demo brief.
For that second question, start with a submitted request. Show the manager identifying the missing detail, returning it with a comment, and the employee seeing what needs changing. Finish where the buyer can see that the request history remains available. Account setup and dashboard navigation probably don’t belong in this story.
Use realistic sample data. A request labeled “Test 123” makes visitors translate the interface into their own situation. “Replacement laptop—missing cost center” gives them enough context to follow the problem without a separate explanation.
Should you use a single-experience, linear, or branched demo?
A single-experience demo for one focused feature is a sensible starting point when the page makes one promise. There’s less content to review, and you can tell whether the walkthrough answers the question.
Use a linear demo when sequence matters. A reporting example may need to move from selecting a source to filtering records to interpreting the result. Cut steps that merely reproduce navigation; keep those that explain cause and effect.
A branched demo with role or use-case choices fits a page serving genuinely different audiences. Finance might want to review spending, while operations wants to resolve stalled requests. Label those choices with familiar tasks, not internal module names. Branching should spare visitors irrelevant content, not give them another menu to decipher.
How do you embed an interactive demo in your website?
Separate building the experience from installing it. No-code screen capture doesn’t mean every publishing step is no-code; your CMS, permissions, and security configuration still matter.
- Prepare the workflow. Capture a representative starting state, the meaningful actions, and the outcome. Remove customer details, credentials, internal notes, and anything else that shouldn’t appear on a public page.
- Write guidance that adds context. “Select Return” repeats a button label. “Return the request with a comment so the employee knows what to fix” explains the action. Keep instructions short enough to read while using the interface.
- Choose the next destination. After the walkthrough, should the visitor inspect a related capability, start a trial, or discuss requirements with sales? Match that choice to the page’s intent, whether the action sits inside the demo or alongside it.
- Get the supported embed instructions. Use your platform’s documented method. Don’t turn a share URL into improvised embed code and assume it will behave correctly.
- Add it to a staging version of the page. Your website owner should use the CMS area appropriate for the supported method. Check dimensions, surrounding content, and any restrictions on third-party embeds.
- Publish, then test again. A CMS preview won’t necessarily reproduce the live site’s consent controls, security headers, or other scripts. Check the actual URL before announcing the page.
With Dale, the same captured-product walkthrough can be embedded or shared by link. Put a clearly labeled direct link near the embed as a fallback. It gives visitors another route if the embedded version fails, although it won’t solve every browser or usability problem.
For the website handoff, include the page URL, intended position, supported implementation instructions, fallback link, and reviewer. Add the acceptance criteria too: “usable on mobile, no sideways page scrolling, final link tested.” That’s more useful than “please add this demo.”
Where should the demo sit on the page?
Put it close to the claim it proves. If a section explains how managers resolve exceptions without email, that is a natural home for the request-correction walkthrough.
I wouldn’t automatically give the first screen of every page to a large interactive embed. Visitors need a reason to use it. A short explanation followed by “See how a manager returns an incomplete request” sets a clearer expectation than “Explore our platform.”
Keep the essential explanation outside the demo. Someone who never interacts should still understand the problem, what your product does, and why the result matters. Captured screens shouldn’t carry the page’s entire argument.
Then inspect the surrounding distractions. A chat window covering the controls or a sticky signup banner squeezing the viewport can spoil an otherwise useful experience. Review the page as a visitor sees it, not as separate components owned by different teams.
What should you test before publishing an embedded demo?
Can someone actually use it on a phone?
“It fits” isn’t a usability test. A desktop interface can shrink into a phone viewport while leaving every label too small to read.
On a real device, start the walkthrough, follow its instructions, scroll the surrounding page, and leave the experience. Watch for awkward interaction targets and competing scroll areas. If the workflow is too dense, reconsider its scope or offer a separate viewing link. Test that destination too; opening a new page doesn’t magically make desktop UI readable.
Does the embed change page performance?
Compare the page before and after implementation. Check whether content jumps as the demo loads, whether the page becomes slow to respond, and whether other third-party scripts make the problem worse. Include a slower connection in testing.
Ask your developer whether the supported implementation permits deferred loading or a click-to-load approach. These are options to verify, not capabilities to assume. Reserve appropriate space so the experience doesn’t push the paragraph someone is reading down the page.
What happens with keyboard access, consent, and security?
Try entering and leaving the demo with a keyboard. Check focus visibility and whether users can reach the content after it. If parts of the experience aren’t accessible, provide a useful explanation outside the embed and another way to get help. Don’t treat that as a substitute for fixing accessibility barriers.
Ask your privacy owner to review the actual implementation: which scripts or cookies are involved, what requires consent, and what happens when consent is declined. An embedded experience doesn’t necessarily inherit your website’s settings.
If the demo fails to load, have the developer inspect CMS restrictions and the site’s content security policy. Adjust the approved configuration rather than switching protections off broadly. For platform-specific questions, consult the Dale help desk rather than guessing.
Before signing off:
- The first screen delivers on the invitation beside it.
- All visible data is safe for public viewing.
- Mobile and keyboard journeys have been tested.
- The page remains useful when the embed is unavailable.
- The fallback link and intended next action work.
- Someone owns both content accuracy and website behavior.
How do you know whether an embedded demo is working?
Pick the business question before choosing the metric. For a feature page, you might ask whether visitors who interact go on to request a relevant sales conversation. For a campaign page, you might want to know whether people engage with the specific workflow the ad promised.
Keep page visits, demo views, starts, completions, and downstream actions separate. They describe different behaviors. Use website analytics for page-level outcomes and the demo platform for the interactions it records; don’t assume those datasets connect automatically.
Dale’s buying intent signals for demo engagement show who viewed, started, or completed demos, clicked links, and downloaded documents. That evidence can help sales choose a relevant follow-up. Completion alone isn’t a purchase decision.
For example, a prospect who downloads an approval-policy document may appreciate a conversation about their approval rules. They don’t need a generic “noticed you were interested” message that ignores what they explored.
A low completion rate deserves investigation, not an immediate rewrite. Perhaps the guidance is confusing. Perhaps the mobile experience is poor. Or perhaps the buyer saw the answer halfway through and left satisfied. Pair the available behavioral evidence with usability testing and the questions sales still hears.
Likewise, few starts may indicate weak placement or a vague invitation. Change one major variable at a time where traffic allows, and record the change. Otherwise, you won’t know whether the new workflow helped or the clearer introduction did.
How do you keep the demo accurate after launch?
Assign a content owner and a website owner, even if they’re the same person. Keep a simple inventory of where each demo appears and which product workflow it represents. Review it when releases change interface labels, behavior, or the promise made on the page. A walkthrough can load perfectly while showing a process buyers can no longer follow.
Start with one high-intent page. Ask a sales or pre-sales colleague for the question buyers still ask after reading it, then write a walkthrough brief that answers only that question. Bring that brief—not a sprawling platform tour—to your next review with the website owner.