Agentic

The support triage agent: sorting issues before they escalate

How often does someone on your team start an escalation by having to look up something that’s already been recorded somewhere? The account, the latest invoice, the previous two tickets, the language the customer is writing in.

How often does your engineer start an escalation by digging up what your stack already holds? The plan and seat count, the renewal date, the failed Stripe charge, last sprint's Jira issue, the admin's language.

How often does your planner, faced with a shipper's complaint, look up again what already sits in the TMS? The order number, the booked loading slot, the trailer's trip ID, yesterday's CMR, the contract rate for that lane.

How often does a senior developer at your firm first dig up what Jira already holds before touching an incident? The client's SLA tier, the release that went live on Tuesday, the retainer hours still left.

How often does your service desk look up, for a breakdown call, what is already on record? The serial number, the as-built BOM, the last service report, the warranty status of the machine.

The question is not whether you receive too many tickets. The question is what condition a ticket is in when someone picks it up.

Your Intercom queue is not the issue. The question is what state a ticket is in when the engineer or CSM who actually owns it first opens it.

The issue is not how many calls you get about a shipment. It is what the planner knows at the moment he picks up the report.

The number of tickets in your service desk is not the question. The question is what a developer knows the moment he opens one.

The question is not how many breakdown calls come in. The question is what your service engineer knows at the moment he picks one up.

I want to go through twenty of my own tickets in one go

30 mins · senior consultant · no slide deck

The mechanism lies in the transfer

The issue lies in the process, not in the volume. A front-line staff member reads a report, lacks context, asks a follow-up question, and forwards the ticket with exactly the same text as when it was received.

The leak sits in the handover. A German customer reports that the DATEV export keeps failing. Your support agent lacks the tenant and integration version, asks for a screenshot and passes it to engineering with the same two lines it arrived with.

The mechanism sits in the handover from customer service to planning. A shipper emails: where is my load for the DC in Venlo? Customer service lacks the order number, asks for it, then forwards the email to planning unchanged.

The leak sits in the handover. Your service desk receives: the link to the accounting package has failed since yesterday. It asks for a screenshot, waits a day and passes the ticket to development with exactly that one sentence.

The leak sits in the handover. A German customer emails: line down, error E-217. Inside sales asks for the serial number, waits a day, then forwards the email to service with exactly that one line of text.

So the specialist starts from scratch. He reconstructs what the primary care team already almost knew. That reconstruction is not visible on any dashboard, because it counts as treatment time rather than a loss.

So your engineer starts from zero. Which release is this customer on, which feature flags are live, which API key belongs to them? That digging counts as sprint time, not as loss, so it never shows up in your burn multiple.

So the planner starts from zero. He finds the trailer in telematics, rings the driver, checks whether the slot was moved. You never see that search anywhere, because it counts as planning hours, not as cost on the lane.

So your developer starts from zero. He looks up which API version runs, on which environment, and what the last sprint changed. Your timesheets call that support, and nobody reads it as lost billable utilisation.

So the engineer starts from zero. He works out which retrofit was done in 2021 and which PLC version is running. That counts as service hours, often under warranty and so unbillable, never as loss.

The second-order cost is the lead time to the customer. Every follow-up enquiry costs a customer cycle. With multilingual flows – Dutch, English and German all mixed together – and messaging expectations where a customer expects a response within an hour, this really adds up. You’re not losing minutes; you’re losing turns.

The dearer cost is time to resolution for the customer. Every follow-up question costs a turn. Your customers write in Dutch, English and German, through in-app chat and a shared Slack channel, and your enterprise contract promises a reply within four hours. Mid-trial or just before a renewal, that stacks up. You are not losing minutes, you are losing turns.

The second-order cost is response time to the shipper. Every follow-up question costs a round. The German warehouse emails in German, the Polish subcontractor messages in English, and the shipper expects a new ETA in his portal within the hour. Meanwhile the truck waits at the dock, and every round costs a slot.

Your client pays the second cost: lead time. Every follow-up question costs a round. A product owner in Hamburg writes English in the shared Teams channel, his IT manager phones in German, and the contract promises a response within four hours on a P1. The clock does not tick in minutes there. You lose rounds, and each round counts when the contract comes up for renewal.

The second-order cost is downtime at your customer. A maintenance manager in Bavaria writes in German, his purchasing wants a PO number for the wear part, your engineer thinks in English. With his line down, he expects a call back within the hour. Every follow-up question costs him a shift. You are not losing minutes, you are losing shifts.

The pattern persists because it is nobody’s fault. The first line is assessed on the speed of handling the case, so it makes sense to push through. The second line is assessed on the resolution, so it makes sense to get to the bottom of it. Nobody is held accountable for the handover between them.

Work out the cost using your own figures

Work it out using your own figures. Take the number of tickets that go to a second-line team each month. Multiply that by the number of minutes someone spends re-establishing context. Divide that result by 60, as the divisor is the number of minutes in an hour. Then multiply that by your own full-rate hourly rate.

To illustrate, using figures you’ll need to fill in yourself: 180 tickets carried over multiplied by 12 minutes gives 2,160 minutes. Divided by 60, that’s 36 hours per month – purely a calculation. That figure represents the cost of the transfer, not the cost of the tickets.

Our estimate; not a measured standard.

A wide chessboard with pieces halfway through a game, seen at eye level
[ Four questions ]

Four questions for your own ticketing system

  1. What proportion of your forwarded tickets reach the second line without any account history, and can you retrieve this information from your ticketing system, or do you have to estimate it?

    What share of your escalated tickets reach engineering or your CSM without ARR, plan and renewal date, and can you pull that from Zendesk and HubSpot or must you estimate it?

    What share of your forwarded reports reaches planning without an order number, trip ID or CMR status, and can you pull that from your TMS or must you estimate it?

    What share of your escalated tickets reaches development without the SLA tier, the last deployment and the contract hours, and can Jira tell you, or must you estimate?

    What share of the breakdown calls you pass on reaches service without a serial number or machine configuration, and can you pull that from your ERP or must you estimate it?

  2. How many times is the same ticket handled by more than two people in the space of a week, and is this reflected in your processing time per ticket?

  3. How many of your incoming enquiries are actually the same question phrased in a different language – Dutch, English or German?

  4. If you look at the five most recent escalations today, how many of them contained a follow-up question that could have been answered using data from your own systems?

Two parts: a router agent and a specialist path

The agent consists of two parts. A routing agent reads the incoming enquiry, determines the language, classifies the query and selects a path: billing, technical, or churn risk. If it recognises a familiar enquiry with a predefined answer, it answers it itself. If it does not recognise it, the enquiry is routed to the specialist path.

The agent has two parts. A routing agent reads the ticket, detects the language and picks a path: billing, such as a VAT invoice or a declined card, technical, such as SSO or an API rate limit, or churn risk, such as a downgrade request. When an admin asks how to add seats, the agent answers itself. When it does not recognise the question, the ticket takes the specialist path.

The agent has two parts. A router agent reads the incoming report, detects the language, links the order number and chooses a path: status and ETA, damage and POD, or an invoice dispute over the diesel or Maut surcharge. If a shipper asks for a signed POD already in the system, it sends it itself. If it does not recognise the question, the report goes to the planner.

The agent has two parts. A routing agent reads the incoming ticket, detects the language and picks a path: incident under SLA, bug within the warranty period, change request you invoice separately, or risk on a key account. A known question, such as adding a user in the CMS or a DNS record after a migration, it answers itself. Everything else goes down the specialist path.

The agent has two parts. A routing agent reads the request, detects the language, links the serial number to the machine and picks a path: spare parts order, technical fault or warranty claim. If a customer asks the lead time of a standard wear part or a copy of the CE declaration, it answers itself. Everything else goes to the specialist path.

That specialist role carries out the work that is currently being phased out. It retrieves account history, outstanding items and previous tickets, drafts a proposed solution, and prepares it for review. Anything that can’t be resolved is escalated. But it’s escalated with the case file already attached: who the customer is, what happened previously, and what the agent tried. The agent starts off briefed, not from scratch.

Close-up of an old brass key against a dark background

The PRAL loop in its simplest form

This is PRAL in its simplest form. ‘Perceive’ is the notification plus the system context. ‘Reason’ is the classification and the choice of course of action. ‘Act’ is to respond, enrich or escalate. ‘Learn’ is the correction made by your specialist to the concept.

Being honest about the level of autonomy

Let’s be honest about the level of autonomy. This workflow operates at Level 2, AI-augmented: the agent makes a suggestion, and a human validates it. Only the narrow range of known questions with predefined answers reaches Level 3. Capgemini estimated in 2025 that around 15 per cent of processes would run at Level 3 or higher, rising to a quarter by 2028. Anyone who sells you a fully autonomous support agent is selling you ‘agentic washing’.

The polarity of the certainty score, once made explicit: high means certain, low means uncertain. The rule is therefore: only when the certainty is high does the agent respond themselves; if it is medium or low, the query is forwarded to a human.

In addition, there is a strict rule: regardless of the level of certainty, anything relating to a payment, a credit note, a cancellation or a complaint with legal implications must always be handled by a human being.

What to do in week one

What to do in week one. Take a hundred closed tickets from the previous month and ask the agent to classify them without replying to them. Compare their routing with what actually happened at the time. You’ll be able to measure how often they misroute tickets, and how often their case file was complete enough to work with. It’s that second figure that counts.

What you do in week one. Export a hundred closed tickets from last quarter, including the week after your last major release, and let the agent classify them without replying. Set its routing beside what actually happened. You measure how often it misroutes and how often its brief was complete enough for your engineer. The second number counts.

What you do in week one. Take a hundred closed reports from last month's customer service inbox and let the agent route them without replying. Set its choice beside what planning actually did. You measure how often it misroutes, and how often its file, with trip and CMR, was complete enough to start from. The second number counts.

What you do in week one. Export a hundred closed service desk tickets from last month and let the agent route them without answering. Set his choice beside what happened then, and watch separately for change requests you fixed free of charge as bugs. You measure how often he misroutes and how often his file was complete enough to start from. That second number counts.

What you do in week one. Take a hundred closed service requests from last quarter and let the agent sort them without replying. Put its routing next to what your service coordinator actually did. You measure how often it misroutes, and how often its file with serial number, as-built and last visit was complete enough for the engineer. The second number counts.

Governance

What the GDPR specifically requires of you in this regard

This agent handles customer data, and often payment and contract details as well. This represents the highest level of exposure of the four workflows in this pillar. That is why governance is treated as a separate section here, rather than a single sentence.

For a Dutch company with between 10 and 100 employees, this means five specific things. A data processing agreement with the model provider: what data, for what purpose, for how long, and who has access to it. A business subscription rather than a consumer account. Knowing in which region the processing takes place and being able to demonstrate this. A retention policy for each type of data, set out in writing and enforceable. And a documented escalation procedure to a human being, including who signs off on it.

On top of that, an audit trail: for each decision, the decision itself, the data used, the risk score, and whether a human was involved. That’s not just about compliance. It is your only way to reverse an error and inform the customer. In 2026, Deloitte found, amongst 3,235 leaders in 24 countries, that 74 per cent want to deploy agentic AI, whilst 21 per cent have mature governance in place.

This is a point you mustn’t gloss over. The agent records how often a staff member overrides their draft. This is personal data, even if it relates to the agent themselves. Our rule is that this override ratio is team data, owned by the team, intended to help guide the agent and reduce their workload. If you ever use it for individual appraisals, that constitutes a different purpose, and the works council must be consulted in advance. Make sure you tell your team this before you start.

[ By sector ]

The same workflow, three sectors, three different diagnoses

The same workflow, three sectors, three different diagnoses. The unit of measurement changes, the instrument changes, and the time frame against which you measure changes too.

SaaS scale-up

The unit is tickets per active account per month. The metric is the link between ticket labels and your release log. The timeframe is the release cycle.

  1. Extract all tickets from the last two releases and categorise them by function.
  2. Place the labels next to the release notes and highlight which peaks follow a change.
  3. Let the router agent predict the labels only, without providing a response as yet, and measure the misrouting rate by functional area.
  4. Include the common questions that crop up after every release in the predefined set of answers.
  5. Repeat the measurement after the next release and check whether the misrouting changes in line with the update.

Logistics

The unit is enquiries per consignment. The tool is the linking of notifications to the consignment status in the TMS. The timeframe is the delivery window, not the month.

  1. Select a week’s worth of consignments and count how many customer contacts each consignment generated.
  2. Place each contact on the shipment timeline and indicate whether it occurred before, during or after the delivery window.
  3. The agent should only distinguish between status enquiries and exceptions such as damage and missing items.
  4. Check whether, in exceptional cases, the file already contained the consignment note and the most recent scan.

Mechanical Engineering

The unit is the number of reports per machine in the field. The instrument comprises the serial number, maintenance history and warranty status. The clock refers to the number of hours of downtime.

  1. Link each report to a serial number and to the most recent service.
  2. For each report, determine whether it was covered by the warranty or not, and whether this was known at the time of receipt.
  3. Ask the agent to check only the warranty status and service history, without commenting on the complaint.
  4. Measure the reduction in downtime resulting from the service coordinator no longer having to look up those two pieces of information themselves.
  5. Mark all reports with safety implications as ‘always human’, regardless of the level of certainty.
Two people in suits shaking hands, with a field of points of light in the background
Please bring

Choose your own twenty tickets before you buy anything

Read this before you stick anything down

Read this before you upload anything, as this step is not optional. Remove names, email addresses, telephone numbers, customer numbers and invoice numbers from the tickets. Replace them with ‘Customer A’ and ‘Customer B’. Use a business subscription from your LLM provider, not a consumer account. Check that a data processing agreement is in place before you upload even anonymised customer text. Check where the processing takes place. Do not keep the results for longer than your test lasts, and delete them afterwards. This test will take you an hour and will tell you more than three demos.

The assignment 
Je bent triage-analist voor mijn klantenservice. Ik plak hieronder twintig echte,
geanonimiseerde tickets. Doe precies dit, in deze volgorde, en verzin niets bij.

1. Bepaal per ticket: de taal, het pad (facturatie, technisch, opzeggingsrisico,
   overig), en een zekerheidsscore hoog, midden of laag. Polariteit: hoog betekent
   zeker, laag betekent onzeker.
2. Pas deze regel toe: alleen bij zekerheid hoog antwoordt de agent zelf, bij
   midden of laag gaat het naar een mens.
3. Harde stopregel, ongeacht de zekerheid: alles wat een betaling, een creditering,
   een opzegging of een klacht met juridische lading raakt, gaat altijd naar een mens.
4. Noem per ticket welke drie gegevens uit mijn eigen systemen een specialist nodig
   heeft om dit af te maken. Vraag ze niet op, benoem ze alleen.
5. Schrijf voor de drie tickets die volgens jou het duurst zijn in behandeltijd een
   overdrachtsdossier van maximaal acht regels: wat er speelt, wat al geprobeerd is,
   wat de specialist als eerste moet controleren.
6. Sluit af met de vijf vragen die zo vaak terugkomen dat ze een vastgelegd antwoord
   verdienen, en zeg er per vraag bij waarom je dat denkt.

Zeg expliciet welke tickets je niet kon classificeren en waarom.

Next, look at point 5, not point 1. If those files are usable, the workflow is of value. If they aren’t, the problem lies with your data capture process and not with the model, in which case RENEW is your first step.

Where this ends

This agent isn’t right for you if your sales channel is your support channel and every conversation is a customer engagement. In that case, you’ll lose more than you gain. Nor is it suitable if your ticket volume is low and your queries vary each time, as there’s then no pattern to route them by. And it isn’t suitable if you’re buying it to cut staff numbers. Gartner expects that more than 40 per cent of agentic projects will fail by 2027 due to unclear business value. Deflection as a goal is precisely such an unclear value. We do not build it without human intervention for handling exceptions, even if you ask for it.

This agent does not fit if your twenty largest accounts each have their own CSM and every support conversation is an expansion conversation. You would lose more than you gain. Nor does it fit if you have forty customers and every ticket is really product feedback, because there is no pattern to route on. And it does not fit if you buy it to cut support heads so your burn looks better before the next round. Gartner expects over 40 per cent of agentic projects to be scrapped by 2027 over unclear business value. Deflection as a goal is exactly that kind of unclear value. We do not build it without a human on the exceptions, even if you ask.

This agent does not fit if the key account behind your chilled freight rings the owner-director over every deviation. That call belongs to the relationship, and an agent in between costs you more than it returns. Nor does it fit if you get few reports and every shipment is a project, as in abnormal loads, because then there is no pattern to route on. And it does not fit if you buy it to cut a planner. Gartner expects more than 40 per cent of agentic projects to be scrapped by 2027 over unclear business value. Fewer planners as a goal is exactly that kind of unclear value. We do not build it without a human on the exceptions, even if you ask us to.

This agent does not fit if your two or three largest clients handle support straight through your account manager and that is where the next project comes from. You would lose more than you gain. It does not fit if you get thirty tickets a month and each concerns custom work only one developer knows, because there is no pattern to route. And it does not fit if you buy it to cut a seat on the service desk. Gartner expects more than 40 per cent of agentic projects to be scrapped by 2027 over unclear business value. Deflection as a goal is exactly that kind of unclear value. We do not build it without a human on the exceptions, even if you ask us to.

This agent does not belong with you if you have five key accounts you ring yourself the moment something stops. There every service call is a relationship call, and you lose more than you gain. Nor does it fit if you deliver eight special machines a year and every fault is unique, because then there is no pattern to route on. And it does not fit if you buy it to cut an inside-sales post. Gartner expects more than 40 per cent of agentic projects to be scrapped by 2027 over unclear business value. Deflection as a goal is exactly that kind of value. Warranty claims and safety reports always go to a person; we do not build it otherwise, even on request.

Where to read on

Twenty of your own tickets, worked through together.

I’d rather have a look at twenty of your own tickets first than show you a demo: I’d be happy to arrange a meeting where we can go through those twenty together.

Rather than a demo, I would sooner read twenty of your own tickets, say from the month before your last renewal cycle. I am glad to set up a call where we go through those twenty together.

I would rather look at twenty reports from your own customer service inbox than show you a demo: I am happy to book a call in which we go through those twenty together.

I would rather look at twenty tickets from one of your managed services clients than give you a demo. Book a conversation and we will go through those twenty together.

I would rather look at twenty of your own breakdown calls than show you a demo: book a conversation and we will walk through those twenty together, from email to service report.

I want to go through twenty of my own tickets in one go

30 mins · senior consultant · no slide deck