Every capability, by plan

Sales site, support portal, partner app — each gets a widget with its own look, greeting, allowed origins, agent routing, sign-in mode, hours and file rules. Agents see every domain in the same Teams queue; the closed-chat report shows the source domain. Add or change a widget from the dashboard, no redeploy.

• Every widget is managed in the same Teams tab: add widgets in bulk, apply settings from another widget, preview who gets a chat, and give a widget its own admins.
• Per widget: the look and every visible string, the allowed origins, the Foundry agent that answers first, the sign-in mode, the file rules and permissions, the business hours, the inactivity timeout and the fallback contact.
• Each widget carries a list of allowed origins, and that list drives the Content-Security-Policy frame-ancestors header on the widget host, so a browser refuses to render the widget on a domain you did not list.
• One script tag on the page. Which widget answers, and which domains may render it, follow from the widget you point that tag at.
• The widget is mobile-first: it respects the host page's safe areas, follows the on-screen keyboard as it opens and closes, and behaves with the browser back button on Android.

The widget's "Chat with a Human" button, or the same words as a quick-reply chip, asks your team for a person; whoever takes the chat in Teams joins the same thread, with the conversation so far. Per widget, business hours, live Teams presence or both decide when it is offered, and presence filters who is notified. When nobody is available, the widget offers your fallback contact.

• Handoff runs in every direction, any number of times: "Chat with a Human" or your agent brings a person in; claim, transfer to a colleague or group, take over, hand back to AI, reopen a closed chat. Hours or live Teams presence decide when a human can be offered — the AI is never gated — and presence filters who is notified. When nobody is available, the widget shows your fallback contact.
• The visitor gets a chat window, not a form. AI answers stream in as they are written; suggested replies appear as chips to tap instead of type; a registered visitor can download a transcript of the conversation as a PDF. Every visible string — the greeting, the placeholder, the system messages — and the colours are configurable per widget, so the widget reads as part of the site it sits on.
• The AI keeps answering; business hours decide when a human can be offered, live Teams presence decides who is notified, and outside both the widget shows the fallback contact you configure — there is no separate offline form or ticket queue.

Per widget you choose anonymous, optional or required sign-in. Registration and profile happen in the widget, against an External ID tenant you own; the service validates a real OIDC token. Signed-in users open their Past conversations, download a PDF transcript and unlock the file space. Admins do not manage external users in the app: the directory is yours; the widget is the front door.

• Sign-in is a per-widget decision, not a tenant-wide one. A widget can be anonymous (no sign-in offered), optional (the visitor may register to unlock history and files) or required (no chat until they have). A support portal can require it while the marketing site never mentions it, and the same Teams queue answers both.
• Registration is not a form that takes your word for it. The identity token the widget presents is verified against your Entra External ID tenant's published keys — signature, issuer, audience, the tenant id it was issued for, and the object id of the user — and only then does the session become an identified one. What we keep is the object id and the display fields your directory returns; passwords and other credentials never reach the service, because sign-in happens in your tenant.
• Signed-in customers open Past conversations inside the widget — their earlier chats, readable in full, with a PDF transcript to download.
• Inside the widget, customers and partners get answers, tap "Chat with a Human", sign in, submit files and open Past conversations — without leaving your site.

Topic Analysis runs across your closed chats for the range you pick, groups them by topic, shows the domains behind each, and writes per-topic recommendations for your human agents and your AI agent. The closed-chat report adds source domain, agents, transfers and handling time. For continuous improvement: no sentiment scores, no trend charts, no per-user profiles.

• A run is scoped and bounded on purpose. You pick the date range and filter by agent and widget domain; the pass covers closed conversations only. Each run classifies at most 200 conversations it has not seen before and reuses every classification it already holds, so a large backlog is worked through in predictable steps — and each step's inference cost is predictable with it.
• The Dashboard tab reports on closed conversations only, so the numbers stop moving while you read them. Filter by date range, by agent type (AI or human), by a specific agent and by source domain, then read chats resolved, time to resolution, how long a human was actually handling the chat, how many transfers it took and who closed it. It is a report, not a live queue — the live queue is the chat list next to it.