Skip to content
Guides

Understand a customer conversation

The assistant combines available business evidence with a permitted set of actions. Your configuration shapes its response, and your team can inspect the conversation or take over through the console.

Grounded answers

Business answers use retrieved Knowledge, structured catalog rows, configured business facts and the results of available tools. Greetings and conversational explanations do not need a document citation. A style instruction or customer assertion does not become authoritative business evidence.

A business fact you have not filled in (contact details, hours, locations, payment or delivery) is not treated as absent: the assistant searches your Knowledge for it before telling a customer it does not exist, and an answer built only on an empty field is not recorded as grounded. When it cannot make that check, it says it could not check rather than saying no.

When supporting material is missing, stale or unavailable, the assistant should explain what it cannot verify and offer an available next step. A missing answer does not always create an escalation: useful request capture, an available team route and the reason for the gap affect the outcome.

Where Knowledge publication checks are enabled, approval is checked against the exact evidence revision. A source that changes or loses approval can prevent an answer from being delivered from that evidence. See review and publication.

Evidence behind a reply

Each assistant reply in a transcript carries a small chip beside its time. Evidence · 3 means three items were recorded with that reply; select the chip to list them. Each row names the document, catalog row or business overview line the assistant was handed, with the first lines of the passage it read. No evidence means the reply was written without any recorded passage. A reply with no chip was written before evidence was kept per message, so nothing is known about what backed it.

A passage listed here is what the assistant read for that reply. It is not proof that every sentence of the reply follows from it: the assistant can read the right passage and still phrase something wrongly, and it can be handed a passage it did not use. Read the reply against the passage when reviewing an answer, and use Test your knowledge base when the right document was not among them.

Action limits

Actions depend on the active profile, platform switches, plan, workspace policy, data readiness and conversation state. Check Capabilities for the effective configuration. The server authorizes tool execution and validates its inputs; adding an action to Goals or Agent Guidance cannot grant it.

Catalog and cartsLook up structured products, save actionable items and submit an internal request where authorized. This does not place a commerce order, take payment, reserve stock or start fulfilment. Catalog and carts.
AppointmentsSearch offered times and record a manual request or commit an automatic internal confirmation. Customer cancellation and rescheduling require the relevant permission, ownership and confirmation checks. Appointments.
Order lookupAn enabled read-only connector can retrieve an existing order using the required customer verification details. It does not create, change or cancel external orders. Configure supported lookups under Developers.
Customer requests and complaintsRecord supported requests for your team where capture is enabled. Recording a callback or refund request does not make a call or issue a refund.
Media and voiceShare eligible reviewed media and produce audio replies when the relevant delivery or synthesis capability is available. Media and voice.
Smart UpdatesRecord explicit topic consent and send eligible approved updates when enabled. This does not connect a general newsletter provider or add customers to an external list. Smart Updates.
Public web lookupRequires an enabled capability and configured provider. Do not assume the assistant can verify current online facts in every workspace.

There is no customer checkout, live inventory reservation or external calendar synchronization in these internal workflows. They do not provide course enrollment, formal grading or certificate issuance. Catalog stock reflects your maintained data, not a live warehouse check.

Conversation goals

In Assistant → Goals, describe the desired conversation outcome, the work your team handles, details it needs and preferred escalation situations. These settings guide the assistant within its existing authority. See assistant setup and guidance for forms, template imports and baseline adoption.

Working memory and action outcomes

The assistant can carry relevant context between turns, such as the selected product, an offered action or an appointment option. A customer saying yes establishes intent; a successful server operation establishes completion. Failure and conflict outcomes should be communicated as such.

Code-generated cart and appointment confirmations use committed results. Model-generated text is checked for unsupported capability claims before delivery. These controls reduce invented promises; they are not a guarantee that every generated sentence is correct. Inspect the transcript and recorded action state when reviewing an issue.

Conversation working state is separate from optional longer-lived customer memory. Review memory consent and retention controls under Assistant → Answer quality.

Phrases to avoid

Add exact prohibited phrases to the Never say list on Goals. The response guard checks configured phrases with case-insensitive substring matching and can withhold a matching reply. Use specific wording and test it: a broad phrase can also match an ordinary acceptable sentence. Handoff still follows the available routing and handling policy.

Human handoff

Confirm escalation recipients under Settings → Escalation alerts. A reachable route is necessary before the assistant can promise team follow-up; adding an unconfirmed address is not enough. Set business hours and handoff wording under Assistant → Behavior.

Escalated conversations appear in Needs attention with their history and reason. A teammate can take over, reply through the customer’s channel and use the available resolve or release actions. Conversation assignment and channel delivery restrictions still apply.

Recorded reasons include a customer request for a person, low confidence, unsupported knowledge, high risk, frustration, repeated failure and service errors. The reason does not by itself guarantee escalation: routing, policy and whether a person can move the request forward influence the disposition. Analytics helps distinguish content gaps from unavailable services.

Optional waiting follow-ups and unfinished-chat nudges have separate activation and delivery checks. An unfinished-chat follow-up is sent once, about 45 minutes after a conversation goes quiet with something left open: options shown, a price or quote given, a booking, viewing, enrolment or application not completed. It is not sent if the customer has replied, declined, asked for a person, or if someone on your team has taken over, and it respects the channel’s messaging window and every opt-out. On a workspace with an adopted sector programme the message is written for that sector and situation. Business hours do not create a response-time guarantee or a staffed team.

Languages

Configure language behavior under Assistant → Behavior. Six languages are certified: English, French, Nigerian Pidgin, Yorùbá, Hausa and Igbo. In an enabled language the assistant answers in the language the customer wrote in and keeps their register, and the code-level checks that read a reply for unbacked promises, fabricated successes and wrong-language output run in that language. In any other language the customer receives a selection notice naming only the languages the workspace enabled. Your written material can stay in whatever languages it is written in, mixed or not: the assistant reads which languages your documents use (from the documents themselves, no configuration) and tells the model to search in those languages whatever language the customer wrote in. When a search finds nothing and the question is not in one of your documents’ languages, the assistant searches once more with the customer’s own words if they are in one of them, and otherwise renders the question into every language your documents use with one bounded model call, keeping the names, codes and figures the customer typed, then searches those renderings in turn and stops at the first that answers; a question in a language your documents already use never pays that call. If that search cannot be completed, the assistant says it could not check rather than that you have nothing written on the subject, and it does not record a gap it never established. This was measured on a live model on 21 September 2026: six single-fact documents, one per language, asked about in all six languages, plus absent answers and messages that mix two languages. After that run’s fixes, every one of the 36 document-and-question pairs returned the correct figure in the customer’s language, every absent answer was admitted rather than invented, and every mixed-language message was answered. The lab’s search index is word-based rather than the production embedding model, so the measurement proves the mechanism, not the production index; a run on the production index is the remaining step. Test with your own documents before relying on it. Identifiers such as SKUs and order references should remain unchanged.

Every fixed message the assistant can send exists in all six languages: handoff and escalation texts, request confirmations, capability limits, cart and booking confirmations, order status, appointment notices and reminders, availability watches, Smart Updates (including the consent question and the updates themselves), the sector programmes’ emergency lines and follow-ups, and the after-hours note. Organization defaults may optionally be authored in the four Nigerian languages and read the English otherwise; sector coaching lines the model reads stay in English and French; voice profiles depend on the voices your provider offers. Test the languages your customers use.

Reading customer text in your language. Your team does not have to read every language the assistant answers in. A message, a customer request, a complaint or a delivery note written in a language a teammate does not read can be rendered into that person’s own reading language with one click, wherever it appears in the console and in the phone app. The original is always shown as written and stays beside the rendering; names, references, phone numbers and figures are kept exactly. Each rendering is made once, when someone first asks for it, and shown to everyone after; a text that is edited is rendered afresh. Set your reading language under Account & security. It is yours alone and does not change which languages the assistant answers customers in. Renderings are model calls the workspace pays for, capped per day; when one cannot be made, the original is shown and the reason is stated.

Consequential questions

Medical, legal, financial and safety-sensitive requests receive additional handling checks. Grounded conceptual education and a personal recommendation are different requests; the active profile and risk rules decide what can proceed. Do not configure the assistant as a substitute for qualified professional judgment.

Reviewing quality

The repository includes tests for capability guards, tenant isolation, action authorization and response quality. Passing tests establishes behavior for the covered cases, not perfect output on every future conversation. Use Analytics, transcripts, complaints and Answer quality to review actual outcomes and improve the underlying content.