Share a Walkthrough as a Link — Run Guidance Live, Not in a Loom
BreakGround turns any published content item — a guide, tooltip, survey, announcement, task list, journey, even an NPS — into a shareable URL. Open it on your own domain and the SDK renders that exact piece of guidance, immediately. Replace the Loom and the screenshare; let the product show itself.
Built for support, customer success, sales, and lifecycle teams.
Why the alternatives fall short
- A Loom makes the user do the work twice: The user watches the recording in one window and tries to replicate every click in their own app in another. They juggle two screens, lose their place, and quietly give up when the UI doesn't match frame-for-frame. A share link is different — the guidance runs in their own product, on their own data. It's the difference between watching someone tie a knot and having them guide your hands.
- Screenshares don't scale past one user: Scheduling a call to walk a customer through a feature blocks the agent, blocks the customer, and produces a recording that's useless to the next person who needs the same answer.
- Written instructions get skimmed and abandoned: A six-step Help Center article asks the user to translate prose into clicks. Most users skim, miss step three, and reply to the ticket. A live walkthrough leaves no room for translation.
- Recordings rot the moment the UI ships an update: A Loom recorded against last quarter's UI shows buttons that no longer exist. The share link runs against the current product — so the guidance stays correct without anyone re-shooting anything.
How BreakGround helps
- Share any of nine content types: Guides, tooltips, beacons, surveys, task lists, announcements, NPS prompts, and journeys all generate share URLs from the same primitive. Most competitors limit shares to guides or tours; BreakGround covers the full content catalog.
- Generate from the builder or the chrome extension: Editors and support agents create share links from the dashboard builder or from the BreakGround chrome extension while sitting on the page. No context switch, no copy-pasting an ID into a separate tool.
- Instant revoke, with view tracking and audit trail: Every link records who created it, how many times it was opened, and when it was last viewed. Revoke in one click and the SDK returns a graceful 410 immediately — no waiting for cache invalidation, no orphaned links living in old emails forever.
- Runs on your production domain, not a sandbox preview: The link opens your real product, in the customer's real account, with their real data. This is end-user-facing guidance — not an admin preview mode — so the experience is identical to what the user would have hit if they'd found the content through the SDK on their own.
Deep dive
The shareable URL is, on its face, a small primitive: a token that the SDK reads from the address bar and uses to render a single content item on first paint. Nearly every digital adoption platform ships some version of it — Userpilot calls them permalinks, Pendo calls them guide URLs, Whatfix calls them guide links. What is uncommon is treating the URL as a first-class workflow for the people who actually use it most: the support agent, the customer success manager, the account executive, the lifecycle marketer.
A support agent answering a ticket about a setting that's three clicks deep does not want to record a Loom, schedule a call, or paste a six-step list. The agent wants to drop a URL into the reply, the customer wants to click it and watch the guidance run live in their own account, and both sides want the ticket closed before lunch. This is the workflow BreakGround optimizes for. Share links generate in one click from the dashboard or the chrome extension. The link works on the customer's real production domain — not a sandbox or a preview — and renders the exact guide, tooltip, or survey the agent intended. When the ticket closes, the agent revokes the link and it dies cleanly; no abandoned links rotting in inbox archives.
The same primitive carries weight in adjacent workflows. A customer success manager preparing for a QBR identifies a feature the account has under-adopted, generates a share link, and drops it into the meeting summary email — the contact opens the link and is walked through the feature in their own account. A lifecycle marketer building a drip campaign attaches a share link to each email step, so the deep-link drops the user not into a marketing page but into the product walkthrough that matches the email's promise. A product marketer launching a release uses a share link in the announcement post so anyone who clicks gets the announcement modal in-app, with full context, without having to search for it. The URL is table stakes; the operating model on top is what compounds.
Tactics
- Embed share links in your helpdesk macros: For every recurring support topic, paste the canonical share link into the macro alongside the written explanation. The next time an agent answers that question, the link goes out automatically — and the customer gets the live walkthrough instead of skimming the prose. Track view counts on each macro link to identify which topics deserve a permanent in-product guide.
- Replace Looms that go stale every release: Any recorded video against your product becomes outdated the moment the UI changes. Replace the highest-traffic Looms in your Help Center with share links that render the equivalent BreakGround guide. The guide re-runs against whatever the current UI is — when the product evolves, the guidance does too, without anyone re-recording.
- Hand each CSM a per-account adoption playbook: For every feature you want CSMs proactively pushing, pre-publish a guide and surface its share link in the CSM's tooling (Salesforce field, Notion page, internal dashboard). On every QBR or check-in, the CSM picks the right link for the account's gap and sends it. Activation lift becomes measurable per-CSM, per-account.
- Deep-link lifecycle emails to the walkthrough, not the landing page: When a lifecycle email promises 'see how to set up X,' replace the landing-page URL with a share link that takes the user into their account and runs the walkthrough. Open rates stay the same; activation off those emails climbs because the user lands inside the product already moving forward.
Common mistakes
- Sharing draft content: Share links only work for published content — the SDK rejects unpublished items. Agents who generate a link from a draft and send it discover the failure only when the customer opens the link and sees nothing. Publish first, then share.
- Never revoking, so links live forever: Share links don't auto-expire. A link generated for a one-off ticket sits in the customer's inbox indefinitely; if the underlying content changes purpose, that old link can produce a confusing experience. Build a habit of revoking single-use links once the ticket closes.
- Sharing across tenant boundaries: Links are scoped to the tenant that created them — a link generated in your staging tenant won't render in production, and vice versa. When agents move between environments, double-check the link was generated in the same tenant the customer is on.
Metrics to track
- Share link view count: Total opens per link, surfaced in the dashboard. High view counts on a single link indicate the underlying content deserves promotion to a permanently-triggered guide — the link is a discovery signal. Benchmark: Single-ticket links: 1–3 views. Macro/email links: 50+.
- Time-to-resolution on tickets with a link: Median resolution time for tickets where the agent sent a share link versus tickets without one. Faster resolution validates that the live walkthrough is genuinely deflecting back-and-forth. Benchmark: Healthy: 25–40% reduction vs. text-only ticket replies.
- Activation lift on lifecycle email cohorts: Activation rate for users in an email cohort that received share links versus a control cohort that received landing-page links. Quantifies how much of the lifecycle program's lift is the email versus the in-product follow-through. Benchmark: Strong programs: 10–25% activation lift on click-through cohorts.
- Revocation rate: Percentage of links that get explicitly revoked. Low rates can indicate hygiene drift (old single-use links living forever); very high rates can indicate links are being treated as one-shot when a permanent guide would serve better. Benchmark: Healthy ops: 60–80% of single-use support links revoked within 30 days.
Frequently asked questions
How is this different from Pendo guide permalinks, Appcues permalinks, or Whatfix guide links?
The URL primitive itself is table stakes — most major DAPs ship some version of it. BreakGround's differences are operational rather than mechanical: share links cover all nine SDK content types instead of being limited to guides and tours; generation is first-class in the chrome extension so support agents can create a link without opening the dashboard; every link has built-in view tracking, audit, and instant revocation; and the workflow is designed for support, CS, and sales teams — not just builders. If your team uses share links the way support teams actually want to (drop in a ticket, revoke when done, measure deflection), the surface area matters more than the URL.
Does the recipient need to be logged in to use a share link?
The recipient needs to be on your product's domain in their normal authenticated session — the share link opens your real production app, not a public preview. The link token itself does not authenticate the user; the user's existing session does. If they're not logged in, they'll hit your normal login flow first, and the guidance renders once they're inside. Token possession does grant access to the specific shared content, so treat links the way you would any URL containing a token — fine to email a customer, not fine to post publicly.
Can a share link expire automatically?
Not in the current version — links persist until manually revoked. This is a deliberate choice so that links embedded in helpdesk macros, evergreen emails, or Help Center docs don't quietly break. For one-off support tickets, the recommended pattern is to revoke explicitly when the ticket closes; the dashboard makes this a single click. Auto-expiry by date or single-use mode are on the roadmap based on customer feedback.
What happens after I revoke a link?
The SDK returns a 410 Gone response the next time anyone opens the link, and no content renders. The end user sees a graceful fallback on your page rather than a broken or stale experience. Analytics for the link continue to be preserved — view count and last-viewed timestamp remain visible in the dashboard, so you can audit usage even after the link is dead.
