Before replacing a service desk that mostly works, count what it is actually closing. If a large share of tickets were resolved by typing an answer, you do not have a desk problem. You have questions arriving through a ticketing system, and an answering layer handles those without touching the desk.
TL;DR
- An answering layer sits in front of the desk, replies from your own documentation, and creates no ticket.
- It is an addition rather than a replacement, so the ITSM evaluation you were dreading may not be necessary.
- The diagnostic is one number: the share of closed tickets resolved by information rather than by action.
- Above roughly 40 per cent, adding answers beats replacing the desk on both cost and disruption.
- Flat pricing means the addition does not scale with your agent count, unlike the desk underneath it.
- It will not reduce request volume, because explaining how to request something is not provisioning it.
What an answering layer actually is
A system trained on your own documentation that replies to questions in the tool people already use, usually chat, without creating a record that somebody then has to close.
It reads what you give it. Runbooks, onboarding guides, the VPN instructions, the expense policy. Whatever is written down and current.
It answers rather than routing. The difference from a chat integration on your service desk is that a chat integration creates a ticket, and an answering layer does not.
It hands off when it should. Anything requiring an action, a decision or a human belongs in the desk, and a well-configured layer routes those rather than attempting them.
So the two sit in series rather than in competition. Questions stop at the answering layer. Work passes through to the desk.
The one number that decides it
What to do: take a fortnight of closed tickets and sort each into two piles. Resolved by information, meaning somebody typed an answer and closed it. Resolved by action, meaning access was granted, hardware ordered, a configuration changed, something provisioned.
| Share resolved by information | What it means | What to do |
|---|---|---|
| Under 20 per cent | Your desk is doing real work | Fix the desk if it needs fixing |
| 20 to 40 per cent | Mixed, with a documentation gap | Improve the docs first, then reassess |
| Above 40 per cent | Your desk is a question queue | Add an answering layer |
| Above 60 per cent | Most of your desk is avoidable | Add answers before any desk migration |
That count takes an afternoon and it routinely changes a plan. Teams who were three weeks into evaluating ITSM replacements discover the desk is fine and the inbound is the problem.
Why adding beats replacing
No migration. Your request catalogue, approval routing, SLA rules and automation stay exactly where they are. A desk migration is four to eight weeks of rebuilding those; adding a layer in front touches none of them.
No retraining. Your agents keep the tool they know. The change is that fewer trivial tickets reach them, which is a change nobody objects to.
Different billing basis. A desk charges per agent, so it gets more expensive as more people resolve tickets. A flat-priced layer does not move, which means the combined bill grows more slowly than the desk alone would.
Reversible. If it does not work you switch it off and nothing about your desk has changed. A migration is not reversible in any comfortable sense.
What it costs alongside the desk
Every figure below was read from the vendor’s own page on 15 October 2026.
Matram publishes $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats and a 30-day trial that takes no card. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site.
Where it struggles, stated plainly: there is no free tier; it answers questions but does not action tickets, so nothing is provisioned or closed; and it is not an ITSM platform, so there is no asset register and no change management. All of that is the point in this arrangement, since the desk underneath already does those things.
SiteGPT publishes one yearly payment of $468, $948 or $3,108, equivalent to $39, $79 or $259 a month when billed yearly, which is the main alternative shape if an annual commitment suits you better.
Crisp publishes $0, $45, $95 and $295 a month per workspace, with additional agents charged on top, so its free tier allows an evaluation at no cost.
Set against that, a desk migration costs four to eight weeks of a part-time owner plus the overlap subscriptions. The layer is cheaper by a wide margin and considerably less disruptive, which is why the count is worth doing before committing to a migration.
Making the boundary clear to people
The arrangement fails on labelling rather than on technology. If colleagues cannot tell which thing to use, they guess, get it wrong twice, and go back to messaging IT directly.
Checklist for a clean boundary:
- One sentence people can retain: ask for how things work, raise a ticket for anything that needs doing
- The layer offers to raise a ticket when it cannot answer, rather than dead-ending
- Agents can see what the layer answered, so they are not repeating it
- One owner for the combined experience, even if two people own the components
- A fortnightly read of what the layer could not answer, feeding new documentation
That last item is where the compounding value sits. The questions it fails on are a precise list of your documentation gaps, and closing them makes both the layer and the desk better.
Check the published figures yourself before committing: Matram, SiteGPT and Crisp all publish openly, and prices here move within weeks.
Final thoughts
Adding an answering layer is the cheapest intervention available to an IT team whose desk works and whose inbound is mostly questions. It requires no migration, no retraining and no change to the catalogue you spent two years building.
What it will not do is reduce requests, because explaining how to ask for a laptop is not ordering one. Count your closures by type before deciding, and if the pile is mostly actions then the desk is the right place to spend.
What is an answering layer?
A system trained on your own documentation that replies to questions in the tool people already use, without creating a ticket somebody then has to close. The distinction from a chat integration on your service desk is exactly that: an integration creates a record and routes it, while this answers and stops. Anything needing an action or a decision gets handed to the desk.
How do we know if we need one?
Sort a fortnight of closed tickets into resolved by information and resolved by action. If more than about 40 per cent were closed by somebody typing an answer, your desk is functioning as a question queue and a layer in front of it will remove that traffic. Below 20 per cent your desk is doing real work and this is not your intervention.
Why not just replace the service desk?
Because a migration is four to eight weeks of rebuilding your request catalogue, approval routing, SLA rules and automation, none of which transfers between products, and it will not change your question volume. Adding a layer touches none of that configuration, requires no agent retraining, and can be switched off if it does not work. It is reversible in a way a migration is not.
Will it reduce request volume too?
No, and this is the boundary worth setting with people from the start. Explaining how to request a laptop is not ordering one, so anything requiring provisioning, access changes or approvals still needs the desk. If your closures are mostly actions rather than answers, a layer will decline most of what reaches it, correctly, and look like it is not working.
How do people know which one to use?
You tell them in one sentence and repeat it: ask the assistant how things work, raise a ticket for anything that needs doing. The arrangement fails on labelling rather than technology, so the layer should also offer to raise a ticket when it cannot answer, rather than dead-ending somebody who then messages IT directly and learns to skip both systems.
Who should own the combined setup?
One person for the overall experience, even if different people own the desk and the layer, because what breaks is the seam between them rather than either half. The recurring job is roughly a fortnightly read of the questions the layer could not answer, each of which is a precise documentation gap. Closing those improves both systems and is where the compounding value sits.
