How It Works

This article explains the architecture of the KarmaFlow helpdesk for a technical audience: the ticket model, how every channel feeds one system, the ticket lifecycle, and why being CRM-native matters. It stops short of configuration steps — those are in the signed-in documentation.

The Ticket Model

A ticket is a durable operational object, not a message thread. Each ticket carries:

A human-readable number (e.g. #1042) both sides reference
State — its status, owner, priority, type, and tags
SLA timers — first-response and resolution clocks
Visibility — who, on the customer side, may see it
A complete history — every reply, internal note, status change, and assignment
Origin links — the chat, call, email, form, or automation that created it

The distinction from a conversation is deliberate. A conversation ends; a ticket persists, can span several conversations and channels, and remains the accountable record of one customer issue from open to close.

One Model, Every Channel

Tickets enter from every channel KarmaFlow supports, and all of them resolve to the same ticket object:

Channel	How it becomes a ticket
Email	Mail to your support address opens a ticket; replies thread back automatically by message headers (with a `[#number]` subject fallback)
Customer portal	Customers open and track tickets directly in a branded, signed-in portal
Website chat	A chat agent can open a ticket mid-conversation, or an escalation creates one
SMS & voice	SMS and voice agents open and update tickets during a text thread or call
Web forms	Any form can be configured to open a ticket on submission
API & MCP	Create and manage tickets programmatically, or let any connected AI agent do so over the Model Context Protocol

Whatever the channel, the ticket records where it came from and links back to that originating interaction — so context is never lost between the conversation and the ticket.

The Lifecycle

Tickets move through a clear set of states. Some transitions are manual; others happen automatically — a staff reply moves a ticket to pending customer; a customer reply on a solved ticket reopens it; a solved ticket closes automatically after a configurable window.

stateDiagram-v2
  state "Pending customer" as PC
  state "Pending internal" as PI
  [*] --> New
  New --> Open: picked up
  Open --> PC: staff reply
  PC --> Open: customer replies
  Open --> PI: waiting on team or vendor
  PI --> Open
  Open --> Escalated: specialist or human requested
  Escalated --> Open
  Open --> Solved: resolution provided
  Solved --> Open: customer reply reopens
  Solved --> Closed: auto-close after window
  Closed --> [*]

Status	Meaning
New	Created, not yet picked up
Open	Someone is actively working it
Pending customer	Waiting on the customer — the SLA clock pauses
Pending internal	Waiting on another team, vendor, or approval
Escalated	Handed to a specialist, or the customer asked for a human
Solved	Resolution provided; the customer is invited to rate it
Closed	Finalized automatically after the reopen window

CRM-Native by Design

The helpdesk isn't a separate silo. Every ticket requester is a CRM contact, and their company is a CRM account — so a ticket is grounded in the customer's full history across voice, chat, SMS, email, and deals, and support activity enriches the same account intelligence your revenue team uses. There is no integration to build and no data to sync: it's one platform.

This is also what makes the AI effective. The same agents, the same knowledge, and the same customer memory power both your outbound work and your support — so an AI answering a ticket already knows who it's talking to.

Want to set one up? Configuration and day-to-day operating guides are in the signed-in documentation. Sign in to KarmaFlow to read them.