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 language model 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 ▸ Collections. Click + Collection at the bottom of the list.
  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 collection list on the left.

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 · Taxonomy · 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 Label on a Classification-type Learner holds the category an item is sorted into, rather than a value copied out of the text. See the Glossary.

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

  1. Select Support Intake → open the Taxonomy tab → click Taxonomy (footer) to open Create Taxonomy.
  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. Taxonomy tab → Taxonomy (footer). Name: Triage · Description: How to sort this ticket · Type: DocumentClassification · Entity: Support Intake. Submit.

  2. Select Triage, + Label. Label Name: category · Description: Which queue this ticket belongs in. Then open Show Advanced Settings ▸ View Config and add a validation rule listing the allowed values — that is how a Label becomes a single-select; there is no “type” dropdown, the validation rule defines the shape (Collections & schema). The four values, and what belongs in each:

    Value What belongs in it
    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 the same way:

    • 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 category, 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). Where: Studio ▸ Data ▸ Ingestion.

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 ▸ Data ▸ 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. If a chip stalls at 0%, processing hasn’t started — 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 ▸ Agents ▸ Agent Toolkit ▸ 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 language 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, Send to Inbox 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) — that is what makes a stage a review stage. When a ticket reaches it, an Inbox item appears pointing at the ticket, remembering which collection, document and stage it came from.
  2. Gate the stage with Can be viewed by to the persona that should handle it. Create personas on Studio ▸ Governance ▸ Users & Access ▸ Personas — a Billing-Handler and a Tech-Handler persona map neatly onto your two branch stages, and only their holders then see and act on tickets resting there (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 item 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.

An automatic decision is recorded as one. The audit row for an auto-resolved ticket shows the agent as the actor, with the confidence — never a person’s name. That honesty is the point. Every stage move is written to the audit trail, and the “decision” is that trail (Audit & compliance).

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) — open one’s stage history and confirm the agent, not a person, is the actor. 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 · the ticket · the 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 item cleared itself.
  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 the agent’s 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 page for the team. Give everyone a bird’s-eye view. Build it on Studio ▸ Experience ▸ Designer ▸ Pages: create a page, place cards from the card library (Studio ▸ Experience ▸ Designer ▸ Cards), and set the page as what your users land on (Shaping the experience). Cards worth having:

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

Your team reads the page in the consumer app; you build and change it 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