An employee onboarding chatbot is usually evaluated by HR and judged on policy questions. The IT side has a different question load, a different failure mode and a much clearer boundary, because half of what IT gets asked requires an action rather than an answer.
TL;DR
- IT’s new starter questions split cleanly: where and who, which a bot handles, and grant and reset, which it does not.
- The volume is concentrated in week two, after the access problems are solved and before people know the vocabulary.
- A bot cannot help anybody who cannot sign in, which excludes the worst day one problems entirely.
- Pointing it at runbooks written for engineers produces answers a new starter cannot use.
- Measure which questions stop reaching a person, not how many conversations it has.
- The handoff matters more than the answers. Test it before anything else.
The split that decides the value
Go through a month of new starter tickets and sort them into two piles. One pile asks where something is, what it is called, who owns it, or how to request it. The other asks for something to be granted, reset, installed or fixed.
The first pile is answerable from documentation and is usually larger than anybody expects. The second requires an action and is not a chatbot problem, although some tools can open a ticket to start one.
The ratio between those two piles is the whole business case. Run it before evaluating anything, because a team whose volume is mostly resets will not get much from this category regardless of which product they choose.
The week two concentration
Day one problems are access problems and a bot cannot help, because somebody who cannot sign in cannot reach it. That is worth stating plainly, because it is the single most common misunderstanding when this gets scoped.
The real volume arrives in week two. The person is working, they are encountering internal systems for the first time, and they do not yet know what anything is called. They ask where the deployment process is documented, who approves a licence, what the internal name for a shared drive is, and whether a tool they have heard mentioned is something they should have.
These are high volume, low value and entirely documented. They are also the questions people feel worst about asking, which is why they often go to a colleague rather than to a queue, making them invisible in your ticket data.
Runbooks are written for the wrong reader
The obvious move is to point the tool at your existing IT documentation. This often disappoints, and the reason is audience rather than quality.
Runbooks and operational docs are written by engineers for engineers who already have context. They use internal names without expanding them, assume access the reader may not have, and skip steps that are obvious to anybody who has done the task before. An answer drawn from them is accurate and unusable to somebody in their second week.
What to do:
- Connect starter facing documents first, not the operational library.
- Write a short glossary of internal names and connect that.
- Check that each connected document states who it is for.
- Exclude anything assuming access a new starter will not have.
- Add documents only when a real question demands one.
The glossary is the cheapest high value item on that list and almost nobody has one. Internal naming is the single largest source of week two confusion.
A deployment judged on the wrong number
A sixty person IT function deployed an answering tool for new starters and reported strong usage: several hundred conversations in the first month.
Ticket volume had not moved. Looking at the conversations showed why. Most were people asking things they would never have raised a ticket for, which is a genuine benefit but not the one claimed. Meanwhile the questions that did become tickets were overwhelmingly resets and grants, which the tool was never going to absorb.
The honest conclusion was that it had removed a hidden load rather than a measured one. That was worth keeping, and it required changing the reported measure from conversations to which question types stopped reaching a person.
What to test before buying
The behaviour that matters is not the answer, it is the refusal. Write five questions that are plausible for your company and definitely not in your documents. The correct response is that it does not know, offered with a route to a person. Any confident answer in that set is a failure, and a plausible sounding one is worse than an obviously wrong one because you will not catch it in production.
Then test the handoff itself. Does the person receiving it get the conversation, or does the starter have to repeat themselves. Does it reach somebody who is actually monitoring that destination. A handoff into an unwatched inbox is worse than no handoff, because it looks like help.
Matram is our own product, stated plainly. It reads the documents you give it, answers from them, and declines outside them, which is the behaviour described above. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only, so it can open a ticket in a connected service desk but will not grant access, reset a password or install anything. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. The second pile of tickets stays with your service desk.
What it covers on the IT side
| Question | Answerable | Why |
|---|---|---|
| Where is the deployment process documented | Yes | Retrieval from a known document |
| Who approves a licence for this tool | Yes | Documented ownership |
| What is this internal system called | Yes, with a glossary | Naming, not policy |
| Should my role have this tool | Yes, if role templates are published | Reads the template |
| Please reset my password | No | Requires an action and identity proof |
| I cannot sign in at all | No | They cannot reach it |
The checklist worth keeping
Checklist:
- A month of starter tickets sorted into answer and action piles.
- Starter facing documents connected, operational runbooks excluded.
- A glossary of internal names written and connected.
- Five questions tested that are definitely not in your documents.
- The handoff tested end to end, to a destination somebody watches.
- Success measured as which question types stop reaching a person.
Final Thoughts
On the IT side this category has a sharper boundary than it does for HR. Questions about where, what and who are answerable from documents you already have. Requests to grant, reset or install are not, and no amount of configuration changes that.
Sort your tickets into those two piles first. The ratio tells you whether this is worth doing, and it takes an afternoon to find out.
Frequently asked questions
What does an employee onboarding chatbot do for IT?
It answers the questions new starters ask about where things are, what they are called, who owns them and how to request them, drawn from documentation you already have. It does not grant access, reset credentials or install software, although some can open a ticket in a connected service desk to start that work.
Will it help on day one?
Generally not, because day one problems are access problems and somebody who cannot sign in usually cannot reach the tool either. The volume it addresses concentrates in the second week, once a person is working and encountering internal systems and naming for the first time. Plan for it as a week two onward tool.
Can we point it at our existing runbooks?
You can, and it often disappoints. Operational documentation is written by engineers for engineers with context, using internal names without expansion and assuming access a new starter does not have. The answers come out accurate and unusable. Connect starter facing documents first and add a short glossary of internal names.
How should we measure it?
By which question types stop reaching a person, compared against a sample taken before launch. Conversation counts are misleading because many conversations replace questions nobody would have raised a ticket for, which is a real benefit but not the one usually claimed in a business case.
What is the most important thing to test?
The refusal. Ask five questions that are plausible for your company and definitely absent from your documents, and check that it says it does not know and offers a person. A confident answer there is a failure, and a plausible sounding one is the most dangerous outcome because nobody will notice it once it is live.
Does it reduce ticket volume?
It reduces the share of tickets that were questions rather than requests, which varies enormously between teams. If most of your new starter volume is password resets and access grants, expect little movement in the ticket count and look instead at the hidden load of questions that currently go to colleagues and never appear in your data at all.
