The Tickets Pile Up, and Half Are the Same Question
Open the CS inbox. Refund requests, shipping status, login problems, plan questions… dozens to hundreds a day. And a large share are repeat questions with fixed answers. Only some genuinely need human judgment.
The catch: to find that "some," a human has to read all of it. You wade through 30 shipping-status checks to reach the one truly angry customer. That's a triage problem — quickly classifying incoming tickets, drafting first-line replies, and routing to a human only what needs one.
This post is a recipe for that triage on a Marblo board. It takes the hybrid-CS strategy from AI chatbots vs. traditional CS and turns it into an actual board. We'll assume you've done the first multi-agent tutorial once.
Why One Chatbot Isn't Enough
"Can't I just bolt on a CS chatbot?" — the real problem with a single chatbot is that it answers confidently even when it shouldn't. Misstate a refund policy, or send a boilerplate reply to an angry customer, and the automation erodes trust instead of building it.
Triage, too, is a bundle of different kinds of work:
- Classification — type, urgency, sentiment (fast and cheap, at volume)
- Draft reply — accurate, only when the knowledge base supports it (RAG)
- Safety check — filtering out policy violations and wrong guidance (independent judgment)
- Routing — reply draft if confident, human if not
Splitting these across models with different strengths is the heart of heterogeneous agents. A Marblo board wires the four stages visually and traces how each ticket was handled.
Recipe Architecture
[Intake: email / chat / contact form]
│
▼
classifier
│
▼
responder (draft reply · knowledge-base RAG)
│
▼
safety_checker (policy + accuracy)
│
┌────┴─────────────────────┐
▼ ▼
[High confidence] [Violation / uncertain / strong negative]
Rep approval queue Escalate straight to a human
(draft attached)
The core design: no ticket fully bypasses a human unsafely. Confident cases go to a rep as a draft; ambiguous ones go straight to a person. Even when the automation errs, it doesn't reach the customer as-is.
Station by Station
1. classifier — Classification
This station skims a high volume of tickets, so speed and cost matter more than reasoning. A light, cheap model (Claude Haiku or Gemini Flash) is plenty.
Role: classifier · System prompt, in essence:
You are a CS ticket classification agent. Take a ticket and classify it
as JSON only.
- type: refund / shipping / account / billing / other
- urgency: high / medium / low
- sentiment: negative / neutral / positive
- kb_answerable: does this look answerable from the knowledge base? (true/false)
- needs_human: true if the call is ambiguous
If unsure, set needs_human to true. Handing to a person beats a wrong
classification.
2. responder — Draft Reply
Accuracy is decided here. Replies must be grounded in the company's actual knowledge base (FAQs, policy docs, manuals). In Marblo you connect the knowledge base as an MCP tool so the responder can search relevant docs (RAG). For why MCP became the standard for this kind of tool connection, see the MCP guide. Grounded answers want long-context reasoning, so Claude fits.
You are a CS reply-drafting agent. Take the classification and the
original ticket, and draft a reply **only when the connected knowledge
base supports it**.
- Cite the source document
- Never invent anything not in the knowledge base
- If there's no support, return "No knowledge-base support" instead of a draft
- Match tone to the customer's sentiment
That second-to-last rule is decisive — if there's no basis, don't fabricate; raise your hand. That's what blocks wrong guidance at the source.
3. safety_checker — Safety Check
Verifies the draft against policy and accuracy before it can be sent. Crucially it uses a different vendor (Gemini) — a model checking its own draft shares its own misconceptions.
You are a CS safety-verification agent. Take the draft reply and the
source documents, and verify:
- Does it match refund/compensation/policy rules exactly?
- Does it avoid promises (discounts, exceptions) beyond knowledge-base support?
- Is the tone appropriate given the customer's sentiment?
If there's any violation, flag it and state the reason.
4. Routing — Only Escalate What Needs a Human
Cases that pass safety_checker and that classifier marked high-confidence go to the rep approval queue with the draft attached. Policy violations, needs_human, and strong negative sentiment escalate straight to a person with no draft.
Where the Human Comes In — Start With "Agent-Assist"
The most important principle: don't auto-send from day one. Run it as agent-assist at first — the agent drafts, and the rep approves or edits before sending. Instead of writing from scratch, the rep just reviews a polished draft. Throughput rises while control stays with the human.
After a few weeks of approving and confirming that verification passes reliably, pick low-risk types (say, shipping-status checks) and move only those to auto-send. For how to widen trust in layers like this, see the 5 principles of AI agent governance.
Real Numbers and Honest Limits
The metrics this recipe tends to move are first-response time, tickets handled per rep, and the share of repeat tickets handled automatically. Thanks to the approval queue, reps trade writing time for reviewing time.
Honestly, complex or emotional tickets still need a human — and they should. What this recipe removes is classification and drafting labor, not judgment. The goal is to get past 30 shipping-status checks and reach the genuinely upset customer faster and with more focus.
FAQ
Q. What if a wrong answer reaches a customer?
Two layers of defense — safety_checker (different-vendor verification) plus the rep approval queue. Starting in agent-assist means a human sees every draft before it sends. Automate low-risk types only after trust is built.
Q. Our knowledge base is thin. That's a problem to fix first. RAG answers are only as accurate as the source docs. If anything, prepping this recipe is a good reason to tidy up your FAQ and policy docs.
Q. We get tickets in multiple languages.
Add a language-detection/translation station before classifier, or make responder multilingual. The architecture scales unchanged.
Q. What does it cost?
Multi-agent boards are available from Marblo Pro (from ₩19,000/month), plus per-run API charges. Putting classifier and safety_checker on cheaper models cuts per-ticket cost substantially.
Build It Yourself
To build this board against your own tickets and knowledge base, book a free 30-minute session and the Marblo team will design your first triage board with you. Or just start free on Marblo.
Related Posts
- AI Chatbots vs. Traditional CS: Cost and Satisfaction, Compared
- Building Your First Multi-Agent System with Marblo
- Why Heterogeneous AI Agents Beat a Single Model
- 5 Principles of In-House AI Agent Governance
Last updated: 2026-07-10. Marblo's UI improves often, but the board recipe pattern is stable.