From sales demo to onboarding asset: making walkthroughs work twice

The triple-record problem

Tuesday, 2:14 PM. An AE on the data-platform team finishes a 22-minute Loom for a late-stage prospect, walking through the "ingest a CSV, build a dashboard, share with a stakeholder" flow. He titles it `Acme - Custom Walkthrough v2 FINAL.mp4` and drops the link into the deal thread.

Wednesday, 10:30 AM. The deal closes. A CS manager opens a fresh recorder, navigates to the same ingest screen, and records a "Welcome to your workspace" walkthrough for the kickoff call. Same flow. Different intro. Different narration. The Loom from yesterday is irrelevant — wrong audience, wrong tone, wrong CTA at the end.

Thursday, 4:45 PM. A product marketer on the docs team needs screenshots for a help-center article titled "Importing your first dataset." She opens the same screen, takes nine screenshots, annotates them in Figma, and writes 600 words around them.

Three people. Three recordings. Three rot timelines. When engineering ships a redesign of the ingest screen six weeks later, the AE's Loom looks dated on the next deal, the CS manager's walkthrough confuses every new customer for two weeks until somebody flags it, and the help-center article sits with stale screenshots for a quarter because nobody owns it cross-functionally.

This is the triple-record problem. The same flow, captured three times, owned by three teams, breaking on three different schedules. It is the most expensive habit in B2B sales enablement walkthroughs, and almost nobody talks about it.

Why teams default to triple-recording

If sharing one asset is so obviously cheaper, why does every B2B company over fifty employees do this?

Four reasons, in roughly the order they bite:

• Asset format mismatch. Sales wants a Loom they can paste into a Gmail thread and watch on 1.5x. Onboarding wants an interactive walkthrough that fires inside the product on day one. Docs wants annotated stills that render in a markdown article and get indexed by search. Same flow, three output formats, and most tools are good at exactly one.
• Ownership boundaries. Sales doesn't trust marketing-built demos because they're "too polished" — too generic, no objection handling, no use-case framing. Marketing doesn't trust sales-built demos because they bury the value prop under three minutes of "let me find the right tab." Each team rebuilds rather than negotiate.
• "It's faster to re-record than to ask." Asking the marketing ops person which folder the canonical walkthrough lives in, whether it's been updated for the v4 navigation, and whether the narration matches the new pricing page — that takes twelve minutes. Re-recording takes nine. The math always wins.
• Tools that are great for one stage, hostile to the others. Loom is great for sales. Pendo is great for in-product onboarding. A Notion doc with screenshots is great for the help center. Stitching them together so a single capture feeds all three is, at most companies, somebody's manual job that nobody does.

What a "twice-working" walkthrough looks like

Twice-working — really thrice-working — means one underlying capture with audience-specific overlays. The DOM trace, the click sequence, the screenshots: captured once. Everything layered on top is per-surface.

Concretely, the affordances you need:

• Single source-of-truth capture. One recording of the actual click path through the live app, stored as structured steps (selectors, screenshots, intermediate states), not as a baked-in MP4.
• Configurable narration per audience. Sales-version narration leans on objection handling and proof points. Onboarding narration assumes the viewer just signed a contract and needs to do the thing. Docs narration is terse, scannable, and SEO-aware. Same steps, three voiceovers or text overlays.
• Branching for use-case-specific paths. A 12-step capture might be steps 1–4–6–9 for the analyst persona and 1–2–3–10 for the admin persona. Branching off a shared base beats maintaining four parallel walkthroughs.
• Multiple embed surfaces from one source. The same demo renders as: a hosted page link in a sales email, an in-app modal triggered by a Pendo-style guide on day three, an iframe embed in a help-center article, a static MP4 export for the prospect who just wants to forward it.
• Audience-targeted CTAs. Sales ends on "book a follow-up." Onboarding ends on "now try it yourself." Docs ends on "see also: configuring permissions."

The asset stops being a video file. It becomes a structured demo object with surface-specific renderers.

The handoff workflow

Here is what the workflow looks like when the underlying capture is shared instead of re-recorded. Each row is one phase, one owner, one artifact.

Two non-obvious accountability rules make this work:

The AE owns the base capture, not the marketing team. The deal-specific recording is what kicks off the chain, because that's where the freshest, most-realistic click path comes from. Sales is closer to "what does this product actually do for a customer" than marketing is on most days.

CS and PMM fork rather than re-record. Forking is cheap, takes under five minutes, and preserves the link back to the source. Re-recording resets the rot timer and breaks the maintenance chain.

Maintenance discipline

Twice-working demos have a doubled blast radius when they break. A stale Loom embarrasses one AE on one deal. A stale base capture, embedded in three surfaces, embarrasses you on every deal, every onboarding, every help-center search hit until someone notices.

This is why maintenance discipline matters more for shared walkthroughs than it does for one-off recordings. Two practices to bake in:

• Automated drift detection on the base capture. The walkthrough tool should run the click path against a staging or production environment on a schedule and flag broken selectors before a customer sees them. If your tool can't do this, your "single source of truth" is a single source of failure.
• Alert routing across teams. When a step breaks, the alert can't go only to whoever recorded it. Route it to a shared channel — `#walkthrough-health` or similar — with the embed surfaces listed, so the AE knows their email demo is stale, the CSM knows the day-one modal is broken, and the PMM knows the help-center article needs an update.

Without these, the second time the underlying app changes, the twice-working demo concept dies a quiet death and everyone goes back to triple-recording.

Metrics: did the demo actually earn its keep?

One demo, three scoreboards. Don't try to merge the KPIs — each surface is solving a different problem.

Across all three, track one shared metric: how often the same base capture appears in deal cycles, onboarding flows, and indexed help articles in the same week. That's the reuse number. If it's low, you don't have a sales-to-onboarding handoff — you have three teams pretending they do.

How Heal Demo fits

We built Heal Demo around demo reuse because triple-recording was the pattern we kept seeing on customer calls. The browser-extension recorder captures one base, the web editor lets sales, CS, and PMM fork it with their own overlays, and the same capture embeds into emails, in-app modals, and help-center articles.

The unlock, honestly, was the Playwright-based healing agent. Without it, the twice-working demo concept dies on the second UI change — three surfaces all break at once and you're worse off than when you were re-recording. With healing, the base capture patches itself when selectors drift, the alerts route to the right team, and the asset actually earns its keep across the funnel.

If your sales enablement walkthroughs and onboarding tours are currently three separate recordings of the same flow, the fix is mostly workflow, partly tooling. Either way: stop recording the same thing three times.