The gap between "answering" and "helping"
"What is your refund policy?" is a retrieval question — any grounded chatbot handles it. "Where is my order?" is not. The answer lives in your database, is different for every visitor, and must never be given to the wrong person. Most website chatbots stop at the first kind of question, which is why customers still open a ticket for the second.
Step one: prove who is asking
Your backend computes an HMAC-SHA256 signature over the user's id using a secret only your server and the workspace hold, and your frontend calls flocciChat.identify(user, hmac). The session is then verified: the assistant knows this really is customer 84213, not someone claiming to be. The signature covers the identifier itself, so nothing in the browser payload can be edited into somebody else's account.
Step two: give the assistant your endpoints
In the dashboard's Actions area you describe an action — a name, a plain-English description of when to use it, the parameters, and the endpoint. The assistant then decides on its own when that action fits a customer's question, calls your API with X-Flocci-End-User-* headers identifying the verified user, and answers from the live result. Typical first actions: order status, shipment tracking, subscription or plan lookup, invoice retrieval, appointment or booking status, licence-key resend.
What is built in before you configure anything
- create_support_ticket — raise a ticket with the conversation attached, on request or on policy.
- get_my_support_tickets — a verified customer can ask about their own open tickets.
- web_search — for time-sensitive questions the knowledge base cannot cover, so the assistant searches and cites rather than declining (per-workspace toggle).
- my_flocci_activity — for Flocci's own products, a grounded view of the signed-in person's cross-app activity, granted by an operator rather than self-serve, precisely because it reads real user data.
Guardrails that matter
Actions execute only for the subject of the verified session — the assistant cannot be talked into looking up a different customer, because identity comes from the signed session rather than from anything the model or the visitor supplies as an argument. Credentials for your endpoints are encrypted at rest with AES-256-GCM. Every execution is written to an audit log with the action, the round and the outcome, and surfaces as a visible chip in the conversation so the customer can see what was done on their behalf.
Practical sequencing
Ship the answering layer first: embed the widget, let it learn the site, watch a week of real questions. The dashboard's unanswered-intent list will tell you exactly which account-specific questions keep arriving — that list, not a guess, is your action backlog. Most teams need two or three actions to remove the majority of their ticket volume.