Skip to content

The support desk.

Triage · Grounded replies · Escalation before the SLA breaks

Support volume is spiky, mostly repetitive, and the exceptions are the only part that genuinely needs a person. The failure mode is not that questions go unanswered, it is that the ones that matter get buried behind the ones that do not, and the SLA is breached on the ticket nobody saw. This module handles the repetitive tier, drafts the rest from your own documentation, and makes sure the ones with consequences reach a human early.

What it takes off the desk

  • Triage that actually routes. Every incoming request classified by what it is, how urgent it is, which customer it belongs to and which team owns it. Not a category label, a routing decision.
  • Replies grounded in your documentation. Drafted from your own policies, product docs and prior resolutions, with the source attached. Anything the system cannot ground is escalated rather than invented.
  • Resolution without a person, where that is genuinely right. Only where the system can see the order, the account or the ticket history. Where it cannot, it hands over with the context already assembled instead of making the customer repeat themselves.
  • SLA risk before the breach. The clock watched per ticket and per contract, escalated early enough to prevent the credit rather than reported after you owe it.
  • Patterns, not just tickets. Twenty tickets about the same defect surfaced as one problem with a cause, which is the difference between a support desk and a queue.
  • Knowledge that maintains itself. Every resolved exception becomes an answer for the next one, so the documentation improves as a by-product of the work rather than as a project nobody has time for.

The realities we build around

The tickets that matter commercially are a small fraction of the volume, and they look identical to the rest on arrival.

An assistant that cannot see the order, the account or the history can only apologise. Access is what separates resolution from deflection.

A breached SLA is money, and it is usually breached on a ticket nobody had eyes on rather than one that was genuinely hard.

Your team already knows the answers. Most of it has never been written down, and asking them to write it down as a separate project has failed everywhere it has been tried.

Where most of these systems go wrong

Most support AI is a chatbot measured on deflection rate, which optimises for the customer giving up. The patterns that fail: bots with no access to the actual systems, so they cannot resolve anything and simply delay the handover; canned answers that state a policy rather than the customer’s actual entitlement, which in Australia is a consumer law problem and not just a service one; triage that assigns a category but not an owner, a priority or a next action; and knowledge bases that are stale within a quarter because maintaining them is nobody’s job. Deflection is the wrong metric. Resolution without a person, on the requests that genuinely do not need one, is the right one.

What it connects to

Whatever you run: your service desk or ticketing platform, your CRM, your order or job system, your documentation and knowledge base, and your communication channels. We do not publish a supported-vendor list: line of business applications, online software, on premise or in the cloud. If it holds the data, we integrate with it, and if it is not named here that is not a limitation.

Where the human stays in the loop

Anything with a commercial consequence goes to a person: refunds, credits, contractual commitments, anything that changes what a customer is owed. Where the system is uncertain it escalates rather than guessing, and it hands over with the context assembled so the person is not starting from nothing. We would rather escalate too often at the start and tighten it than have your customers be the ones who discover the limits.

How an engagement runs

  1. Map the rules. A discovery sprint captures how this actually works in your business today, including the parts nobody has written down. You get a recommended architecture and a fixed-price build quote.
  2. Build against your systems. Against your real data and your real structure, with the human approval steps designed in from the start rather than bolted on.
  3. Validate on real work. We run it against what your team actually receives and tune it until it holds up on the messy cases, not the clean ones.
  4. Hand over and operate. Working, in your environment, with a runbook and full ownership. Extend as a build or a retainer.

What it costs

Most teams start with a discovery sprint from $7,500 to map the rules and produce a fixed-price build quote, or an Automate Your Role engagement from $12,000 for a tightly scoped first version. A full build starts at $40,000 and scales with the complexity of your rules and the number of systems involved.

After the build you choose how to hold it: a monthly subscription covering hosting, monitoring, model costs and ongoing tuning, or a perpetual licence purchased outright, where you own the deployment and support is available separately on a retainer.

Common questions

Is this a chatbot?

Not in the sense you are probably worried about. It resolves requests where it can genuinely see the underlying data, and escalates with full context where it cannot. We do not optimise for deflection, because deflection just means the customer gave up and told someone else about it.

How do you stop it telling a customer the wrong thing?

Every answer is grounded in your own documentation and data with the source attached, and anything it cannot ground goes to a person. On anything touching entitlements it states the actual legal position rather than a store policy, because in Australia misstating a consumer guarantee is itself a breach.

Will it replace our support team?

It replaces the repetitive tier so the team spends its time on the exceptions, which is where they are actually worth paying for. If your plan is headcount reduction we will tell you plainly whether the volume supports it.

Can it work inside the tools our team already uses?

Yes, and it should. The worst outcome is another window your team has to remember to check, so it runs inside your existing service desk rather than beside it.

Start a brief