Skip to documentation

How conversation usage is counted

One visitor starts a billable conversation window when the live widget creates a conversation. In normal chat, that happens with the first submitted message, not when someone opens the launcher.

8 min readUpdated 6 October 2026

Opening the chat is free#

The base charge is tied to admission of the support conversation, not to the amount of text in its first reply. If the first answer fails, the base visitor-window unit is still separate from any extra answer-segment reservation. For a clean check, use a controlled browser profile, record workspace usage, open the panel without sending, then submit one ordinary business question. Refresh the usage view after the service processes it. Do not run repeated paid tests by deleting transcripts: deleting content does not reverse an admitted base unit. Private five-question website tests use their own limited allowance instead.

WorkflowAdmission is different from opening the panel
Page loadsNo billable chat unit from the launcher
Panel opensLocal greeting; no answer request yet
First submitted questionAn admitted base visitor-window unit
The standard widget starts the conversation on a first submission; a confirmed handoff can also bootstrap.

The six-hour visitor window#

For example, a visitor admitted at 10:00 has a window ending at 16:00. A question at 15:55 does not move that end to 21:55. A new billable admission after 16:00 can create another unit even when a retained transcript continues. Two tabs for the same technically identified visitor on the same website share the current underlying window; they do not create a fresh allowance of twenty answers in each tab. A separate website in the same workspace has its own visitor/site window, but consumes the shared workspace pool. Retention can be longer than the billing window without making continued support permanently free.

Data lifecycleThe clock is anchored to window creation
10:00Base visitor window begins
15:55Same window, subject to available answer group
16:00 and laterA new billable admission can create a new base unit
Example for the same technical visitor and website. A later question does not extend this clock.

Up to 20 AI answers per segment#

Answer-group accounting is window-wide. Capacity is reserved before an AI answer and shared across pending or completed AI attempts in the same visitor/site window, so two concurrent tabs cannot independently receive twenty fresh answers. The first group belongs to the base unit. At answer 21, another unit is required; answer 41 requires the next group.

AI answers in the windowRequired units
1–20The admitted base unit.
21–40Base plus one additional unit.
41–60Base plus two additional units.

Failed provider attempts are removed from the active answer count. Eligible unused extra reservations are reconciled when the remaining attempts no longer need that group. The original admitted base window is separate: a first-answer error does not automatically refund it. A fixed system reply or provider-free verified fallback does not itself reserve another AI group. While investigating, distinguish temporary capacity reserved for an in-progress answer from the final reconciled count; deleting a transcript is not that reconciliation.

WorkflowAnswer groups belong to the shared window
AI answers 1-20Covered by the base group
AI answers 21-40One additional paid unit required
AI answers 41-60The next additional group
The same visitor's tabs share this website window. Failed eligible extra reservations are reconciled separately from the base unit.

Practical examples#

Keep the examples' assumptions explicit. A new private browser session can receive a new technical visitor identity; signing into your business account does not merge it with a previous device's window. Clearing browser storage may likewise change identity. Conversely, multiple visible chat transcripts do not necessarily mean multiple base units when the same browser visitor remains within one website window. Add a new website or move outside the window and the result changes. Do not compare usage with a count of chat bubbles: a visitor question and assistant reply are different message records, and a fixed welcome bubble is not an AI answer.

System and provider-free responses#

The service's duplicate-turn protection prevents a repeated request using the same turn identifier from producing a second independent completion. It is a request-safety mechanism, not an instruction for customers to repeatedly submit the question with new identifiers. A new ordinary submission remains a new turn and can use the answer group. An Action result, a human-handoff status or a protection boundary can also appear as a card or message without being an additional AI answer. For an unexpected count, identify whether the change was a new base window or an additional answer group before concluding that every displayed event was charged.

Compare the evidenceVisible messages are not identical to AI usage
Greeting or fixed noticeLocal/system content
Verified provider-free fallbackNo additional AI-answer segment
Ordinary AI answerUses the shared answer-group count
These examples do not themselves reserve another AI group; an already admitted base window remains separate.

Check the workspace pool#

The used count may include more units than the number of retained conversation rows, because long exchanges need extra groups and old content can expire while accounting remains. The opposite comparison is also possible: multiple conversations can share one valid visitor window. Top-up credit increases capacity, not the number of already used units. A usage period changing at its monthly boundary is another reason to record the precise dates when comparing counters. If an extra group cannot be admitted, switching top-ups on does not make unpaid capacity instantly available. New work must wait for eligible, verified capacity rather than borrowing against a payment attempt.

Reconcile units with an event timeline#

For a disputed counter, build a short ledger with four columns: timestamp, website, event and expected unit effect. At 10:00, a new visitor submits a first question and admits the base window. At 10:20, opening another page or the launcher has no new admission effect. At 11:00, the twenty-first AI answer requires the next group. At 16:05, a further admitted question can begin a new base window because the original fixed six-hour period has ended. These events can happen in one visibly continuous transcript, so its row count is not the ledger.

Compare the ledger with the active monthly usage period and actual workspace counter. If a period boundary falls inside the observation, separate the records before comparing totals. If a top-up appears, record that as a capacity change, not as a negative used unit. Do not combine counts from two different sites merely because the same person owns both. Nor should you merge independent browser identities based on a name typed in chat. This method isolates the smallest unexplained event, making a support investigation more useful than a claim that a whole day's transcript count should equal its billing count.

Keep browser identity stable during a measurement#

Use the same browser profile and installed website when measuring one visitor window. An ordinary reload can preserve continuity; a different private session, device or storage reset can create a different technical identity. A move from one hostname to another can also change the origin in which continuity values are stored. A business login or an email in a handoff form does not retroactively merge those independent support windows. Record redirects and any browser-setting change in the test notes so it is clear whether identity itself changed between observations.

For a controlled test, choose one profile, record the starting time and workspace counter, and submit only the planned questions. Keep other team testing out of that workspace while making the comparison, or account for it explicitly. A second tab can be used to test shared-window behaviour, but it should use the same origin and retained visitor identity. Do not clear storage simply to make a greeting reappear: that changes the variable being measured. Stop once the expected boundary is demonstrated. Extra exploratory questions can create genuine additional units and make the original before/after comparison difficult to interpret.

Read a failed extra-answer reservation correctly#

Consider a window with twenty completed AI answers. Its next answer needs an additional group, so capacity is reserved before the provider attempt. If that attempt fails and no pending or completed work still needs the extra group, the eligible unused reservation can be reconciled. The admitted base window remains. A replacement question can then need that group again if it succeeds. The final counter is therefore different from an intermediate view taken while the failed attempt was still pending. The exact failure stage matters: failure to admit a new group and failure after a reservation are different events.

Concurrency makes this distinction useful. Another tab may have an answer still in progress or completed within the same group, so one failed request does not automatically make the whole extra group unused. Give support the safe conversation references and time range rather than deleting records to force a preferred count. Fixed provider-free replies are a separate case and do not create an AI group merely because they appear as an assistant bubble. The service reconciles its reservation records; a customer-side refresh, transcript deletion or screenshot of an error is not itself a refund or a new counting rule.

Example: two tabs in one visitor window#

Consider a visitor asking twelve AI-backed questions in one tab and ten in another during the same six-hour window on the same website. There are twenty-two AI answers across the shared window, so the twenty-first answer needs one additional unit; opening the second tab does not reset the group. If the visitor returns after the window ends, a further billable admission can start another base unit. If question twenty-one fails at the answer-provider stage, an unused eligible extra reservation can be reconciled. A completed earlier base unit remains. These examples assume unchanged browser identity, website and current paid usage period.

Test coverageTwo tabs do not create two fresh answer groups
Tab ATwelve AI answers
Tab BTen AI answers
Shared resultTwenty-two answers; answer 21 needs an additional unit
Example assumes one unchanged visitor, same website, same six-hour window and current paid pool.

Verify the outcome and keep safe evidence#

For support, provide the website, non-sensitive conversation reference if available, the approximate time range, the period shown in Overview and the before/after counters. Explain any second tab, storage reset, device change or unusually long exchange. Do not include browser tab tokens or private message contents just to illustrate a count. A reliable investigation compares admission times and successful or pending answer reservations, not a screenshot of an isolated bubble. If the UI has not refreshed, refresh the view once and keep the same recorded baseline. Repeated test traffic while investigating makes the evidence harder to compare and may create real new usage.

Need help with this?

Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.

Contact Reesponder

Search documentation

Search by task, feature, setting or error. Your search runs in this browser.