One queue, 2 AI agents, and a Sunday evening to begin with
Picture a man who runs a small appointment-booking software, the kind which barbers and physio clinics use for taking their bookings, and picture him on a Sunday evening, seated with the support queue after his dinner. Not because anybody asked him to be there. He goes through the queue on Sundays on account of Monday mornings being cruel otherwise, seventy-odd tickets gathered up over a weekend, and only himself and one part-timer to answer the whole of it. Does that evening sound familiar to you? Plenty of founders shall recognise it straight away, and this page was written with them in mind.
Now, plainly said, an AI customer support agent is a software which reads the tickets arriving in your queue and performs real work upon them by its self. It sorts some of them. It answers some of them. And it holds back whenever it is unsure, waiting for a person, quite similar to a careful new employee who does that much which they know and asks about the rest. That is the entire definition, and you are not required to carry any more theory than this for the rest of the page.
One naming matter must be settled before we proceed, though, because this industry went and used the very same word for two different things. Around a helpdesk, an agent has always meant a person, a member of your own team, and over here at Maxdesk every plan takes unlimited human agents, the $0 plan included, with no per-agent fees anywhere in sight. The AI agents are a separate matter entirely. There are 2 of them, they arrive with the Elite workspace at $99, and each one carries one half of the job our Sunday man was doing by hand. The first goes by the name of the triage agent. The second is called the resolver agent. Well then, let us meet them one at a time.
The triage agent, and where your sorting hour truly goes
It is important to see what the sorting costs before any software earns credit for removing it. Our man never counted sorting as work, funnily enough. Sorting felt like preparing for work. Yet there he sat, reading each ticket far enough to judge the urgency of it, deciding whether the matter belonged with billing or bugs or the how-do-I pile, and then performing the most tiring calculation of the lot, who takes this one, given who is already carrying what. Multiply that little ceremony across every ticket of every day and you shall find a serious slice of the week hiding inside of it, and not one minute of that slice was ever visible to a customer.
The triage agent performs that same ceremony, only at machine speed and without the sighing. The moment a ticket arrives, the agent reads the actual words of it and sets a priority based on the issue it finds there, and hence a failed payment lands on top of the queue with an urgent flag on it while a question about changing logo colours settles somewhere lower down. The same reading files the ticket into its proper category, billing matters to billing, the bug reports over to bugs, so the person who is strongest on a subject keeps meeting the tickets which belong to that subject. And then the assignment. The agent keeps count of the open tickets each team member is holding at that exact moment and passes the new one to whoever holds the fewest, and this action keeps the load level across the whole team without a manager refereeing the queue by hand. On the first morning it ran for him, the part-timer was carrying next to nothing while he himself sat buried, and the fresh tickets travelled to her, one after another, till the scales came level. Nobody negotiated. Nobody was required to.
A fair question arrives at this point, and it deserves its own paragraph. Could the no-code automation rules manage this? Some of it, honestly yes, and our helpdesk automation page walks through that machinery properly. But a rule only catches that much which somebody predicted in advance, a word in a subject line, a particular sender, nothing besides. The triage agent reads the ticket its self, the actual complaint inside the actual sentences, and that is the entire difference between the two of them.
The resolver agent, and the confidence which decides the sending
My reminder emails have stopped reaching my customers, kindly look into this at the earliest. Some version of that message, or the one about moving opening hours for a bank holiday, or the eternal password one, arrived in our man's queue so often that he could type the answers with his eyes shut, and there sat the trouble, he was still the one typing them. Every queue carries its own easy regulars, and they may possibly be the most expensive tickets you own, since no single one of them is hard and the supply of them never once dries up.
The resolver agent was built for precisely these regulars. It checks each ticket as it lands, and whenever it understands the issue, it drafts a complete reply, built from the conversation in front of it and the context sitting behind it, never from some canned script which greets every customer with the same three lines. Then comes the step which separates an agent from an autoresponder, and it is worth reading slowly. The resolver weighs its own confidence in the draft it has made. Once that confidence runs high enough, the reply goes and sends its self, right away, and your customer may hear back within minutes despite nobody from your team being anywhere near the queue. And whenever the confidence falls short of the bar, the draft simply waits inside the ticket for a human hand, to be read, mended wherever mending is wanted, and sent out under a person's own name.
Hold onto that second half, because the whole trustworthiness of the arrangement lives there. A machine which answers one and all of your tickets shall eventually answer one wrongly, in writing, to a paying customer, and you shall then spend a good long while repairing what a single minute broke. The resolver refuses that bargain. What it is sure of, it sends. The unsure remainder travels to your people with the typing already done, and even those held drafts earn their keep, since a draft wanting a light edit is still far quicker than a blank page. Isn't that the very deal you would offer a careful new employee? Do the part you know cold, and bring the rest of it to us.
The first thirty days, told the way they actually went
Nobody trusts a new machine on day one, mind you, and nobody should, so the sensible way is the way our man took, which was to treat the first thirty days as a probation period.
In the early days he mostly watched. The triage agent stamped its priorities and he checked them against the ones his own head would have picked, and the stamps sat right there in the ticket history for the comparing, since every action either agent takes gets written into the record like any team member's work would be. Then the resolver's first sent replies went out, the password ones, the opening-hours ones, and he read each one after the fact, the way you read over a new hire's shoulder in their first week without quite admitting that you are doing it.
The held drafts turned out to be the most useful reading of the lot, funnily enough. Whenever the resolver kept holding back on one topic again and again, it was pointing at a hole, some answer his knowledge base never got around to writing down. He went and wrote the missing article, and the resolver grew steadier on that topic almost at once, on account of the material now existing for it to draft from. That little loop, held draft to missing article to fewer held drafts, is the best habit an Elite team can keep, and it costs a few minutes in a week. By the end of the probation the usage dashboard held the whole story in the open, what was sent, what was held, where the month stood against its 5,000, and the verdict was never a feeling. It was a record.
The money, and the small print we shall say ourselves
Now for the money, and the fine print alongside it, each bit of it said by us rather than discovered by you.
A practice has spread across AI support tools where the bill gets tied to resolutions, meaning a fee is charged every time the bot successfully answers a customer, and our quarrel is with the practice, never with any name in particular. Price the thing that way and your best month becomes your priciest month, which is the same per-seat problem coming back with a different unit on the bill, and somewhere down that road a business finds its self wondering whether its bot ought to answer fewer people. No business should be wondering any such thing. Elite is $99 per workspace per month, flat, with up to 5,000 AI responses inside of it and extra packs available whenever a queue genuinely outgrows the number. A heavy month costs the very same as a quiet one, and the human side never enters this arithmetic at all, unlimited people on every plan we sell, the $0 workspace included. The wider argument about how support tools get priced, and what each model quietly makes a team ration, is set out in help desk pricing models.
The rest of the small print, quickly and plainly. The AI agents live on Elite and nowhere else, so a team wanting them is a team paying $99, no two ways about it. Email is the only channel the agents work, there is no chat widget, no phone line, and no roadmap winking at either, and in case your customers mostly reach you through chat, we are honestly the wrong shop for you, better said here than after a migration. There are 2 agents, one for the triage and one for the resolving, and this is no workshop for building bots of your own. And some tickets shall always wait for a human, by design, since the confidence bar exists exactly so that the hard ones reach people. Alongside the two of them, fair is fair, Elite does carry the smaller AI comforts as well, a copilot suggesting replies beside your people while they write, ticket summaries for the long threads, live translations, sentiment and urgency read on arrival, and each of these shaves minutes rather than making headlines, which is quite honestly all we shall claim for them.