Build: Support intake triage

In one line. Inbound support items — emailed, uploaded, or typed — are sorted into a category by an agent, the lifecycle sends each category to its own queue, and each queue lands in a human Inbox. You’ll build. A triage pipeline: a Processing collection, a list of categories (billing, technical, account, urgent, other), 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

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 (sort): Billing / Technical /
 Input Form (typed)──┘                        Account / Urgent / Other
                                 worker: Triage Classifier picks one category
                                 lifecycle: Intake ──► Route by category
                                   ──► Billing / Tech / Account / Urgent queue
                                   ──► Needs triage (Other)
                                   each queue ──► Inbox (a 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 — the Create Collection dialog opens.
2. Purpose: pick Processing (the choices are Knowledge, Processing, Structured and Dataset (Evaluation)). Collection Name: Support Intake. Description: Inbound support items to be classified and routed. Leave Allowed Ingestion Types and the rest at their defaults; optionally turn on Set as Primary if this is the project’s main intake target.
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 · Capacity; a Knowledge collection adds Index Health, a Structured one Schema). 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 (sort the item into a category). Triage is mostly classification. The way the product sorts is the one in Sorting documents into types: a taxonomy of Type Document Classification whose labels are the categories, and an agent that picks exactly one of them — or none.

Vocabulary. A Taxonomy owns a group of labels. On an extraction taxonomy a label holds a value copied out of the text; on a classification taxonomy each label is a category, and the agent marks the item with one of them. 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. Taxonomy Name: Ticket Details · Description: Who/what the ticket is about · Type: Section Classification — the type the dialog starts on, and the one an extraction taxonomy uses. Submit.
3. Select Ticket Details, open its Labels tab, click Label, and add (using Add between, Add and exit on the last): customer_name — Description: The requester's name; subject — Description: The ticket's subject line or summary; account_id — Description: Any account/order reference mentioned. The classifier below does not fill these: a person fills them on the ticket, or the Input Form (Stage 3) captures them as the ticket is typed.

Then the Triage taxonomy — the heart of this build. Its labels are the categories:

4. Taxonomy tab → Taxonomy (footer). Taxonomy Name: Triage · Description: Which queue this ticket belongs in · Type: Document Classification. Submit.

5. Select Triage, Labels tab → Label, and add one label per category. The Description is what the agent reads to decide, so say what belongs:

   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
   Other	Anything that fits none of the above

   Other is there because the product has no built-in “unclassified” category: a ticket that fits none of your labels is otherwise left with no category at all.

What this build does not do. One classification agent sorts on one taxonomy, and a collection runs one intake agent. So this build sorts by category only. Priority or sentiment would each be a taxonomy of its own (High / Medium / Low), sorted by another agent run another way — for example from an XFlow (XFlows & pipelines). The same holds for the Ticket Details labels: a collection runs one intake agent, and this build gives that one job to the classifier.

Checkpoint. The Labels tab of Triage lists Billing, Technical, Account, Urgent and Other.

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. Give it a Display name, choose how it signs in to the mailbox (IMAP with a username and password is one choice), fill the details and click Test connection — an Email connector cannot be created until the test passes. Create connector.
2. + Job → Step 1: pick the Email connector. Step 2: Job name Support mailbox, Folder INBOX, tick Include attachments, and pick Support Intake as the Target entity. Step 3: Recurring (every N units) → Run every 15 Minutes (or a cron). Check the Next 5 runs preview → Create job.

Upload — ad-hoc and smoke tests:

3. The Upload toolbar button takes a one-shot batch — no connector or job needed. Drag in files, set Target collection to Support Intake, and click Upload N (N is the number of files). 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, and the collection’s Add-Data settings say which forms people may fill in it:

4. Go to Studio ▸ Data ▸ Input Form → + Input Form (at the foot of the list) → Type: Create Source. Name it Log a ticket.
5. Add Columns mapped to your Ticket Details labels — 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 label. Create.
6. Point the collection at the form: select Support Intake, open its Ingestion tab and click Add-Data settings. Under Methods users can use, tick Fill a form; under Allowed forms, tick Log a ticket; make sure Run the collection’s agents automatically when data is added is ticked (it is by default), so the classifier sorts what is typed; click Save. People adding data to Support Intake can now pick Fill a form and type a ticket into it.

Checkpoint. Drop 3–5 sample tickets via Upload. Each appears in the document list; add the Ingestion Progress column to watch each one’s bar fill. If a bar does not move, processing hasn’t started — see Ingestion & connectors.

Stage 4 — Build the “Triage Classifier” agent

The agent reads each item and marks it with one Triage category. 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: Sorts inbound support tickets into one category. For Instructions, click the ✦ button beside the field to have the co-pilot draft them from “Sort a support ticket into one category,” then edit the draft to read roughly:

   You are a support-triage assistant. Read the subject and body of each
   inbound ticket and pick the one category it belongs in. Anything that
   reports an outage, data loss or a security issue is Urgent. When the
   ticket fits none of the categories, pick Other.

3. Model tab. Pick your project’s language model, and keep Temperature low under Advanced sampling dials. (The editor’s tabs are Persona, Model, Knowledge, Capabilities, Output, Governance, Context, Subagents and Harness Summary; this build needs Persona, Model and Output.)

4. Output tab. Turn on Structured output. Under Taxonomy, pick Triage in Taxonomy / learner, and under Labels click Add all — every category comes in with its description. Turn on Auto-annotate document: it is what writes the chosen category onto the ticket. The agent picks exactly one category, or none; the category carries no confidence score.

5. Save Agent.

6. Test it in the playground on the right with one of your sample tickets, and read the category it picks. Feed it an off-topic ticket and confirm it picks Other.

7. Assign it to the collection. Open Support Intake ▸ Agents: with no agent assigned yet, pick Triage Classifier under Assign to:; if the collection already has an intake agent, use + Change Intake instead. From now on every item that lands — emailed, uploaded, or typed — is sorted as it arrives.

Checkpoint. Upload a fresh ticket and watch its category appear on the document.

Stage 5 — Route by category: one queue per category, each in the Inbox

This is where classification becomes routing. A Lifecycle is the ordered stages a document moves through (Taxonomy, lifecycle, tags & events) — not an XFlow. Open Support Intake ▸ Lifecycle — the seeded Four-Eyes flow is already there, and new tickets arrive in its Intake stage. Sorting documents into types explains each setting below.

One thing first. After the classifier writes a category, the platform moves the ticket on. If the lifecycle has a stage named L1 Review — the seeded one does — every ticket goes straight there, whatever its category. Rename that stage (e.g. Review) before you start, or your routing never runs.

The queues:

1. Add a stage per queue with + Stage above the stage graph: Billing queue, Tech queue, Account queue, Urgent queue, and Needs triage for Other and for any ticket left with no category. (A collection with no lifecycle at all shows Add Lifecycle instead; this one already has the seeded one.)
2. On each queue 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.
3. Gate each queue with Can be viewed by (under Show Advanced Settings) to the persona that handles it. Create personas on Studio ▸ Governance ▸ Users & Access ▸ Personas — a Billing-Handler and a Tech-Handler persona map neatly onto two queues, and only their holders then see and act on tickets resting there (Access & roles).

The routing stage:

4. Add a stage Route by category. Open it with its pencil (Edit Stage), click Show Advanced Settings, set Workflow Type to Automated and Automation Type to Conditional, and list all five queues in Can be moved to. Leave Confidence threshold at 0.
5. One block is already there; click Add for each further category, so there is one block per category. In each block, under Label Conditions, pick the category as the Label and leave its slider at 0; open the row’s list menu and turn on Is Mandatory. Set Success to that category’s queue and leave Failure empty.
6. The way out for a ticket with no category. Click Add once more. In this last block add one row per category — Billing, then Technical, Account, Urgent and Other, each with Is Mandatory on and the Gate of every row after the first set to OR — and set Failure to Needs triage, leaving Success empty. The block passes when the ticket carries any category, so only a ticket with none goes to Needs triage, where a person sorts it.
7. Open Intake and add Route by category to its Can be moved to (under Show Advanced Settings) — the only Automated stage it leads to.

Why the blocks are set this way: without Is Mandatory, a condition on a category the ticket does not have counts as met; and every block’s choice is carried out, so a Failure stage on a category’s block would receive every ticket of the other categories too.

Start simple: wire one category first, prove a ticket reaches its queue and the Inbox, then add the rest.

The one point not to miss — you act on the wrapped document, not in the Inbox. The Inbox (Dashboards & inbox) offers Open, Snooze and 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 review stage resolves the Inbox item automatically. The Inbox is a worklist, not a workspace.

No auto-resolve here. The Auto-decide policy card lets clean documents be approved or declined without a person — but it acts on an agent’s approve-or-decline recommendation, and a classifier gives none. For triage it does nothing; every ticket reaches a person’s queue.

Checkpoint. Each stage saves with Save Workflow Stage in its editor (Save changes above the graph saves only phases). Then upload one ticket per category and watch each reach its queue.

Stage 6 — Test the whole loop

Drop in a spread of sample tickets and watch them sort 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”), a genuine emergency (“Production is DOWN, losing data”), and one off-topic note (“Thanks for the lunch yesterday”).
2. Watch sorting. Each ticket gets one category. Confirm the emergency reads Urgent and the off-topic note Other.
3. Watch routing. Each ticket moves to its queue — open one’s stage history to see the moves. Each queue item appears in the Inbox (App ▸ Inbox).
4. Act on one — the right way. In the Inbox, find an item and 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. Add a ticket to Support Intake with Fill a form and Log a ticket, and confirm it is sorted and routed exactly like an emailed one.

You’re done when an emailed, uploaded, or typed ticket is sorted into a category, reaches that category’s queue, and appears in the Inbox where a human opens the wrapped ticket to act.

Make it production-worthy

Two upgrades, each a real surface from the chapters.

Why not a team that picks a specialist? An agent can hand each ticket to one member of a team (the Auto Select mode on its Subagents tab). Do not do that to the classifier: the chosen member’s answer is what gets written onto the ticket, not the category, so routing by category stops working. Keep the classifier on its own; give specialists their own queue instead.

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. In Events, pick the stage event (Document State — the product shows your collection’s own word for a document), then set Workflow to your lifecycle and Stage to Urgent queue.
2. Add Action → set Action to Webhook and give your endpoint (or Slack, to ping the on-call channel).
3. Show Advanced Settings → turn on Check SLA Breach and fill in SLA Time (sec): — now the event fires when an urgent ticket sits unattended that 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 Triage labels.
• Queue depth — a breakdown of how many tickets sit in each queue.

Your team reads the page in the consumer app; you build and change it in Studio.

This classify → route → 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

• Sorting documents into types — the sorting and routing settings, and why each matters.
• Taxonomy, lifecycle, tags & events — the Conditional automation and Auto-Decide in full.
• Build: Contract review — the next end-to-end build.