--- title: "Automatic Ticket Categorization in 14 Days | JustAutomate" description: "A ticket gets its priority, type and team within seconds of arriving, so nobody sorts the queue by hand. Zendesk, Freshdesk, Intercom, live in 14 days." url: "https://justautomate.ai/en/automations/automatic-ticket-categorization/" lang: en --- Support and customer service # Automatic ticket categorization the queue is sorted before anyone opens it A message from email, a web form or chat gets a priority, a type and an owner within seconds. A language model reads the content and the customer history, a rule checks the plan and the deadline in the contract, and the result lands in Zendesk, Freshdesk or Jira Service Management as a finished label. Support opens a queue already sorted and starts with the most expensive case, not the newest. Book a free consultation [See how the workshop works](https://justautomate.ai/en/services/process-workshop/) - 5 to 10 secondshow long it takes to set the priority, the type and the team, counted from the moment a ticket lands in the system - 14 daysfrom the workshop to the first rule running on your own tickets from the past month - 2 to 6 weeksfull rollout: taxonomy, classification, routing, escalation and measurement after 30 days The problem ## Why does a ticket wait for someone who will only read it? Tickets land in one shared inbox and sit there until somebody reads them. A broken integration at your largest account stands next to a question about changing a password. The order is decided by the minute the message arrived, not by the weight of the case, because at that point nobody knows yet what is inside. A person does the sorting, usually between other tasks. The same kind of ticket goes to engineering one day and to customer service the next, because the rule lives in the head of whoever is on shift and changes with the shift. A ticket passed on three times comes back to the customer with a question they have already answered once. The contract clock starts when the ticket arrives, not when somebody reads it. An outage reported at 17:10 sits until the morning, so nothing is left of an eight hour response window. The report does not show it, because the report measures time from assignment, that is from the moment the problem was already countable. - An outage waits behind an invoice question, because both arrived in the same minute - The same type of ticket reaches two different teams, depending on who is on shift - A complaint sits in the ordinary queue and nobody watches its deadline - Sorting the queue eats the hours of the person who is meant to be solving cases, not distributing them Why now ## What changed, so that classification runs on your tickets in weeks? Every ticketing system now hands over a new ticket through a webhook and takes a label back through an API: Zendesk, Freshdesk, Intercom, HubSpot Service Hub, Jira Service Management. Nothing has to be replaced and no history has to be migrated. The [HubSpot developer documentation](https://developers.hubspot.com/) is public, like the equivalent docs for the others, so the classifier plugs in beside your helpdesk and writes fields onto the ticket that is already there. On top of that sits a layer that was not available at a sensible price three years ago. A language model reads a ticket in English and in Polish, pulls out the type of case, the tone, and whether the customer is describing an outage or an inconvenience. Plenty of tickets are settled by a single keyword, so the first layer is a cheaper rule based classifier in [n8n](https://docs.n8n.io/) or Make, and the model only sees what the rule did not resolve. The third change is the AI agent. A label will sort the queue, but it will not answer a manager asking how many critical tickets have been open longer than 4 hours today. BOND, our company AI agent, answers that in a plain sentence in 5 to 10 seconds, with no helpdesk login and no report to build. What changes ## What does the support team get? - ### A queue sorted before the first coffee Tickets from overnight have a priority, a type and a team before anyone opens the helpdesk. The person on shift starts with the work instead of reading twenty emails to find out what is urgent. The label is written into Zendesk, Freshdesk or Jira Service Management within 5 to 10 seconds of arrival - ### An outage does not queue behind a password question Priority is derived from the wording, the number of affected users and the support tier in the contract. A ticket marked critical calls the person on duty in Slack or Teams straight away instead of waiting for the next queue review. Four priority signals instead of one field picked by whoever raised the ticket - ### One classification for the whole team The taxonomy is written down and the same for everyone, so similar tickets end up in the same place whoever is on shift. Statistics by type start to mean something, because they stop depending on who described the ticket. Labels come from one set of rules, not from several people with their own habits - ### A complaint with a clock of its own A ticket demanding a refund or a repair goes into a separate queue with a response deadline and an entry in the register. A case with a legal deadline stops sitting next to a configuration question. A separate queue, a separate deadline and an escalation before it runs out - ### The premium customer visible from the first second The classifier adds CRM data to the ticket: plan, contract value, how long they have been a customer, other open tickets from the same account. The premium queue is visible immediately, not after somebody checks who is writing. Data from HubSpot, Pipedrive, Salesforce or LiveSpace written onto the ticket automatically - ### Questions about the queue in a plain sentence How many critical tickets have been open longer than 4 hours. Which types are growing this month. How many tickets came in after hours. The AI agent answers from helpdesk data, in English or in Polish. An answer in 5 to 10 seconds, with no report and no login to the ticketing system And in your company ## What if our support works differently? Four sentences we hear most often, and we answer all four the same way we would in the consultation. - We get 40 tickets a month and two people handle it. Then classification solves a problem you do not have yet, and we will tell you so. At that volume it makes more sense to set up three views in the helpdesk and finish the knowledge base. We come back to the subject when sorting starts taking someone an hour a day, or when a night shift appears. - The model will get it wrong and an outage will end up with a low priority. That is why the classifier has a confidence threshold, and below it the ticket goes into a manual queue with a note on what it could not resolve. It never lowers a priority a person has set, it can only raise it. The first week runs in suggestion mode: it proposes a label next to the ticket and the team still decides. - Zendesk has its own triage tools, why add anything? If the native rules are enough, we will say so and show you how to set them up. An outside layer earns its place when priority depends on data from beyond the helpdesk: the support tier in a contract held in the CRM, the state of an order in the ERP, the value of the account in the warehouse. The helpdesk does not know those fields. - Our customers' data sits in the body of the tickets. In the workshop we agree which fields leave the helpdesk for classification at all, and usually that is the subject, the body and a customer identifier without contact details. We write down the processing region and the retention period, in line with GDPR 2016/679. We do not use your tickets to train any model. Ticketing systems Zendesk, Freshdesk, Intercom, HubSpot Service Hub, Jira Service Management Inbound channels Shared inbox, website form, chat, transcript of a phone call Customer data HubSpot, Pipedrive, Salesforce, LiveSpace, BaseLinker, Shopify, WooCommerce, PrestaShop Team collaboration Slack, Microsoft Teams, Google Workspace, Microsoft 365, ClickUp, Asana, Notion Data and measurement BigQuery, Google Sheets, GA4, SQL databases Automation layer n8n, Make, Zapier, custom API integrations ## What the classifier puts on a ticket and where the signal comes from The labels that usually go into a first rollout. The set is agreed in the workshop, because a support taxonomy looks different in a product company and in a services company, and a label with no consequence in the system is only decoration. | Label | Where the signal comes from | What it triggers in the system | | --------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Critical priority | wording about an outage, number of affected users, support tier in the contract | alert for the person on duty in Slack and escalation before the contract deadline | | Type: outage | description of the symptom, whether it repeats, product version and module | engineering queue, linked to an issue in Jira Service Management | | Type: complaint | demand for a refund or repair, order number, reference to the warranty | separate queue with a response deadline and an entry in the complaints register | | Type: question | asks about configuration, no order number, no fault described | a suggested answer from the knowledge base offered to the agent handling it | | Type: feature request | conditional phrasing, describes a missing capability, no fault reported | product backlog and a note to the customer that this is not an outage | | Customer segment | plan from the CRM, contract value, length of the relationship, open tickets | premium queue ahead of the standard one, a different escalation threshold | | Ticket language | the body of the message and the sender domain | assignment to someone who works in that language, templates in that language | These rows are a starting point. For most companies a first rollout covers priority, type and segment, and the rest goes in once the data from the first 30 days shows it is needed. How we work ## Five steps from one queue to a label with consequences Every step ends with something you can judge before you decide on the next one. 1. ### Workshop We take a sample of your tickets from the past month and take today's support apart: who sorts, on what basis, how long it runs from arrival to assignment, where a ticket circles between teams. We check which deadlines come from contracts and which from regulation. 2. ### Taxonomy and confidence threshold We write down the list of labels together with what each one triggers in the system. We agree which cases a rule settles, which go to the language model, and below what confidence a ticket goes into the manual queue. Then we pick the tool: n8n, Make or an API integration with your helpdesk. 3. ### Suggestion mode alongside the current queue The classifier runs in parallel and only proposes a label, without moving any tickets. We compare its decisions with the team's decisions on real traffic, including after hours tickets, bilingual ones and the ones that fit two types at once. 4. ### Switch-over and routing Once it checks out the label starts to act: queues, escalations, alerts for the person on duty, a separate track for complaints. The support manager learns to change the taxonomy without us, because a new type of ticket appears with every new product. 5. ### Measurement after 30 and 90 days We look at label accuracy, the number of tickets handed between teams and the time from arrival to first reply. We retune the thresholds against what actually arrives, not against what we assumed in the workshop. Before and after ## How the day of the person on shift changes ### Before - The morning starts with reading twenty emails to work out what is urgent - A ticket is handed to another team, because only now is it clear what it is about - Last night's outage is found at 9:00, once the contract deadline has already passed - A board question about ticket types is answered with a spreadsheet built by hand ### After - The queue opens with the priority, the type and the team already set overnight - The ticket sits straight away in the queue of the team that will solve it - A critical ticket is known from an alert, in the same minute it arrived - Statistics by type are read off the labels, because the labels are consistent from day one The first labels are visible on switch-over day. Accuracy and confidence thresholds we judge after 30 days, the effect on first reply time after 90 days. For the person signing this off ## What a head of customer service gets out of it The question of why nobody noticed stops coming back to you, because the order is decided by a rule you approved yourself and not by the accident of arrival time. A ticket past its deadline shows up through an escalation the same day, not at the weekly review. The second thing matters more in front of the board. You know how many tickets of each type arrive, how many are outages and how many are questions the knowledge base already answers. That is an argument in the conversation about a new hire in support, or about a fix in the product, and today you do not have it because everyone labels tickets their own way. - A taxonomy written down and versioned, independent of who is on shift - Escalation before the contract deadline, not after it - A week of work in suggestion mode, so the current queue holds until the tests are done - You add a new ticket type yourself, with no ticket raised with us What it costs ## The workshop has a published price, the rollout is quoted after it The process workshop costs **EUR 3,500 net per week**, and runs from one to seven weeks. Ticket categorization usually needs one week, two when tickets arrive through several channels and deadlines from several contracts have to be reconciled. We quote the rollout after the workshop, because only then is it clear how many labels are in scope and what state the helpdesk is in. You pay the language model usage and the helpdesk subscription directly to the provider, with no margin from us. A single classification query costs the provider roughly EUR 0.005 to 0.07\. If the classifier sits on your own infrastructure, the automation layer costs nothing beyond what you already pay. - ### Process workshop EUR 3,500 net per week, and ticket categorization is usually one to two weeks A self-contained piece of work. It ends with the taxonomy written down and a rollout plan you could execute without us. - Analysis of a sample of your tickets from the past month - A list of labels together with what each one triggers in the system - A tool recommendation: native helpdesk rules, n8n, Make or the API - The metrics to measure after 30 and 90 days Start with the workshop - Most popular ### Workshop and classification rollout Quoted after the workshop scope follows from the number of channels and labels The option most companies choose. Working classification 2 to 6 weeks after the workshop, tested on your own traffic in suggestion mode. - Everything in the workshop - A classifier in n8n, Make or over the API, wired into the helpdesk and the CRM - Priority, type, customer segment and a manual queue below the confidence threshold - Routing, escalation before the contract deadline, a separate track for complaints - Training for the support manager on changing the taxonomy Talk about a rollout - ### Classification and an AI agent for support Quoted after the workshop for teams that ask about the state of the queue several times a day Everything in the rollout plus BOND, the company AI agent that answers questions about the queue in a plain sentence. - Everything in the classification rollout - An AI agent wired into the helpdesk and the CRM: what is open, for how long, of what type - Alerts on after hours tickets and on an approaching deadline - Access for the support team and the manager, in English and in Polish Ask about the agent If the workshop shows that three rules in Zendesk are enough at your volume, we say so and show you how to set them up. The matter ends with the workshop, and the document from it stands on its own: the taxonomy and the plan stay with you, including when somebody else does the rollout. ## Frequently asked questions What is automatic ticket categorization? It is a layer that receives a new ticket from the helpdesk through a webhook, reads its content and the customer history, and then writes a priority, a case type and a team or a person onto the ticket. The label is not the point in itself: each one triggers something in the system, for example the premium queue, an alert for the person on duty or a separate track for complaints. A person decides wherever the classifier is not confident. How long does a ticket categorization rollout take? The first working rule usually 14 days after the workshop, the full rollout 2 to 6 weeks. The difference comes from the number of inbound channels and from whether priority has to depend on data outside the helpdesk, for example the support tier in a contract recorded in the CRM. A week of that window goes on suggestion mode, to compare the classifier's decisions with the team's. What happens when the classifier judges a ticket wrongly? Below the agreed confidence threshold the ticket goes into a manual queue with a note on what the classifier could not resolve, so it does not guess for the sake of guessing. It never lowers a priority set by a person, it can only raise it. Every correction the team makes is recorded, and after 30 days it feeds the retuning of thresholds and the sharpening of the taxonomy. Will this work on tickets written in English and in Polish? Yes, the language model reads both and recognises which one a ticket is written in, so language is often one of the labels and drives the assignment. The rule based layer gets a separate keyword list per language, because an outage is described as is down in one and as nie dziala in the other. We run Zendesk with our own rules, why add an outside layer? With one criterion the native rules are enough and we will tell you so in the consultation. An outside classifier earns its place when priority depends on data the helpdesk does not hold: the support tier in a contract, the value of the account in the CRM, the state of an order in the ERP. That is when helpdesk rules grow into dozens of entries maintained by hand. From how many tickets a month is this worth doing? There is no agreed cut-off, but the signal is simple: when sorting the queue takes someone an hour a day, or when a ticket circles between teams twice, classification pays back quickly. At 40 tickets a month it usually is not worth it and we say so plainly, rather than selling a rollout with nothing to fix. Does the classifier reply to the customer instead of a person? No, unless you ask for that. By default it sets labels and orders the queue, and a person writes the reply, with the classifier able to offer a ready passage from the knowledge base. An automatic reply is a separate decision and a separate rollout, usually started on one well recognised type of ticket. What happens to customer data held in the body of a ticket? In the workshop we agree which fields leave the helpdesk for classification, and usually that is the subject, the body and a customer identifier without contact details. We write down the processing region, the retention period and who has access to the logs. We do not use your tickets to train any model. ## Let us find out what your queue rests on today The free consultation takes 30 minutes. You tell us how many tickets arrive each month, who sorts them today and what deadlines you have written into your contracts. We show you which labels can be set automatically straight away and which need the taxonomy in the helpdesk sorted out first. You do not have to share any systems at this stage. We run at most two rollouts at a time, so that someone is genuinely sitting on each of them. [Book a free consultation](https://justautomate.ai/en/contact/) **PS.** If an outage in your company waited behind a password question this week, that is exactly the problem. A queue sorted the moment a ticket arrives gives the support team back the hours that go today on reading and distributing. That is where the workshop starts. ## Related - [Automatic task creation](https://justautomate.ai/en/automations/automatic-task-creation/) - [Automatic Slack notifications](https://justautomate.ai/en/automations/automatic-slack-notifications/) - [Automatic client onboarding](https://justautomate.ai/en/automations/automatic-client-onboarding/) - [n8n automation](https://justautomate.ai/en/services/n8n-automation/) - [BOND, business AI agent](https://justautomate.ai/en/services/bond-business-ai-agent/) - [Process workshop](https://justautomate.ai/en/services/process-workshop/) --- **JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/