botminds.aiRequest a demo

Academy · Solutions · Agentic Workflow

Build: Support intake triage

In one line. Inbound support items — emailed, uploaded, or typed — get classified by an agent, the lifecycle routes each by category, the clean confident ones auto-resolve, and the ambiguous or urgent ones queue in a human Inbox. You’ll build. A triage pipeline: a Processing collection, a classification taxonomy (category, priority, sentiment), three intake paths, a Triage Classifier agent, and a routing lifecycle — about 60–75 minutes for the core build, plus 30 for the production upgrades. You’ll use. Core concepts · Collections & schema · Taxonomy, lifecycle, tags & events · Ingestion & connectors · Your first agent · Dashboards & inbox · Teams & mesh

This is the canonical triage and routing shape from What is Botminds: classify incoming items and send each to the right queue or person. Where Build: Invoice settlement decided on each document, this one sorts each document — same building blocks, assembled for a different job. Having built the invoice pipeline first helps but isn’t required. You need a project you can build in, at least one LLM registered (LLMs & services), and enough Studio orientation to find your way around.

 inbound support items          "Support Intake" (Processing)
 email (IMAP)      ──┐          schema:  Ticket Details (extract)
 upload (one-shot) ──┼──►                Triage (classify)
 Input Form (typed)──┘                     category: billing / technical /
                                                     account / urgent
                                           priority · sentiment
                                 worker: Triage Classifier fills the labels
                                 lifecycle routes by category:
                                   simple + confident ──► auto-resolve
                                   ambiguous / urgent ──► Inbox (human opens
                                                          the wrapped ticket)

Steps

Stage 1 — Create the “Support Intake” Processing collection

A Collection is the typed home for one kind of record (Collections & schema). Support tickets are records you decide and sort, not a corpus you read — so this is a Processing collection.

  1. Go to Studio ▸ Data Model ▸ Collections. Click + Collection (rail footer).
  2. On the General tab: Purpose: leave/select Processing. Collection Name: Support Intake. Description: Inbound support items to be classified and routed. Optionally Set as Primary if this is the project’s main intake target. Leave the other accordions at their defaults.
  3. Click Save. Support Intake appears in the left rail.

Watch out — Category is permanent. Processing vs Knowledge is chosen once, at create time, and shows as a read-only chip afterwards. Pick Processing deliberately.

Checkpoint. Selecting Support Intake shows a tabbed detail pane (General · Schema · Lifecycle · Tags · Events · Ingestion · Agents). A new Processing collection is automatically seeded with the 8-stage Four-Eyes lifecycle — you reshape it for routing in Stage 5.

Stage 2 — Build the classification taxonomy

A schema can do two jobs (Taxonomy, lifecycle, tags & events): extraction (pull a value out — the customer’s name) and classification (assign the item to a category). Triage is mostly classification, so you’ll build classification Learners.

Vocabulary. A Learner (a.k.a. Taxonomy) is the trainable extractor that owns a group of fields; a Label is one field (the UI shows it as a Field). A classification label is just a Label living under a Classification-type Learner — its name is a category the item can be sorted into. See the Glossary.

First, a few extraction fields so a human has context:

  1. Select Support Intake → open the Schema tab → click Taxonomy (footer).
  2. Name: Ticket Details · Description: Who/what the ticket is about · Type: DocumentClassification · Entity: Support Intake. Submit.
  3. Select Ticket Details, click + Label, and add (using Add between, Add and exit on the last): customer_name — Description: The requester's name (plain text); subject — Description: The ticket's subject line or summary (plain text); account_id — Description: Any account/order reference mentioned (plain text).

Then the Triage classification Learner — the heart of this build. It holds the three triage decisions: category, priority, sentiment.

  1. Schema tab → Taxonomy (footer). Name: Triage · Description: How to sort this ticket · Type: DocumentClassification · Entity: Support Intake. Submit.

  2. Select Triage, + Label, and add these category labels — one per category the agent can assign. Enter each category as the Label Name with a one-line Description:

    Label Name Description
    billing Invoices, charges, refunds, payment problems
    technical Bugs, errors, outages, “it doesn’t work”
    account Login, profile, access, plan changes
    urgent Service down, data loss, anything time-critical

  3. Add two more single-select fields for priority and sentiment. For each, + Label, open Show Advanced Settings ▸ View Config, and add a validation rule listing the allowed values — this is how a Label becomes a single-select; there is no “type” dropdown, the validation rule defines the shape (Collections & schema):

    • priority — allowed values low, medium, high.
    • sentiment — allowed values positive, neutral, negative.

Keep classification Learners small and flat — one Learner per decision, a handful of labels each. It reads better later in the Conditional stage editor, where you’ll branch on category.

Checkpoint. The Labels tree under Triage shows your four category labels plus priority and sentiment. The schema drives extraction — the classifier agent will assign exactly the labels you defined here, and nothing you didn’t.

Stage 3 — Wire ingestion: three ways items arrive

Support items come from everywhere, so capture them three ways (Ingestion & connectors). Open Studio ▸ Connector ▸ Ingestion.

Flag-gated. This teaches the modern Sources v3 screen. If you land on the legacy wizard, enable the ingestionV3 lab flag first (Getting oriented).

Email — the main inflow:

  1. + Connector → pick Email (IMAP). Fill the mailbox credentials and run the live test — Email connectors can’t save until the test passes. Save connector.
  2. + Job → Step 1: pick the Email connector. Step 2: Job name Support mailbox, Folder INBOX, tick Include attachments, Target collection Support Intake. Step 3: Recurring → every 15 Minutes (or a cron). Check the Next 5 runs preview → Create job.

Upload — ad-hoc and smoke tests:

  1. The Upload toolbar button takes a one-shot batch — no connector or job needed. Drag in files, set Target collection = Support Intake, Submit. Use this to smoke-test your schema before you trust the recurring email job.

Input Form — direct typed capture. Sometimes there’s no document: an agent on the phone needs to type a ticket. The Input Form builder defines a template that creates records directly:

  1. Go to Studio ▸ Connector ▸ Input Form → + Add Form → Type: Create Source. Name it Log a ticket.
  2. Add Columns mapped to your taxonomy fields — e.g. a subject text column (mark Is Title), a customer_name text column, and a multiline body column. Each column’s Label maps to a taxonomy field.
  3. Create. Submissions now land in Support Intake as records, ready to be classified.

Checkpoint. Drop 3–5 sample tickets via Upload. Each appears in the document list with a “Processing…” chip and fills in. The chip stalls at 0% only if the background worker isn’t running — see Ingestion & connectors.

Stage 4 — Build the “Triage Classifier” agent

The agent reads each item and fills in the Triage labels. Build it in Studio ▸ Agent Builder ▸ Agents (Your first agent).

  1. + Agent ▸ Agent to open the editor.

  2. Persona tab. Name: Triage Classifier. Description: Classifies inbound support tickets by category, priority and sentiment. For Instructions, click the co-pilot, seed it with “Classify a support ticket into a category, a priority and a sentiment,” then edit the draft to read roughly:

    You are a support-triage assistant. For each inbound ticket, read the
subject and body and decide: the category (exactly one of billing,
technical, account, urgent), the priority (low/medium/high), and the
sentiment (positive/neutral/negative). Treat anything reporting an outage,
data loss, or a security issue as urgent with high priority. If the ticket
is genuinely ambiguous, prefer a lower confidence over guessing.

  3. Model tab. Pick your project’s LLM Model. Classification is well-bounded, high-volume work, so Agent Mode = Fast is the production setting — but set Thinking for now so you can watch its reasoning while testing. Keep Temperature low (Advanced sampling).

  4. Output tab. Turn on Structured output. Choose the Triage Taxonomy/Learner, set Process unit = Page, add the Labels category, priority, sentiment with a short Description each, and turn on Confidence Score and References. The per-field confidence you turn on here is what routes a ticket to a human later — low confidence on category is the platform’s signal that a person should look.

  5. Save Agent.

  6. Test in the Playground (right pane). Set Input Type = Document, pick one of your sample tickets, Send. Watch it stream the category/priority/sentiment with a confidence each. Feed it an ambiguous ticket and confirm the confidence drops. Flip Agent Mode = Fast and re-run — same answer, quicker. That’s production.

  7. Assign it to the collection. Open Support Intake ▸ Agents tab and assign Triage Classifier as the intake agent. From now on every item that lands — emailed, uploaded, or typed — runs through it automatically.

Checkpoint. Upload a fresh ticket and watch the document fill in with category, priority, and sentiment plus a confidence on each.

Stage 5 — Route by category: auto-resolve the easy, Inbox the hard

This is where classification becomes routing. A Lifecycle is the ordered stages a document moves through (Taxonomy, lifecycle, tags & events) — not an XFlow. You’ll use three lifecycle mechanisms: a Conditional automation to branch by category, the Send to Inbox flag (IncludeManualIntervention) to hand the hard ones to a human, and the Auto-Decide policy to resolve clean, confident ones without a human. Open Support Intake ▸ Lifecycle — the seeded Four-Eyes flow is already there.

Branch by category:

  1. Click the AI Recommendation stage to open the State editor.
  2. Set Automation Type = Conditional. In the Conditional Stages list, + Add Conditional Stage one row per route — each row is a label condition → target stage:
    • category = urgent → L1 Review (you’ll send that stage to the Inbox, below).
    • category = billing → a Billing Review stage. Add it with the State (+) button in the stage graph if you want a dedicated queue, or route to L1 Review to start. Note: + Lifecycle creates a whole new stateflow — to add a stage, use the State button.
    • category = technical → a Tech Review stage (same idea).
    • category = account → straight toward Approved if your account changes are safe to auto-handle, or to a review stage if not.

Start simple: route everything to one L1 Review stage first, prove the Inbox hand-off works end to end, then split out Billing/Tech queues. Don’t build five branches before you’ve seen one work.

Send the hard ones to the Inbox:

  1. Open the review stage(s) you route to (e.g. L1 Review). In the State editor, turn on Send to Inbox (human review) — this is the IncludeManualIntervention flag that makes a stage a review stage. When a ticket reaches it, the server creates an InboxNote that wraps the source ticket, remembering its collection, doc id, and stage.
  2. Optionally gate the stage with Can be viewed by to the role that should handle it (e.g. L1-Reviewer) — roles are covered in Access & roles.

The one point not to miss — you act on the wrapped document, not in the Inbox. The Inbox (Dashboards & inbox) is read + snooze + dismiss only. There is no approve/reject/edit button inside it. Each row is a pointer; you click Open, which takes you to the wrapped ticket, and you act there using the document’s normal lifecycle UI. Advancing the ticket past its human stage resolves the Inbox note automatically. The Inbox is a worklist, not a workspace.

Auto-resolve the clean, confident ones:

  1. Below the stage graph, open the Auto-Decide policy card. Set Enabled = true and Applies To = approve — auto-resolve clean cases; always keep human eyes on the rest.
  2. Leave Min Confidence at its default 0.92 and Require Zero Flags = true. The preview reads roughly “Auto-approve when AI confidence ≥ 0.92 AND zero flags.” Now a ticket the classifier is confident about — and that isn’t urgent — can resolve without a human; everything ambiguous, flagged, or urgent still routes to the Inbox.

Under the hood. Auto-decide never spoofs a user — an auto-resolved ticket’s audit row shows actor AI/auto plus the confidence. Every stage move is written to the audit trail; the “decision” is that trail.

Checkpoint. Validate the lifecycle: exactly one Start, one End, a Start→End path, no dangling cycles. If it complains, fix the graph before saving.

Stage 6 — Test the whole loop

Drop in a spread of sample tickets and watch them classify and route.

  1. Seed varied tickets via Upload (Stage 3): a clean billing question (“Why was I charged twice?”), a technical bug (“App crashes on export”), a routine account change (“Please update my email”), and a genuine emergency (“Production is DOWN, losing data”). Add one deliberately vague one (“It’s broken, help”).
  2. Watch classification. Each ticket fills in category / priority / sentiment with a confidence. Confirm the emergency reads urgent / high and the vague one comes back with a low confidence.
  3. Watch routing. The clean, confident, non-urgent tickets auto-resolve (Auto-Decide) — check their stage history shows actor AI/auto. The urgent and low-confidence ones route to the review stage and appear in the Inbox (App ▸ Inbox), grouped under Needs Review (or To Triage).
  4. Act on one — the right way. In the Inbox, find an item, read its provenance line (wraps ▸ Support Intake · <docId> · <stage>), then click Open. Notice you leave the Inbox entirely and land on the document detail page — that is where you correct the category or advance the ticket. Advance it; return to the Inbox and confirm the note self-resolved.
  5. Try the Input Form. Submit a ticket through your Log a ticket form and confirm it gets classified and routed exactly like an emailed one.

You’re done when an emailed, uploaded, or typed ticket is classified, the easy ones vanish via auto-resolve, and the hard ones queue in the Inbox where a human opens the wrapped ticket to act.

Make it production-worthy

Three upgrades, each a real surface from the chapters.

A route-mode multi-agent team of specialists. So far one agent does all the classifying. For richer handling, make the leader route each ticket to a specialist sub-agent (Teams & mesh). A route-mode team has the leader pick the single member best suited to the request and hand off — exactly the triage shape.

  1. Build two specialist agents the normal way (Stage 4): a Billing Specialist (instructions tuned for refunds/charges) and a Tech Specialist (tuned for bugs/outages).
  2. Open your Triage Classifier agent → Subagents tab. Set Coordination mode = route.
  3. + Add subagent twice: add Billing Specialist and Tech Specialist, each with a short Prefix telling it how to behave inside the team.
  4. Save Agent. The leader now classifies and routes each ticket to the one specialist that fits. A team runs in-process as one agent run; it does not survive a restart, and every member must be an agent. If you needed durable, long-running, or cross-runnable routing you’d reach for a Mesh instead — but a route-mode team is the right, simpler tool here. You can also require human approval before the leader hands a ticket to a specific member — set it on Governance ▸ Approvals ▸ Team agents.

An SLA webhook. Tell your systems when a ticket breaches its SLA, using an Event (Taxonomy, lifecycle, tags & events). On Support Intake ▸ Events:

  1. + Event → Name Urgent SLA breach. Choose the stage-change trigger, scope Workflow to your lifecycle and Stage to the urgent review stage.
  2. + Add Action → Notification Type Webhook → your endpoint (or a Slack action to ping the on-call channel).
  3. Show Advanced Settings → tick Check SLA Breach and set SLA Time (sec) — now the event fires when an urgent ticket sits unattended too long.

A triage dashboard. Give the team a bird’s-eye view — consumers read it (Dashboards & inbox); you build it in Studio ▸ Intelligence (Shaping the experience). Widgets worth having:

  • Volume by category — a bar or donut chart over the category label.
  • % auto-resolved — a stat tile (auto-decided count ÷ total).
  • Queue depth — a status breakdown of how many tickets sit in each review stage, plus an overdue count mirroring the Inbox’s overdue chip.

Consumers read these on App ▸ Overview; you configure them in Studio.

This classify → route → auto-resolve-or-Inbox shape is reusable for any intake-and-sort problem: lead routing, document-type sorting, claims triage, content moderation queues. Swap the categories, keep the skeleton.

Where to go next

Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.

See the platform live