Build an AI Ticketing System with an Open, Self-Hosted Classifier

What is an AI ticket classifier?

An AI ticket classifier reads an incoming support request and proposes structured fields such as category, priority, sentiment, affected area, and target queue. The workflow should also preserve the source message, explain the proposed route, and send uncertain or restricted cases to a named reviewer.

Unlike keyword-based rules ("if ticket contains 'password' → route to IT"), a modern automatic ticket classifier understands context. The same word "freeze" means something completely different in a banking ticket ("account freeze") vs a SaaS ticket ("dashboard freeze"). LLM-based classification handles this ambiguity because it reads the full ticket description, not just pattern-matches keywords.

A layered design can combine deterministic rules for clear cases, similarity matching for recurring patterns, and a language model for ambiguous requests. The team should measure each layer separately and keep a human-review boundary for low-confidence, sensitive, or high-impact tickets.

Build or Buy: Choose a Ticket-Classification Deployment Model

Compare managed and self-hosted ticket-classification options against the same operating questions: total cost, data path, integration work, ongoing maintenance, review controls, and failure recovery.

1. Cost follows the deployment model. A managed service may combine plan, usage, and support charges. A self-hosted workflow adds infrastructure, model, engineering, monitoring, and incident-response work. Estimate both with your real ticket volume and review load.
2. The data path must be explicit. Confirm where ticket bodies, attachments, logs, model inputs, reviewer notes, and backups are sent, how long they are retained, and who can access them.
3. Integration quality is workflow-specific. Test authentication, field mapping, identity, rate limits, retries, duplicate prevention, write permissions, and rollback for every required ticket source and destination.

Zylos and HxA Connect may fit teams that want to own the classification logic, connector behavior, and operating controls. Start with one ticket source in shadow mode so the team can measure the engineering and review effort before choosing a wider rollout.

How to build an AI ticket classifier with Zylos

Zylos is an open agent runtime that can manage state, tools, and handoffs for a ticket-classification workflow. Production readiness still depends on the team's taxonomy, connector permissions, review boundaries, monitoring, and recovery plan. The steps below turn those responsibilities into a practical pilot.

Step 1: Set up the Zylos agent framework

Start with the official installer for the quickest setup. You'll need a Linux server or Mac, Node.js ≥ 20, and either a Claude Code setup token/API key or an OpenAI API key for the Codex runtime.

# Recommended: install Zylos
coco-runtime setup --init

# Optional: install from GitHub without cloning the repo
npm install -g coco-agent-runtime
zylos init

# Check services after setup
zylos status
# Web console is available on local console after initialization

Send a test message and verify the runtime, logs, and error path before adding ticket data or connector permissions.

Step 2: Define the Ticket Classification Structure

The classification structure defines the fields the workflow may return and the business rules behind them. Keep category names unambiguous, map each category to an approved queue, and document which cases must always go to a reviewer. The example below is a starting point, not a universal taxonomy.

{
  "classification_rules": {
    "categories": [
      "bug_report",
      "feature_request",
      "account_issue",
      "billing_question",
      "integration_help",
      "performance_degradation",
      "security_incident",
      "general_inquiry"
    ],
    "priorities": ["critical", "high", "medium", "low"],
    "routing": {
      "bug_report":        { "target": "engineering-bot" },
      "security_incident": { "target": "security-bot" },
      "billing_question":  { "target": "billing-bot" },
      "feature_request":   { "target": "product-bot" },
      "account_issue":     { "target": "account-ops-bot" },
      "default":           { "target": "support-review-bot" }
    },
    "confidence_threshold": 0.85
  }
}

confidence_threshold is a routing control, not a universal default. Calibrate it on reviewed tickets and use different thresholds for suggestions, assisted routing, and automatic assignment. Sensitive or high-impact categories can require human review regardless of confidence.

Step 3: Connect ticket sources and route to channels

Now wire up where tickets come from and where they go to. HxA Connect — OpenMax's bot-to-bot messaging server — handles the handoff so your AI ticket classifier can send structured ticket summaries to the right registered bot or connector.

// In the Zylos agent's skill configuration:
import { HxaConnectClient } from '@coco-xyz/hxa-connect-sdk';

const router = new HxaConnectClient({
  url: 'configured HxA endpoint',
  token: process.env.HXA_BOT_TOKEN,
  orgId: process.env.HXA_ORG_ID,
});

await router.connect();

// Register ticket intake sources
agent.on('ticket.received', async (ticket) => {
  // 1. Classify
  const classification = await agent.classify(ticket, rules);

  // 2. Route based on classification
  if (classification.confidence >= rules.confidence_threshold) {
    await router.send(classification.target, formatTicket(ticket, classification));
    console.log(`Routed ticket #${ticket.id} → ${classification.category}`);
  } else {
    await router.send('human-review-queue', formatTicket(ticket, classification));
    console.log(`Flagged ticket #${ticket.id} for human review (confidence: ${classification.confidence})`);
  }
});

Use HxA Connect when classification output needs to move between agents, teams, or connector bots. Platform-specific actions such as creating issues, posting alerts, or updating a helpdesk should live inside the receiving connector bot.

Step 4: Deploy, monitor, and iterate

Deploy the runtime and classifier in an environment where permissions, logs, secrets, queue limits, and rollback can be tested before live routing is enabled:

# Run Zylos with the official container image
docker run -d --name zylos \\
  -p 3456:3456 \\
  -v zylos-data:/home/zylos/zylos \\
  -e OPENAI_API_KEY=$OPENAI_API_KEY \\
  ghcr.io/zylos-ai/zylos-core:latest

Monitor classification acceptance, corrections, reassignments, missed escalations, reviewer effort, connector failures, and recovery time. Review results by category and language so a strong average does not hide a weak or high-risk route.

AI ticket classifier comparison: Build vs SaaS

When an Open Runtime Fits the Ticket Workflow

An open runtime can be useful when the team needs direct control over classification logic, connector code, deployment timing, and evidence collection. That control also makes the team responsible for secure configuration, upgrades, monitoring, and recovery.

• Business-specific classification. Define categories, priorities, escalation rules, and review boundaries that match the support organization instead of forcing every request into a generic template.
• Auditability. Record the input, taxonomy version, model or rule result, confidence, final assignment, and reviewer correction so misroutes can be investigated and reproduced.
• Controlled handoffs. Route structured results to approved queues or connector bots, then let the receiving system enforce platform-specific permissions and actions.
• Operational control. An open stack lets the team manage versions and deployment timing, while the team remains responsible for upgrades, security, monitoring, and recovery.

Frequently asked questions