ChronexaCUSTOMER SERVICE AUTOMATION · AI SUPPORT AGENTS
Every support bot you can buy answers from your documentation. So the tickets it deflects are the ones you had already answered — and the ones that actually cost you time still land on a person, because the answer lives in your billing system, your job queue or your logs. We build the agents that can read those.
Sits on top of Intercom, Zendesk, WhatsApp or your own app.We are not replacing your helpdesk, and we will tell you when the built-in AI is the better buy.
“How do I change the billing email on our account? The invoices are still going to someone who left.”
What this agent is allowed to read
What the customer gets
Billing email is changed under Settings → Billing → Invoice recipient. It is separate from the account owner, which is why removing the user did not move the invoices. Changes apply from the next invoice; earlier ones keep the old address.
This is the ticket every vendor bot handles well. If most of your queue looks like this, buy the off-the-shelf one — we will tell you so.
01 / THE THING NOBODY MODELS FIRST
Which is fair, and often good value. It is also a cost that grows with the exact thing you are trying to grow, so it is worth doing the arithmetic before you are locked into it.
$0.99per outcome
Intercom publishes Fin at $0.99 per outcome across its plans, where an outcome is a resolution, a procedure handoff or a disqualification. Lead qualification is billed separately and higher.
Good economics when a resolution genuinely saves a person twenty minutes. Less obviously good at high volume on questions that were cheap to answer anyway.
Source: Intercom’s published Fin pricing, as of September 2026.~$1.50per resolution
Zendesk moved to outcome-based billing and, since May 2026, charges only for a verified resolution — the AI answered, a check confirmed it solved the issue, and the customer did not escalate. Escalated conversations are not billed.
Independent 2026 analyses put the effective rate near $1.50 on committed volume and around $2.00 pay-as-you-go, falling at scale, on top of seat licences.
Zendesk publishes the model; the per-resolution figures are third-party estimates, not a list price. Check your own quote.Noper-resolution fee
You pay for the build, then for the model usage and hosting underneath it — which for most support volumes is cents, not dollars, per conversation. Nothing about your cost curve punishes you for growing.
The trade is real and worth stating: you now own a system. It needs maintaining, and it only makes sense past a certain volume or complexity. Below that, buy the vendor one.
We will do this arithmetic with your actual ticket numbers on the first call, including when it says do not build.02 / SORT YOUR OWN QUEUE
Before anyone quotes you a deflection rate, this is the split that decides it. The proportions vary enormously by business — which is why we read your tickets rather than assume.
Vendor AI is measured against the whole queue, but it can only reach the first band. If a third of your tickets ask something no document contains, a third of your tickets are not deflectable at any price, by anyone, until something else can read the answer.
That is the entire argument on this page. Everything we build is aimed at bands two and three — and at being honest about band four rather than papering over it.
The bars below are illustrative shapes, not your numbers. Getting your actual numbers takes us about a week with a ticket export.
03 / WHAT WE ACTUALLY BUILD
A single agent with access to everything is both worse at the job and harder to trust. Splitting by question type means each one has a small remit, a small blast radius and a scope you can read.
Reads the message and decides what kind of question it is before anything tries to answer it. Nothing else runs until this has committed to a category, because an agent guessing at scope is how the wrong system gets touched.
What it can read
Answers the questions your help centre already covers, with the article it used shown underneath. Retrieval is restricted to published, current content so it cannot quote a draft or a superseded version back to a customer.
What it can read
Handles the questions whose answer only exists inside the customer record — invoices, plan changes, seats, renewal dates. It reads live and writes almost nothing; anything that moves money waits for a person.
What it can read
For the tickets that are not answerable from documentation because they describe something specific going wrong right now. It reads the job, the error and the recent history, and reports what it found rather than guessing.
What it can read
Half of support tickets do not contain enough information to answer. Rather than producing a confident guess, this one asks the single most useful follow-up question and holds the ticket open until it gets an answer.
What it can read
Decides when the system should stop. Repeat contacts, cancellation language, anything legal or contractual, anything a confident answer would make worse. It writes the handover summary so the person picking it up is not starting cold.
What it can read
04 / THE PART THAT DECIDES IF YOU KEEP IT
Support automation does not usually get switched off because it was slow. It gets switched off because it confidently told a customer something untrue and somebody had to clean it up. These five rules exist because of that.
Retrieval is citation-controlled: the agent can only assert something it can point at, and the source appears with the reply. If the supporting content is not there, it does not improvise a plausible version.
Confidence thresholds and hard categories send a ticket to a person untouched. We would rather a customer wait twenty minutes for a correct human answer than get an instant wrong one they act on.
The debugging agent cannot see billing. The knowledge agent cannot see the database. Each one gets the minimum it needs for its category, scoped to the tenant it is answering about, and the access is logged.
Most of the value is in reading and explaining. Where an action is genuinely safe and reversible it is automated; refunds, cancellations, credits and anything contractual queue for approval instead.
Every conversation stores which agent handled it, what it retrieved, what it decided and why it escalated. When something goes wrong you get a trace, not a shrug — and that trace is what makes the next version better.
05 / THE ENGAGEMENT
Not a workshop and not a maturity assessment. A sample of what your customers actually wrote, sorted into what can be answered and by what. That read is what the scope and the price are built from.
RELEVANT WORK
The architecture on this page did not start in support. It came out of building retrieval systems for document-heavy work where an unsupported answer was not an inconvenience but a liability — which is where the citation-controlled retrieval, the confidence thresholds and the refusal behaviour were all forced on us.
Support turned out to need the same discipline for the same reason. The interesting part of the work is rarely the model; it is deciding which agent may read what, and what the system does when it is not sure.
How connected AI workspaces are built06 / SEND US YOUR TICKETS
Export a few hundred recent tickets, anonymised. We will sort them into the four bands above and come back with a number you can trust — including the possibility that the answer is to fix your help centre and buy the built-in agent.
You will be talking to the people who would build it, not an account manager.info@chronexa.io
Rather write it down first?
A FEW GOOD QUESTIONS
Often you would not, and that is a real answer rather than a polite one. Both are genuinely good at the part of your queue that a well-written help centre already covers, and if that is most of your volume, the off-the-shelf agent is the cheaper and faster buy. The case for building starts when a large share of your tickets need something only your own systems know — the state of this order, this job, this subscription, this error — or when per-resolution pricing at your volume has stopped looking like a bargain. Send us a few hundred anonymised tickets and we will tell you which situation you are in before quoting anything.
No, and it is worth being precise because the shorthand gets repeated a lot. Both Zendesk and Intercom support custom actions that can call your APIs, and Intercom publishes a developer platform for exactly that. The practical difference is where the orchestration lives and what it costs to maintain: building deep, multi-step, multi-system behaviour inside a vendor framework means modelling your logic in their abstractions, on their release cycle, priced per resolution. Owning the orchestration means the routing, the retrieval, the access scoping and the escalation rules are yours to change. For simple lookups the vendor route is usually the better trade. For anything shaped like real diagnosis, it usually is not.
Lower than the marketing suggests and higher than a sceptic assumes. Independent analyses through 2026 put well-tuned deployments in roughly the twenty to forty-five percent range after several months of iteration, against vendor case studies quoting fifty to eighty. The single biggest determinant is not the model, it is whether the answers exist anywhere the system can reach. If a third of your tickets ask something no document and no system can answer, then a third of your tickets are not automatable at any price, and we would rather tell you that at the start.
Three ways, and none of them is prompt wording. Retrieval is citation-controlled, so an answer has to be traceable to a source or the agent does not make it. Confidence thresholds hand the ticket to a person rather than producing a lower-quality reply. And each agent has a narrow, defined job, which makes it far harder for the system to drift into territory it has no grounding in. Hallucination is largely an architecture problem, not a wording problem.
Exactly what you scope it to, per agent, and no more. The debugging agent cannot read billing; the knowledge agent cannot read the database. Access is read-only by default, restricted to the tenant being asked about, and logged. Where the work touches regulated data — payment details, health information, anything with a specific legal regime — the applicable requirements are part of the design conversation rather than an assumption, and we scope the data flows to match what actually applies to you.
It can act, but the default is deliberately conservative. Safe and reversible things — resending a receipt, retrying a failed job, updating a preference — are automated. Anything that moves money, ends a contract or is hard to undo is queued for a person with the reasoning attached. The point is not to maximise how much the system does on its own; it is to make sure every action it takes is one you would have approved anyway.
It depends on how many categories you want covered and how many systems have to be reached, so there is no list price. The first step is small and concrete: we read a sample of your real tickets, sort them into what is answerable from documentation, what needs live data, and what needs a human, and come back with a scope, an acceptance definition and a fixed price before any build starts.