Algeria AgencyArtificial intelligence
Automation: the queue nobody opens
An automation that works produces cases it cannot handle. They pile up somewhere, and the report goes on showing a comfortable success rate.
No automation handles everything that reaches it. It handles what it recognises and sets the rest aside. That remainder has a name inside the tools that run it — exceptions, failures, pending — and almost never has one inside the company, nor a time, nor a person.
It is the quietest failure AI automation produces: nothing goes down, no alert fires, and the dashboard shows a respectable success rate. Meanwhile a pile grows in a tab nobody opens, and every line in it is a customer, an order or an invoice waiting.
This article is not about choosing what to automate — sorting what can run alone from what must wait for a person is a different subject. It is about what the automation leaves you to do once it runs, and how that remainder is organised so it does not become the problem.
“Handled” does not mean “resolved”
An automation report counts what the program did, not what reached the customer. A line marked handled means the program made a decision: send, file, or set aside. All three count as a success in most tools, because the program did its job in all three cases.
That is where the confusion sits. Setting aside is a success from the program’s point of view and a failure from the point of view of whoever was waiting. A tool showing “96% handled” may well have set aside one file in twenty and be right to call it a success.
So an automation report is read twice: once for what was done, once for what was excluded. If the second number is not in the report, it exists somewhere else — and that somewhere else is the subject of the rest of this article.
That second number is taken once, not daily. Ask the tool how many lines it set aside over the last thirty days, then ask the team how many they believe they handled in the same period. The gap between the two answers is the exact measure of what the queue is hiding from you, and it is usually the figure that starts the conversation.
The queue exists from day one
Nobody decides to create an exception queue. It appears the day the automation starts, because there is always a case the rules do not cover: a name spelled differently, an order at zero dinars, a phone number with one digit too many, an empty attachment.
And because nobody decided it, nobody placed it. It ends up in a folder in a developer’s mailbox, in a tab only the administrator opens, or in a database table nothing displays. Those three places have one thing in common: they belong to somebody with no reason to look at them every morning.
The question to ask before go-live is therefore not “what do we do with exceptions” — the answer is always “we will look at them”. It is: on which screen, at what time, and in whose diary.
Three queues, and only one carries the name
What gets called “the queue” contains three, and confusing them is what makes it impossible to work. The first is technical: the external service did not answer, the file was corrupt, the connection dropped. It clears by retrying, and often clears itself.
The second is data outside the expected shape: the case is legitimate, but it does not fit what the rule expected. It clears by correcting the data, and that is data-entry work rather than IT work.
The third is a decision: the case is legitimate, the data is clean, and somebody has to rule. A refund above the threshold, a customer ordering on credit, a delivery address outside the zone. This one clears only with a person entitled to say yes, and it is the only one of the three that needs a name on the org chart.
Who opens it, and at what time
A queue without a time is not monitored, it is discovered. The difference shows when it is emptied: a monitored queue is emptied daily at the same hour and holds what arrived since yesterday; a discovered one is emptied on a month-end Thursday and holds six weeks.
The hour matters more than the person. A queue checked at nine and at four by anyone adequately trained beats a queue assigned by name to the most capable person in the company, who will look at it when they have time.
The test is simple and needs no tooling: ask three people who handles the exceptions from that automation. If you get three answers, or three hesitations, the queue has no owner — and the same confusion exists for reported faults, where the symptom described is rarely the problem.
The owner also has to survive their own departure. A queue entrusted to one person and nobody else stops the day that person changes role, and the stop is invisible: the queue goes on filling normally. Writing the role beside the name, rather than instead of it, is what makes replacement possible without a meeting.
Friday and Saturday count twice
The working week runs Sunday to Thursday, and Friday and Saturday are the weekend. The automation, meanwhile, runs all seven days. Whatever falls into exception on Thursday evening therefore waits until Sunday morning, and that is not an incident: it is normal operation, two days a week.
This changes how you count. A queue holding forty lines at nine on Sunday did not grow all at once: it accumulated across Thursday evening, Friday and Saturday. The Sunday peak is not an alert, it is arithmetic.
What does deserve an alert is those same forty lines still sitting there on Monday evening. The weekend explains a delay; it does not explain failing to catch up the next day. It is also why an alert threshold set without looking at the local calendar rings every Sunday and ends up switched off.
The exception that comes back every week
A queue holds two very different populations. Rare cases, which arrive once and never return, and recurring ones, which come back every week in the same shape. Both are handled the same way — by hand — and the second is the expensive one.
A case that returns every week is not an exception: it is a missing rule. The supplier who always sends invoices without a reference, the product whose code contains a space, the customer whose address runs to three lines. Each is handled twenty times a year by somebody repeating exactly the same gesture.
Hence the value of counting exceptions by reason rather than by day. Classifying by reason surfaces, within a week, the three or four causes behind half the queue — and those three or four deserve a rule, not a person.
The calculation that convinces is cumulative time. A case returning twice a week and taking six minutes costs a working day a year, for one cause alone, and most queues hold three or four of that kind. Nobody knowingly defends a day a year; it is lost because it is paid six minutes at a time.
What a queue line has to contain
A queue is workable only if each line stands on its own. A line that says “error” forces whoever reads it to reopen the original file, and a queue of thirty such lines means thirty investigations, which guarantees it will not be worked.
Five fields are enough, and they fit on one table row. What happened, to whom, why the machine refused, what the person has to decide, and how long it has been waiting. The last is the forgotten one, and it is the only one that lets you sort.
The convention below is the one we apply; it is not official, deliberately. A queue written in the company’s vocabulary is worked by the business team; a queue written in the program’s vocabulary is worked by IT, which returns it to the developer’s mailbox.
| Field | What it saves | Example |
|---|---|---|
| Subject | Reopening the file to find out what it is | Order 10 482 |
| Person | Hunting for who is waiting | El Feth pharmacy, Blida |
| Reason refused | Guessing what the machine saw | Address outside the delivery zone |
| Decision needed | Wondering what you are meant to do | Accept, refuse, or call back |
| Waiting since | Working it in no particular order | 3 days |
Algeria Agency, convention applied on our automations, 2026
Resuming: who is entitled to decide
The third queue — decisions — stalls on a question that is not technical: who is entitled to say yes. As long as the answer is unwritten, every line escalates to the manager, and the queue moves at the pace of one person.
Writing a threshold settles most of it. Below this amount the team rules alone; above it, they escalate. The threshold does not need to be right first time: it needs to exist, because an approximate threshold applied within the hour beats a perfect judgement delivered three days later.
What must be written beside the threshold, though, is what the person may then do: replay the line, correct it and replay it, or close it without action. A queue where you may decide but not act is not a queue, it is a list of regrets.
The threshold belongs where the decision is taken, not in a procedure document. Stuck on the queue screen, it is applied; filed in a shared folder, it is looked up in the first week and then forgotten. It is the same reason a useful safety instruction hangs above the machine rather than sitting in the office.
The waiting customer does not know they are waiting
From the point of view of the person at the other end, an exception looks like silence. Their order is not refused and not confirmed; their invoice does not arrive; their appointment is neither booked nor cancelled. They have no way of knowing anything is under way.
It is the silence that costs, not the delay. A message saying “we have your order, we will come back to you today” turns an imposed wait into an announced one, and it sends automatically the moment the line enters the queue.
For a business selling online, that message is often the difference between a customer who waits and a customer who orders elsewhere while waiting. It costs nothing to produce: the queue already knows whose line it is, since that is the second of the five fields.
When the queue says the rule is wrong
A queue that grows without stopping is not asking for more staff. It is saying the rule does not match what the company actually does, and no amount of manual handling will correct that.
The sign is a single dominant reason. If two thirds of a month’s exceptions carry the same reason, it is no longer an exception: it is the ordinary case the rule excluded by mistake. The right response is to change the rule, not to reinforce the team catching up.
The opposite sign exists too and reads less easily: a permanently empty queue. It often means the automation is accepting cases it should have set aside, in which case the errors went to the customer instead of piling up in a tab. A queue that is always empty deserves at least a spot check.
Three numbers are enough to watch it
Watching a queue needs no dashboard. It needs three numbers taken once a week, always at the same moment: how many lines came in, how many went out, and how long the oldest has been waiting.
The first two are read together. If arrivals exceed departures two weeks running, the queue will not clear itself, and the question is not “who can make an effort” but “which rule is missing”.
The third is the only one the customer feels. A queue of three hundred lines whose oldest is from yesterday is healthy; a queue of ten lines whose oldest is three weeks old holds ten people who have had time to form an opinion of the company. That is the number to display if only one is displayed.
The three go in a spreadsheet, one row a week, and that suffices for a very long time. The value is not precision but the series: twelve rows are enough to show a trend, and a trend is what makes a decision possible. A measurement tool installed before twelve rows exist mostly measures the enthusiasm of whoever installed it.
What we do, and what we refuse
When we install an automation, the queue is part of the delivery just as the rule is: the screen it appears on, the five fields, the time it is checked and the name of the person who opens it. We also leave the classification by reason in place, because that is what reveals the missing rules after a few weeks.
We do not promise an exception rate. It depends on how clean your data is and how varied your cases are, two things we discover at the same time you do, and a figure announced before looking would be an invented one. Nor do we carry over another client’s: it measures their business, not yours.
And we do not hold the queue on your behalf. Working exceptions every morning is back-office work, it is a different trade from ours, and an outside team deciding in place of yours ends up deciding badly. If nobody at your company can open that screen daily, the subject is not automation: it is organisation, and it is better settled first.
Frequently asked questions
How many exceptions is normal?
There is no normal rate that transfers from one company to another: it depends on how clean your data is and how many special cases your business accepts. The only useful figure is your own, taken over a week. What matters after that is not its level but its direction: a stable queue is sustainable, a queue growing two weeks running is not.
Who works the queue: the business team or IT?
The business team, for everything that is out-of-shape data or a decision — which is the large majority. IT takes only the technical exceptions, which are also the ones most likely to clear themselves on a retry. If your entire queue escalates to IT, it is usually because it is written in the program’s vocabulary rather than the company’s.
Should exception handling itself be automated?
Not the queue itself, or you create a second queue behind the first. A reason that returns every week does deserve a rule, though: it is no longer an exception but an ordinary case the original rule excluded. Classifying by reason exists to catch those three or four.
What happens to exceptions during holidays?
Name a stand-in beforehand, not during. A queue with no owner for two weeks does not produce two weeks of delay, it produces three or four, because resuming means re-reading cases nobody remembers. The stand-in does not need equal expertise: they need to exist and to know the decision threshold.
How do we know the queue is growing?
By comparing the week’s arrivals against its departures, not by looking at its size. A queue of two hundred lines clearing at the rate it fills is healthy; a queue of twenty whose arrivals have exceeded departures for a fortnight is not. The age of the oldest line is the third signal, and the only one your customers feel.
At what point should the automation be switched off?
When the queue costs more time than the manual handling it replaced, and that is not down to an identifiable missing rule. It happens, particularly on low-volume, high-variety processes. Switching off cleanly is a legitimate decision, and it is healthier than keeping a tool the team already works around.
Where we come in
A queue you can count is a queue you can discuss; discovered at month end, it is no longer discussed, only absorbed.
- We open your current exceptions and classify them by reason with your team.
- We write the screen, the five fields and the checking time with the person who will open it.
- We turn the reasons that return every week into rules.
- We leave the classification in place so you can repeat that sort without us.
Until the daily check has a named owner on your side we do not start: a queue held from outside produces decisions taken far from the work.
Read next
Agent, chatbot, automation: three things, one name
Three different products are sold under the same word. They fail differently, and the question that separates them is: who starts it, and who decides?Automating without losing control
Automation makes a process faster, not better. How to sort what can run alone from what has to wait for a person.A live automation: what it costs to keep
The day it works is not the end of the project, it is the start of the bill. What to know before putting the first one into production.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.