Website chat · Staff & launch guide
Keep the conversation moving.
Read what the customer already said, step in when needed, and return control without losing the history.
Use the Inbox
- Sign in with your registered staff account, open Inbox, and select a conversation. Search sender or load more conversations when needed.
- Read the history, including older messages. Check the current owner/run state and any application activity in Details.
- Click Take over. Wait for the confirmed human owner and quiet AI state; a request being accepted is not always the same as the worker being stopped.
- Type and Send reply. Confirm it is Published and visible to the customer, not merely recorded as a pending command.
- Keep replying while you own the conversation, or Return to AI. AI waits for the next new customer input. It does not automatically answer old messages from the human-owned interval.
While staff owns a chat, new customer messages are retained without competing AI replies. Staff replies use the trusted staff identity. A visitor’s public capability does not permit takeover or settings changes.
When something is uncertain
Open Details → Review & recovery tools. Check an uncertain application operation by its original operation key using the connector’s supported reconciliation. Review does not replay customer input. A recorded review note is not proof that a booking failed or a second booking is safe.
If a command’s response was lost, use Retry same command when offered. Preserve the same identity and body. Do not turn an uncertain staff reply into a second new command.
Change the customer experience deliberately
Registered integration managers can load, validate and publish permitted settings. Use a short welcome and clear business instructions. The currently registered public name, connector and credential reference are not a new-agent creation flow.
Publishing creates a new application revision. New conversations use it; existing conversations keep their revision. Configuration and package changes are different: model/provider/tool roots and base profile belong to the supplied package and operator activation process. Do not assume a settings publish migrates long-lived sessions.
See the step-by-step settings guide for origins and embed generation.
The launch checklist
Use a named test conversation and approved test effects. Record the target, active package versions, configuration revision and results. Website rendering, application behavior and production release are separate checks.
| Check | Expected evidence |
|---|---|
| External routes and iframe | HTTPS assets and chat load from the actual registered website; correct public key and welcome. No blocked framing. |
| Customer → AI | The customer message and public AI answer appear in both the widget and authoritative history, with no exposed tool/system content. |
| Read-only application fact | A calculator/data result matches the native source. Settings validation alone does not satisfy this. |
| Takeover while idle, then while running | Human ownership confirmed; worker quiescence checked; no late stale AI publication. Already completed effects are not hidden. |
| Human-owned customer input | Message saved once; no competing AI reply. |
| Staff reply | Exactly one Published canonical reply, visible to the customer. |
| Return to AI | WaitForNextInput; only a new customer message starts AI. Earlier human-owned input not replayed. |
| Reload and history | Intended same-tab capability continuity and correct ordered history. Check long history/compaction and service restart separately. |
| Denied access | Unregistered origin, unauthorized/disabled staff, wrong application/tenant and direct normal/legacy routes denied; no denied mutation. |
| Offline / busy / expiry / unknown send | Appropriate recovery, stable message/command identity, no duplicate reply or blind business write. |
| Optional write workflow | Real native lead/booking receipt and independent saved-record/notification readbacks; approved recipients only. |
| Phone and keyboard | Readable responsive frame, reachable controls and correct open/close/focus behavior for the chosen host wrapper. |
Keep a launch receipt with your actual target, connected workflows and results. This makes future changes easier to check and gives your support team a clear starting point.
Find the failing boundary
| Symptom | Check first | Next action |
|---|---|---|
| Chat not available | Enabled current application, PublicAgentKey/route match, gateway-to-Buffaly connection. | Read current bindings and active package/profile diagnostics. A desired package version is not active proof. |
| Origin denied | Actual HTTPS website origin, www variant, iframe referrer policy. | Correct permitted origins via registered manager; publish/read back and test a fresh conversation. Do not add wildcards. |
| Blank iframe | Gateway HTTPS/path base, parent frame-src and server/proxy frame restrictions. | Use network and console diagnostics; fix the exact hosting policy, not credentials in the browser. |
| Gateway healthy, messages fail | Public service credential, route/binding identity and active backend worker. | Trace open/send/refresh and worker outcome; /health only proves the gateway process. |
| Staff sees no conversations or is denied | Chat.IntegrationFile, application/UserIDs, current enabled role and registered subjects. | Verify both staff-host and Buffaly authorization. Do not bypass it by changing UI visibility. |
| Staff cannot send | Confirmed Human owner/assignee; write Origin equals HostOrigin; review-required state. | Confirm takeover or reconcile the original uncertain operation before return. |
| Old welcome/instructions | Conversation’s pinned binding revision. | Verify the newly published revision in a new conversation. Existing-session migration is a separate operator decision. |
| Business API failure | Connector contract, approved origin, least-privilege server credential and real endpoint. | Run its approved read-only native probe. Do not interpret Validate settings as API acceptance. |
| No consultation slots | Actual enabled meeting link, selected owner/calendar, hours and timezone. | Configure approved real availability. Defaults are not an approved schedule. |
| Booking/callback response lost | Original OperationKey and native receipt/readback. | Reconcile without a second write; hold for staff if the native contract cannot establish the result. |
| Conversation lost after deployment | Data Protection application name/key ring, capability lifetime, canonical and control-state restore. | Restore the coherent owned state or explain expiry. Do not recreate missing canonical history from UI text. |
Keep the two APIs separate
Visitor browser → PublicChat
Under the configured path base: POST /api/open, POST /api/send, POST /api/refresh. The existing ASP.NET browser protocol uses camelCase requests/responses. A protected conversation capability and stable client message key identify visitor operations.
Trusted external adapters → Buffaly.Chat
The existing typed ChatClient calls POST /web-modules/Buffaly.Chat/integrations/v3/{operation} with a role-scoped Bearer credential. Staff calls also carry the trusted X-Actor-Subject. Shared contracts use exact PascalCase; the visitor protocol is not an alternate casing path.
Registered operations: public-binding, open, ingress, list, history, command, resolve-message, reconcile, delivery-status, setup-read, setup-validate, setup-publish. Role permissions determine which operation a credential may invoke.
Feeding Frenzy browser UI consumes its generated ChatAdmin client. Code already inside Buffaly uses its typed runtime services; these cross-process routes are not a reason to make internal HTTP calls.