> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Run the conversation-intelligence operator console > An operator walkthrough for the Conversation Intelligence console: author custom classifiers, understand the active-operator cap and versioning, read per-thread and aggregate results, and run a worked refund-intent example end to end. # 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](/concepts/conversation-intelligence) (the model) and [Conversation operators](/inbox/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](/concepts/conversation-intelligence) — the model: built-in signals (sentiment, topics, quality score), storage, retention, and querying the stats API. * [Conversation operators](/inbox/conversation-operators) — the catalog's API reference: request/response shapes for create, update, deactivate, and per-thread results. * [Quality management program](/guides/quality-management-program) — close the QA loop: operator signals (escalation risk, sentiment) feed reviewer queues and calibration. * [Inbox settings map](/inbox/settings-map) — every operator console under Inbox → Settings, with the symptom-to-console troubleshooting table (including "classifier produces no signals"). * [Inbox SLA timers](/guides/inbox-sla-timers) — pair operator signals with response targets where classification should drive escalation.