​

Run the conversation-intelligence operator console

This guide walks you through the whole operator lifecycle in the dashboard: where the console lives, how to author your first classifier, what the active-operator cap buys you, how versioning keeps reports honest, and how to read results per thread and in aggregate. It is the hands-on companion to Conversation Intelligence (the model) and Conversation operators (the API reference) — this page tells you which button to press; those tell you what the pipeline computes.

​

1. Where the console lives

Open Inbox → Settings and choose the Conversation operators tile (/inbox/settings/conversation-operators). The catalog holds every custom classifier your tenant defined — each one a name, a plain-language instruction, an output type, and a channel scope.

• Owners and admins create, edit, and deactivate operators. The console is role-gated the same way the API is.
• Any authenticated teammate can read the catalog and read per-thread results — agents do not need admin rights to see what the classifier decided on a thread they are working.

There are no operators until you create one. If the classifier produces no signals, this is the first thing to check.

​

2. Create your first operator

From the console, create an operator with four parts:

1. Name — how the signal reads in the dashboard and reports. Make it a question or a noun phrase: Refund intent, Churn risk, Order id.
2. Instruction — the natural-language rule the classifier applies to each thread, in plain language. Be concrete: name the phrases or patterns to catch. “Set to true when the customer asks for money back, mentions ‘refund’, or wants a charge reversed.” A vague instruction produces low-confidence values that pollute every report.
3. Output type — the shape of the signal:
   • boolean — yes/no flags (escalation risk, billing intent).
   • text — free-text extraction (an order number, a country).
   • number — a score or count (a 0–10 frustration rating).
   • enum — pick one from a closed choices list you declare at creation time. Reports on enums are the cleanest to aggregate.
   • list — zero or more values (topics mentioned, products discussed).
4. Channel scope — which text channels the operator runs on (SMS, WhatsApp, email, web chat, and the rest). Leave it broad unless the signal is genuinely channel-specific; per-channel scoping is a cost lever, not a correctness tool.

Save, and the operator starts running against new inbound messages on those channels. Voice conversations are classified by the voice speech-category pipeline instead, so the same taxonomy never applies two classifiers to one thread.

​

3. Active operators, the cap, and classifier cost

Every active operator adds one classifier call per inbound message. To keep that bounded, the number of active operators per tenant is capped at 25. When you hit the cap, create returns a limit error and the console refuses — retire something before adding a new signal. Deactivating an operator is a soft delete, and it cuts two ways:

• What it frees — the operator stops running on new messages, and its slot against the 25-active cap opens immediately.
• What it preserves — the definition and every previously computed result stay on the conversations that carry them. Historical reports over an old window still read the deactivated operator’s values.

Deactivate liberally: keep the active list to signals someone currently reports on, and let the archive carry the rest.

​

4. Versioning and edits

Changing an operator’s instruction, output type, or enum choices bumps its version and re-runs results under the new definition on the next classifier pass. Changing only the channel scope does not bump the version. What happens to results computed under old versions: they stay on their threads, tagged with the version that produced them. A report window over an edited operator never silently mixes definitions — reads tell old-version values from new-version values, so a week-over-week trend across the edit reads as “before and after the instruction changed,” not a drift in customer behavior. Practical consequence: when a reworded instruction materially changes the classification rule, treat it as a new baseline. Trim the old choice from dashboards, or run the operator side by side under a new name for a window and compare before retiring the old definition.

​

5. Reading results

Results land on the conversation itself, so there are two read surfaces:

• Per thread — open a conversation in the Inbox conversation view and the operator results sit in the thread detail: each operator’s value, confidence, rationale, and which version produced it. Over the API, that is GET /api/v1/inbox/conversations/{id}/intelligence/operators.
• Aggregate — the Insights → Conversations dashboard (/insights/conversations) rolls typed outcomes across a window: share of threads flagged, enum distributions, trends week over week. Because results are typed, boolean/number/enum operators aggregate cleanly; a list of topics groups by value.

The conversation list filters on operator outcomes, so an operator with a good name becomes a saved view: every thread where Refund intent = refund this week.

​

6. Worked example: a refund-intent enum operator

Suppose support wants to separate refund requests from order-status checks and complaints. Author one enum operator:

• Name: Refund intent
• Instruction: “Classify what the customer is asking for. refund: wants money back or a charge reversed. order_status: asks where an order is, when it ships, or its tracking. complaint: expresses dissatisfaction without asking for a refund. Pick the closest single value.”
• Output type: enum
• Choices: ["refund", "order_status", "complaint"]
• Channels: SMS, WhatsApp, email, web chat.

Then report on it:

1. Conversation view — open any thread and read the operator’s value, confidence, and rationale.
2. Insights → Conversations — the distribution chart shows the refund share of inbound volume; a rising refund rate after a promo is a cost signal, a rising order_status rate is a shipping-visibility problem.
3. Saved filter — filter the Inbox to Refund intent = refund this week and hand the list to billing.
4. API — the same read is scriptable: GET /api/v1/inbox/conversations/{id}/intelligence/operators returns the operator result per thread for a downstream warehouse pull.

Rename the enum choices carefully — editing choices bumps the version, so a rename is a new baseline (see versioning above).

​

7. Limits and edge cases

• Active-operator cap — 25 per tenant; deactivating frees a slot immediately (see section 3).
• Throttled background analysis — analysis runs in the background: a poll against the intelligence endpoint kicks a throttled scan, and an hourly server-side scheduler re-kicks the same scan. Newest conversations may show un-analyzed on the first dashboard load after traffic lands; values fill in on the next poll. This is expected, not a stuck classifier.
• Voice threads — operators run on message text only. Voice and video conversations are classified by the voice speech-category surface; the operator taxonomy is shared with it, so a report can treat voice categories and text operators as one taxonomy.
• No signals at all — until a tenant defines its first operator, the pipeline makes no classifier calls. An empty result list with a 200 means the taxonomy has no active operator, not that classification failed.
• PII before the classifier — redaction runs before any thread content reaches the classifier, so operator definitions never send raw message bodies out of your tenant.

​

8. Where to go next

• Conversation Intelligence — the model: built-in signals (sentiment, topics, quality score), storage, retention, and querying the stats API.
• Conversation operators — the catalog’s API reference: request/response shapes for create, update, deactivate, and per-thread results.
• Quality management program — close the QA loop: operator signals (escalation risk, sentiment) feed reviewer queues and calibration.
• Inbox settings map — every operator console under Inbox → Settings, with the symptom-to-console troubleshooting table (including “classifier produces no signals”).
• Inbox SLA timers — pair operator signals with response targets where classification should drive escalation.