Support twins
Early access. The core — grounding, honest gaps, instant handoffs, token gating — is solid and included in every plan. Resolution analytics, helpdesk integrations and admin controls are on the roadmap.
Your public twin speaks as you. A support twin speaks for something you own — your product — inside your own site or app.
It answers in a neutral voice from the product knowledge you give it, never sells, and when it can't answer it does the one thing bad support bots don't: it says so, and offers to pass the question to a person. The visitor leaves an email, the question lands in the twin's Inbox tab, and you get an email immediately — a handoff means someone is stuck right now, so it always alerts, whatever your notification settings say. Nobody dead-ends.
Nobody can reach it by URL
A support twin has no public link. The only way in is a signed token your own server mints — your site vouches for its visitors, which is why they never need hiy accounts. The address exists only so your dashboard and your snippet can name it.
Setting it up is three steps on the twin's Publish tab: copy your signing secret, mint a token per page view on your server (the exact code is on that page), and drop the widget snippet — bubble or inline — with the token.
Keep the secret server-side, always. If it ever leaks, tell us and we'll rotate it.
What it knows
Only what you give it, exactly like your own twin: paste docs, import your help site, add corrections. It quotes limits and steps verbatim, cites its sources, and never guesses at how your product behaves — an invented answer about your own product is the most expensive kind of wrong.
Give it a Known issues list and it can look up what's broken right now and say what the workaround is.
Review before it answers
The same identity rule applies: you twin yourself, or something you own. A support twin whose name could belong to a person is checked by a human before it can answer — so "Acme Support" may wait briefly, and "Ask Sarah" always will. That's deliberate.