Development of an AI system for automatic ticket creation after an inquiry

Automatic ticket creation: where request processing breaks

A request arrives by email, messenger, and website form — and already at the entrance to first-line support, manual triage begins. The operator reads the text, determines the topic, manually creates a ticket, and transfers contacts and description into it.

Here, too, part of the context is lost: attachments are not attached, the essence of the request is retold in one's own words, and the client is left without a ticket number and without understanding who is handling it.

Next failure — duplicate tickets. One client writes in chat, duplicates by email, and calls: three independent requests appear in the system, handled by different assignees.

The client receives contradictory answers, and the team wastes time reconciling versions instead of solving the task.

Then the support request queue suffers: a ticket without an explicit route remains in the common first-line inbox queue. Responsibility for it is blurred, response deadlines are not counted, and priority is determined by whoever reminded about themselves loudest.

Lost requests are a direct consequence of this arrangement: an email received outside working hours or buried in an operator's personal folder does not become a ticket and surfaces only after a client complaint. Some requests never reach the assignee, and we learn about it from the customer, not from a report.

The root of all these failures is the same: triage, classification, and routing rest on a person, not on rules. Below we analyze how this is closed at the system level.

What changes after implementation: speed and completeness of triage

The effect of implementation is measured not by "it became more convenient," but by numbers taken from the support reporting dashboard. We record them before launch and accept the system according to this list — each line is taken from a standard export for the period.

• [ ] Share of requests triaged without a human. The model reads the request text, extracts entities, and closes typical scenarios itself — in high-volume topics this is 60–75% of the incoming flow.
• [ ] Time to assignee assignment. A request no longer waits for manual sorting in the queue: the time is reduced from tens of minutes to seconds, and the first response arrives in the same session.
• [ ] Share of returns for clarification. If the ticket lacks product, version, or reproduction steps, the assignee returns it to the author — the target for this metric is a clear percentage of the total number.
• [ ] Eliminated class of routing failures. Erroneous assignments between queues (a payment request landing in technical support) cease to be a systemic problem: the queue is selected by content, not by the form of the request.
• [ ] Support workload. Freed hours go to complex cases, not to mechanical sorting and rewriting fields.
• [ ] Ticket completeness. Required attributes are filled at intake from request data, not from the memory of the author or operator.

We configure integration with the ticketing system — in our case Jira Service Management and equivalent platforms — so that each metric is calculated by standard reports, without manual summaries.

Ways to receive requests: rules, classifier, language model

The flow of requests is heterogeneous: some come through a form with ready-made fields, some as free text from chat and email. How the incoming flow is triaged determines whether a request reaches the right group immediately or lingers in the common queue.

The choice between rules, a classifier, and a language model is a choice between predictability of the result and flexibility to formulations.

When choosing, three things are considered: uniformity of formulations, volume of accumulated history with assigned categories, and requirements for explainability of the decision.

Rules give a deterministic result and full control, but require manual editing with every new formulation. The model handles free text, but requires field validation and processing of uncertain cases.

The hybrid triage scheme takes the best from each approach: rules filter out the obvious and do not waste model resources, the model parses free text, and low-confidence requests go to the operator with an already filled ticket draft.

Implementation stages: from request audit to first tickets

Automatic ticket creation is not a model by itself, but a pipeline: request intake, meaning triage, queue and priority determination, recording in the ticketing system.

An error at any step costs more than manual triage: an incorrect ticket goes to the wrong assignee and returns to the author. Therefore, work proceeds from flow audit to a pilot on historical data — each subsequent stage relies on the measured previous one.

1. Request flow audit. We count channels, request types and their shares, and repetitiveness of formulations. The output is a category map and draft routing rules.
2. Triage scheme. We agree which ticket fields are filled automatically (subject, category, priority, assignee) and which remain with a human, and in what form the system returns the result.
3. Integration setup. We connect request sources and the ticketing system: email, chat, website form, internal portal. Separately, we check that repeated email delivery does not create a second ticket.
4. Confidence threshold. Each triage receives a confidence score. Above the threshold, a ticket is created immediately; below, it goes to the operator with pre-filled fields, so the decision remains with a human.
5. Pilot on historical data. We run closed requests and compare category, priority, and assignee with what was decided manually. Based on discrepancies, we adjust rules and prompt wording.
6. Acceptance of triage quality. We record target accuracy by category and the share of requests accepted without edits, and analyze the most frequent error classes.
7. Handover to operation. We set up monitoring of the autofill share, a procedure for reviewing disputed cases, and a procedure for changing thresholds without stopping request intake.

What we hand over: schemas, routing rules, regulations

The delivery package is not a folder with descriptions, but the working part of the loop. Using these documents, your support service independently changes routing rules, adds categories, and investigates incidents without waiting for us. Below is what is included in the handover and why each element is needed.

• Integration schema — request intake channels, ticketing system, knowledge base: exchange direction, data format, behavior when an external system is unavailable.
• Routing rules — correspondence "topic → queue → assignee → priority" and the procedure when classification yields two equivalent categories.
• Escalation regulation — model confidence thresholds, response times by priority, and the request handover chain if automatic triage produced no result.
• Access policies for request data — which employees and services see texts, where copies are stored, how personal data is masked, and how the access log is maintained.
• Labeling documentation — taxonomy of categories and priorities, examples of borderline cases, triage rules; with it, a new employee reaches agreed quality.
• List of accounts and permissions — which service accounts are needed, which permissions are granted, and where rate limits apply.
• Model maintenance regulation — quality metrics, frequency of checks on fresh data, retraining procedure, and conditions for rolling back to the previous version.

Case: support request triage before and after implementation

Support converged into one queue: emails, website forms, and messenger messages landed in Zendesk without triage. The operator manually determined the topic, selected the queue, and filled the card — category, priority, customer data. This took 15–20 minutes, and a noticeable share of requests went to the wrong group.

Before the project, we captured baseline metrics on a flow of several thousand requests per month — without them, the implementation effect cannot be measured. Below is a comparison before and after launching automatic ticket creation.

Technically, this is three steps: classification of text and attachments by topic, extraction of fields for the card, and a routing rule that selects the queue and assignee.

The key detail is the confidence threshold: if the model is uncertain, the ticket is not created automatically, but goes to the operator as a draft with already filled fields.

Repeat requests fell not because of speed, but because of card completeness: the client was answered on the first try because the ticket immediately had the order, region, and history.

Then the model is retrained on operator corrections — each reassignment becomes an example, so the share of erroneous assignments decreases without manual rule editing.

How does automatic classification differ from routing rules?

Routing rules are deterministic conditions: channel, selected category, account type, dictionary match. Request classification by a model is a probabilistic assessment based on the entire text.

Hence the difference in the nature of errors: rules are explained by one line and give the same answer for the same input; the model generalizes to paraphrases but does not guarantee the result.

Rules are more predictable where the signal is formal: a request from an "payment" form, an email to a known address, a subject with an order number.

Rare topics are also rule territory: dozens of examples are not enough for a stable class; it is more reliable to establish an explicit condition and a separate queue.

In ITIL logic, this is categorization by a pre-described reference book — predictable, but requiring dictionary maintenance.

The model wins on free text: describing a symptom in one's own words, nested conditions, mixed languages. But without a confidence threshold, it confidently errs on rare topics, so answers below the threshold are not routed, but go to manual triage.

The hybrid approach on one flow looks like this: rules as the first layer take formal requests, the remainder goes to the model, low confidence goes to the operator, and their decisions return to labeling.

The triage scheme is chosen by measurement: we run the request history through rules and see what share is closed without the model. The share of automatically created tickets grows, and erroneous routings remain visible in the report.

Common technical doubts before launch

Before launch, the customer's technical side asks the same questions: how the system behaves on a live flow, where automation ends and the operator begins, what happens after changing triage rules. Below are answers to those that most often influence the decision.

What if the topic is rare and there are almost no similar examples?

Such a request does not receive a random category: low triage confidence moves it to the common queue with a flag. The operator sees a ticket draft with already extracted entities and edits it, rather than filling it from scratch.

How is the correspondence history and attachments preserved?

History is labeled by message: channel, author, attachments — everything is linked to the ticket, and does not remain in email or messenger. On a repeat request, the context of previous tickets is pulled in, and the client does not need to describe the problem again.

Does a human remain in the chain, and how is triage quality controlled?

The confidence threshold is configured for your process: higher means more goes to the operator; lower means more is taken on by automation.

After any change to rules or examples, the run on reference requests is repeated, so it is visible on what share the triage remained correct.

Let's discuss the task: what is missing for an accurate assessment

To calculate how the system will triage requests and create tickets, we need data, not a retelling of the pain: a live request flow and the rules by which it is processed today.

Using them, we test the hypothesis on real examples, not on demonstration scenarios, and state timelines and scope of work without "we'll clarify during the process."

• Problem statement: what result we consider successful — the share of requests triaged without an operator, accuracy of topic and priority determination, time from message to ready ticket.
• Request export: 2-3 months of correspondence in text form without personal data, necessarily including cases that operators closed longer than usual — on them the model's boundaries are visible.
• Intake channels: email, website chat, messengers, call transcripts — how many there are, what volume and in what form the text arrives.
• Ticketing systems: where tickets are created, which fields are required, how reference books of projects, queues, and assignees are structured.
• Escalation rules: by what signs a request goes to a human, to whom and within what time, what is considered critical and requires immediate response.
• Data restrictions: requirements for storage and depersonalization, prohibition on transfer outside, whether an isolated environment is needed.
• Implementation plan: which systems and accesses are affected, who accepts the result on the customer side, in which windows we roll out changes.

Describe the task and attach what is available from the list — we will return with an assessment, plan, and list of risks.