A live video support person on your site, in five lines

You can put a live AI video support person on your website this afternoon. Not a typing indicator in a chat window: a face in a bubble that visitors talk to out loud, that answers from your own site, and that can call your backend to look up an order. The install is five lines of code. This post walks through what those lines buy you, and what happens when things fail, because that part matters more than the demo.

What the bubble actually is

Bubblio puts a realtime video agent in the corner of your site. A visitor clicks the bubble and is face-to-face with a support person that listens, speaks, and answers in real time. Under the hood there are three avatar providers; the visitor sees one person, and we decide which provider carries the call.

The agent is not limited to talking. You define tools, which are actions on your own backend: order lookup, booking, refunds with guardrails. The agent calls them mid-conversation, and every call is HMAC-signed with a per-customer secret, so your endpoint can verify that each request actually came from us.

Tools you mark as dangerous get platform-side protection: cooldowns, rate caps, and deduplication. An agent cannot issue the same refund fifty times because a visitor asked fifty ways. Those guardrails live on our side of the wire, so a clever prompt cannot talk its way past them.

Conversations also persist. A returning visitor sees their past conversations in the bubble, and the agent greets them with that context instead of starting cold. Support that forgets everything between visits is one of the quiet failures of most chat widgets, so we treat memory as part of the product.

The install is five lines

Here is the entire integration for a Next.js app. One install, one component, one server route.

npm i @bubblio/server @bubblio/widget
// app/layout.tsx (or any page)
import { BubblioWidget } from '@bubblio/widget'
<BubblioWidget config={{ serverUrl: '/api/bubblio' }} />
// server: one route created with createBubblio({ apiKey })

The widget renders the bubble and manages the call. createBubblio({ apiKey }) creates the server route the widget talks to, and your API key never reaches the browser. The full walk-through lives in the Next.js docs, and non-React sites can use the one-script-tag embed instead.

Failure degrades, it never goes dark

Realtime video is the hardest support modality to keep up. Providers have outages. Corporate networks block WebRTC. Visitors deny the mic prompt. We designed for the failure cases first, because a dead support bubble is worse than no bubble at all.

At connect time the widget walks a failover ladder:

• Provider down: the next of the three avatar providers takes over automatically. The visitor sees a person, not an error screen.
• Video cannot connect at all, for example because the visitor denied microphone access: the bubble degrades to text chat in the same window. The conversation continues; only the face is gone.
• Prepaid minutes exhausted: the same degrade to text chat. A billing state never turns your support off.

That is the invariant we hold ourselves to: there is no path through the system that ends in a dead bubble.

Knowledge is crawled from your site, and the agent refuses to guess

There is no knowledge base to build before launch. Bubblio auto-crawls your own site with zero configuration, and the agent answers from what it finds, with citations, so a visitor can see exactly where an answer came from.

When the agent does not know, it says so instead of improvising. That restraint is deliberate. Vendors claim resolution rates for text bots near 76 percent, while estimates place real-world rates around 42 to 53 percent, and we think confident wrong answers account for part of that gap.

Every question the agent refuses is logged to a dashboard feed called Customers are asking. You get a running list of what visitors wanted and could not find, which is a documentation roadmap you did not have to research.

A human is always reachable, three ways

The baseline is an async inbox. The visitor leaves their question, and you reply from the dashboard or by email.

If you are at your desk, you can take over live. You pause the AI mid-call and type as yourself, and the visitor sees the handoff happen instead of being routed into a queue.

The third mode is puppeteering. You type, and the avatar speaks your words in its own voice, mid-video-call. The visitor keeps a face-to-face conversation; you supply the judgment. It is the strangest feature we have shipped, and the story of how the widget got here is in the chat bubble grew a face.

Pricing is prepaid minutes, nothing else

Packs are $49 for 100 minutes, $199 for 500, and $599 for 2,000. There is no per-resolution fee and no overage; spend cannot exceed what you bought, and when a pack runs out the bubble degrades to text chat rather than going dark. There is no contract.

Resolutions themselves are measured, not billed. Outcomes are read from transcripts and shown per conversation, and the dashboard reports them as X percent resolved, measured on N. Conversations we cannot measure are counted as unmeasured, never guessed. The long version of why we will not bill per resolution is in what Fin really costs and assumed resolutions.

To be fair to the incumbent: Fin has distribution, integration breadth, and brand recognition we do not, and if your support is high-volume and text-first, it may still be the right tool for you. Our bet is narrower. Nobody in mainstream customer-support software offers realtime video agents today, and we think a face that can call your backend is worth five lines.

No resolution tax. No overage. No contract. Live in 5 minutes.

Where to start

If you are paying per resolution today, run your own volume through the resolution-fee calculator and see what minutes would cost instead. If the five lines above look like your kind of afternoon, request access to the private beta.