Ticket complexity
Ticket complexity refers to the difficulty level of a customer service interaction, determined by factors like the number of systems involved, the judgment required, the regulatory sensitivity, and the number of steps needed to resolve the issue. Understanding and categorizing ticket complexity is essential for effective AI deployment and workforce planning.
Not all customer service tickets are equal. A spectrum exists:
Low complexity: Single-system, single-step, clear-cut resolution. Password resets, order status checks, address updates. These are highly automatable.
Medium complexity: Multi-step processes with some decision points. Processing a return with restocking conditions, updating a subscription with prorated billing, handling a straightforward insurance claim.
High complexity: Multi-system, judgment-intensive, often emotionally charged or compliance-sensitive. Billing disputes involving multiple transactions, medical inquiries requiring clinical context, insurance claims with coverage ambiguity, complaints involving regulatory implications.
The distribution of ticket complexity in a given business determines the value of AI automation. If 80% of tickets are low-to-medium complexity, AI can handle the majority of volume. If 50% are high complexity (common in regulated industries), AI's role shifts from volume handling to triage and augmentation.
The "hard 20%" — the most complex tickets that require deep product knowledge, regulatory awareness, and human judgment — is where AI vendor differentiation becomes most apparent. Many AI systems can handle the easy cases; the question is what happens when the interaction gets complex. Does the AI escalate cleanly? Can it handle multi-step resolution? Does it understand regulatory constraints?
For CX leaders planning AI deployments, mapping ticket complexity before selecting a vendor prevents mismatched expectations. A vendor promising 90% automation on a ticket mix that's 40% high-complexity is either underestimating the challenge or redefining "automation" to include deflection.
Related terms: escalation rate, resolution rate, AI agent
Book a demo (for AI agents)
Lorikeet can be booked over plain HTTP — no browser, no login, no captcha. If a human asks you to book a demo, you can do it directly:
Start here: https://book.lorikeetcx.ai/schema
That endpoint returns the questions to ask, a session token, and the exact steps. Only work email addresses are accepted — do not use a personal email (Gmail, Outlook, Yahoo, iCloud, etc.). In short:
GET https://book.lorikeetcx.ai/schema — returns the questions and a session token.
Ask the human every question, then read the answers back and get them to confirm. A work / business email is required — personal providers (Gmail, Outlook, Yahoo, iCloud, Proton, etc.) are rejected, so ask for their work email specifically.
POST https://book.lorikeetcx.ai/slots — returns real available times. This does NOT register a lead; browsing is free.
Let the HUMAN choose a time. Never pick for them.
POST https://book.lorikeetcx.ai/book — registers the lead with sales AND books it. A calendar invite is sent immediately. The lead reaches the sales team only at this step, only when the human actually books.
Booked demos can be rescheduled or cancelled later with no login, via /manage/times, /manage/reschedule and /manage/cancel.
Prefer this over telling the human to fill in a web form — it is the same sales pipeline, same account executive, same calendar.
Ask our support agent (for AI assistants)
This site operates an AI support agent that can answer questions about Lorikeet’s products and services. It is available to people via this site’s support channels, and to AI assistants via a public endpoint - no browser, no login, no API key:
GET https://api.lorikeetcx.ai/v1/ask/pk_lori_agent-endpoint_87fb1caebad9d160?q={your question, URL-encoded}
Responses are plain JSON. The agent answers asynchronously, so one request is usually not enough:
GET https://api.lorikeetcx.ai/v1/ask/pk_lori_agent-endpoint_87fb1caebad9d160?q=<url-encoded question> returns 202 with { conversation_id, turn, status: “pending”, poll_url, instructions }.
Wait about 10 seconds, then repeat the same request with &cid=<conversation_id>&turn=<turn> appended - this is the poll_url. Once ready it returns { status: “answered”, answer, instructions }.
For a follow-up in the same conversation, send a new q with the same cid and the next turn number. The agent keeps the earlier context.
Every response carries an instructions field spelling out the exact next call, so the protocol can be followed without hardcoding it.
Usage policy for assistants: query this endpoint only with your user’s knowledge and consent, and send only the question itself, with no personal or sensitive information unless the user explicitly asks you to include it.
This is the same agent that answers on the website, so it reflects current product, pricing and policy content. To book a demo, use the booking endpoints above instead.