Demo Agent SetupCopy link to this section

Setting up the demo automation agent takes about 20 minutes once you have your site configured. The agent needs content to know your product and capabilities to structure what it shows.

PrerequisitesCopy link to this section

Before configuring the demo agent, make sure you've completed these steps:

Site created: You need a site in the dashboard pointed at your product's URL. See Sites if you haven't done this yet.
Content ingested: The agent's product knowledge comes from your documentation. Add at least your docs site and one other content source (knowledge base, videos, etc.) via ingestion.
Demo context prepared: Capabilities tell the agent what your product can do. Floe prepares them internally after ingestion; generated capabilities must be refreshed internally when your source content changes. See Capabilities.

If you haven't completed these steps, follow the Quickstart first. The demo agent won't have enough context to run a useful session without all three in place.

Configuring the demo experienceCopy link to this section

Open Demo Agent → Configure in the dashboard. The page has six cards, and each card saves independently:

Languages & voices picks which languages this agent speaks and the voice for each. English only, unless you enable Hindi. This is where the session's voice comes from — not the Persona card. See Languages & Voices.
Persona & tone controls this agent's identity, tone, answer length, and pace. Warm Guide is the default; Witty Peer, Crisp Expert, and a 500-character custom tone are also available. Identity is optional (120 characters), answer length defaults to Medium, and pace defaults to Brisk.
Video avatar enables or disables the live presenter shown alongside the demo. It is off by default, and takes effect only when avatar support is enabled for your deployment — otherwise sessions run with voice alone. Talk to us if you want it on.
Discovery & Opening selects None (the default), BANT, MEDDIC, MEDDPICC, Challenger, SPIN, Sandler, Gap Selling, or a custom framework of up to 2,000 characters. Add up to eight qualification questions (240 characters each). The agent weaves them across the demo and asks at most one before showing the product.
Ask for their details controls whether identity capture is enabled, when it appears, and which fields it asks for. It defaults to email and name, asked Before the demo starts. Deferred timings include after the intro, after the first feature, when a full walkthrough is requested, and at the end before the calendar. Deferred capture can ask for email, name, company, and role; at least one field must remain selected.
Opener chips are the one-tap starting points shown when the demo connects. Add, reorder, or remove up to six chips (100 characters each), or leave the list blank to derive suggestions from your guides.

Logo, accent color, and the booking CTA are shared across agents and live in the site's Settings, not on this page. The capabilities and workflows available to the agent come from Floe-prepared capabilities and guides rather than a featured/hidden list on Configure.

The agent runs against a live instance of your product, signed in as an account you provide. This is configured under Settings → Product credentials, not on the Configure page.

Demo/App Domain — the origin the demo starts on. This one lives under Settings → General → Domain Configuration, not on the credentials tab. Use a demo environment or sandbox, never production. Left blank, Floe falls back to the login URL's origin and then your primary domain.
Login URL — where the agent signs in.
Demo account email and password — the account the agent uses. Credentials are encrypted at rest.

The first time you enter a demo account email, Floe rejects the save unless you tick the confirmation that you're authorized to let an automated agent sign in as this account. Once a site is attested, later edits — rotating the password, changing the login URL — save without re-asking.

Add credentials after the site exists, not while creating it. The create-site dialog has fields for them, but saving credentials requires the authorization step above, which that dialog doesn't ask for. Leave them blank there and fill them in from Settings once the site is created.

Two limits worth knowing before you pick an account:

The demo agent's sign-in does not complete an MFA challenge. Prefer an account with MFA disabled. The TOTP Secret field on this card is not dead — content ingestion uses it to crawl an MFA-protected product — but it does not get the demo agent past a challenge.
A magic-link-only account will not work for demos. Magic Link is selectable and is used by content ingestion, but the demo agent's session refresh still requires a stored password, so a magic-link-only site never gets a signed-in demo browser.

The agent acts as this user. It will not invite or remove people, change permissions, connect integrations, or send messages — but it can create and modify data, so give it a low-privilege account in an environment you don't mind it writing to.

Invest time in your demo data. An empty state kills momentum. The best demo environments have realistic sample data that makes features look like they're already in use.

Integrate with a coding agentCopy link to this section

Paste this into your coding agent after replacing the two placeholders with the values from your site settings:

Integrate Floe's Demo Agent into this website.

Requirements:
- Use Floe's hosted browser SDK at https://cdn.floe.so/floe-sdk.iife.js.
- Load the SDK and a same-origin /floe-init.js file as external deferred scripts, in that order. Do not add inline JavaScript.
- In /floe-init.js, initialize Floe exactly once with clientKey: "YOUR_CLIENT_KEY", demoMode: true, demoSiteId: "YOUR_SITE_ID", and embedMode: "docked".
- Keep the object returned by Floe() in a const named floe.
- If the site has a "See it live" button, wire it to await floe.requestDemo(). Preserve the site's existing booking or navigation fallback when that method returns false.
- If the docked embed should catch desktop exit intent, add exitIntent: true or an object with the desired dwell and top-edge threshold. Do not use exit intent with a fullscreen embed or start a session from the exit signal.
- Do not set websiteAgent. Do not add product API access or host-page DOM capture; this mode drives Floe's server-side demo browser.
- If the framework owns a client-side mount lifecycle, initialize once in the site shell and call floe.disconnect() only when that integration is permanently unmounted.
- Report the files changed and how to verify the docked pill, CTA, microphone flow, fallback, and teardown.

Canonical embedCopy link to this section

Add the two external scripts near the end of <body>. Keeping initialization in your own file works with a strict Content-Security-Policy:

<!-- Allow https://cdn.floe.so in script-src. -->
<script src="https://cdn.floe.so/floe-sdk.iife.js" defer></script>
<script src="/floe-init.js" defer></script>

// /floe-init.js — served from your own origin
const floe = Floe({
  clientKey: "YOUR_CLIENT_KEY",
  demoMode: true,
  demoSiteId: "YOUR_SITE_ID",
  embedMode: "docked",
});

floe.ready.catch((error) => console.error("Floe failed to initialize", error));

document.querySelector("#see-it-live")?.addEventListener("click", async () => {
  if (!(await floe.requestDemo())) {
    window.location.assign("/book-a-call");
  }
});

requestDemo() resolves true only when a mounted agent handled the request. Keep the fallback: a site without a runnable demo, an invalid configuration, or an SDK that did not boot should never leave the visitor with a dead button.

Add exit intent to a docked demoCopy link to this section

Exit intent can re-open the docked intro pill when a desktop visitor moves to leave. It is off by default and is not available in fullscreen mode:

const floe = Floe({
  clientKey: "YOUR_CLIENT_KEY",
  demoMode: true,
  demoSiteId: "YOUR_SITE_ID",
  embedMode: "docked",
  exitIntent: {
    minTimeOnPageMs: 5000,
    thresholdPx: 20,
  },
});

exitIntent: true uses those defaults. The automatic desktop detector can surface the pill only once for that SDK instance/page. This does not start a paid demo session, request microphone permission, or send a visitor turn. The visitor still has to interact with the pill before a session can begin.

For a customer-owned mobile or funnel signal, call showExitIntent() after floe.ready. Use enableExitIntent(options?) or disableExitIntent() to change automatic detection at runtime; disabling it leaves the manual method available. See Browser SDK: Exit intent for examples and return values.

Runtime configurationCopy link to this section

clientKey (string, required) is the public browser key from site settings.
demoMode (true, required) selects the Demo Agent. If both agent flags are present, demo mode wins.
demoSiteId (string, required) selects the product site whose demo browser should start.
embedMode ("docked" or "fullscreen") defaults to "docked". Use "fullscreen" only when the entire page is dedicated to the demo.
exitIntent (true or object) is available only with embedMode: "docked". It opts in to a one-shot desktop top-edge prompt and accepts enabled, message, minTimeOnPageMs, and thresholdPx; custom message copy is used by the Website Agent, while a docked demo simply expands its intro pill.
prospectEmail (string) pre-fills the work-email step; it does not start a paid session. The prospect must still act before a session starts. A submitted address is attached to that demo as a contact claim, not used to merge visitor histories.
userInfo (object) can pre-fill current-session prospect context such as name, company, and designation (shown as role). It is unsigned browser input, so it does not verify the prospect or unlock history from another browser.
demoCalendarLink (string) overrides the booking URL configured for the site. It must use HTTPS; Floe does not append prospect identity or contact-claim data to it.
enableAudio (boolean) defaults to true; debug (boolean) defaults to false.

See the Browser SDK for the shared API and lifecycle methods.

Creating and publishing a demo linkCopy link to this section

Create prospect-facing demos from Demo Agent → Demo Links:

Click New demo link.
Optionally add the prospect's name, work email, company, and role. You can also override the site's booking link with an HTTPS URL or set an expiry date.
Click Create preview link. Every new link starts as a private preview.
Open the preview and QA the complete experience before sharing it.
Publish the link when it is ready, then copy and send it to the prospect.

Publishing is a toggle, not a deploy. You can return a published link to preview status, and edits to its prospect context, booking link, or expiry apply immediately without republishing.

Prospect context is optional. When provided, the agent can personalize its opener and frame the demo around the prospect's company and role. Without it, the agent starts broadly and adapts to the prospect's live questions.

Sessions are read-only historyCopy link to this section

Use Demo Agent → Sessions to review session history. It is not where you create, preview, or publish demo links.

Verifying your setupCopy link to this section

For a docked embed with exit intent enabled, first wait for the configured dwell and move the pointer out through the top edge. Confirm the intro pill expands at most once and that no session or microphone prompt starts until you interact.

Before sharing a demo link with a prospect, test its private preview yourself:

Create a link from Demo Agent → Demo Links and open its private preview.
Confirm the agent can log into the configured demo environment.
Ask it to show a few important capabilities and verify the navigation and explanations.
Ask about a topic outside its current knowledge and confirm it responds appropriately.
Interrupt the agent mid-explanation and confirm it adapts.
Test identity capture and the booking CTA using the settings you configured.
Publish the link only after the preview passes QA, then open the published URL once more before sending it.

Things to watch for:

Navigation failures: The agent can't find a screen or clicks the wrong element. Update the relevant source content and re-run ingestion; generated context must be refreshed internally before the demo reflects the change.
Inaccurate explanations: The agent says something wrong about your product. Check your ingested content for gaps or outdated information.
Missing capabilities: The agent can't address a topic you expected it to know. Verify that relevant documentation was ingested; generated capabilities must be refreshed internally before the demo reflects the change.

What's nextCopy link to this section

FAQCopy link to this section

Can I run multiple demo sessions at the same time? Yes. Each session is independent with its own browser instance.

Do I need a separate demo account for each session? A single demo account works for concurrent sessions as long as the demo data doesn't conflict. If sessions modify data (e.g., creating records), consider separate accounts to keep each session clean.

What happens if my product is down during a demo? The agent detects when pages fail to load and communicates this to the prospect. It will attempt to retry navigation, but if the product is unreachable, the session can't proceed.

Can prospects interact with the product directly? In the current setup, the agent controls the browser while the prospect watches and talks.

Can I use exit intent on a fullscreen demo page? No. Exit intent is for a dormant marketing surface, so it supports the Website Agent and docked demo embeds only. Use showExitIntent() from your own mobile or funnel signal only when one of those eligible surfaces is mounted.