What an Onboarding Chatbot Answers in a New Joiner’s First Week, and What It Cannot

TL;DR

• An onboarding chatbot is an answering layer over documents you have already written. It is not an onboarding platform and it does not collect paperwork.
• You do not need one if you hire fewer than about twenty people a year and your handbook is one document that one person maintains.
• The questions it handles well are the repetitive, factual, already documented ones. Expenses, holiday policy, payroll dates, who approves what, where a form lives.
• The questions it handles badly are the ones with no written answer, the ones that depend on somebody's specific contract, and anything where being confidently wrong costs real money.
• Three approaches exist: a person on call, a searchable portal, and an answering agent. Most teams need two of the three.
• If your documents are wrong, an answering agent will repeat the wrong thing faster and more confidently than any human would. Fix the documents first.

Somebody starts on a Monday. By Wednesday afternoon they have asked eleven questions, nine of which are answered somewhere in a document they were sent a link to on their first morning. The other two are genuinely new. Nobody can tell which two without reading all eleven.

That is the shape of the problem. It is not that new starters ask too many questions. It is that the answerable ones and the real ones arrive mixed together, through whatever channel is nearest, and a person has to sort them by hand. The HR coordinator who sorts them is good at the job, which is exactly why it is a waste of them.

The real issue is not question volume. It is that the cost of answering a question that was already written down is the same as the cost of answering one that was not.

Recommended Tools

Best tools for AI HR Tools

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

When you do not need an onboarding chatbot

There is a version of this article that tells you every company needs one. That version would be easier to write and less useful to read. Here is the honest staging.

Manual is genuinely fine below about twenty hires a year. If you bring in fifteen people across twelve months, that is roughly one starter every three and a half weeks. One person can absorb that. They will answer the same nine questions fifteen times, which is tedious, but tedium is not a budget line until it displaces something else. Buying software to remove fifteen conversations a year is not a decision anybody needs to defend.

The friction stage starts when answering stops being one person's side job. You will recognise it by a specific symptom: somebody asks in a group channel, two people answer, and the answers differ. That is not a volume problem, it is a consistency problem, and it arrives earlier than most teams expect. Usually somewhere between thirty and sixty hires a year, or sooner if you operate in more than one country.

The liability stage is where it stops being about convenience. When an answer about notice, or leave entitlement, or an expense limit varies depending on who the new starter happened to ask, you now have a record problem rather than a service problem. Different people were told different things and you cannot reconstruct who was told what. An answering layer that logs every question and every answer is worth something here that a helpful colleague is not.

And there is an edge case that argues the other way. If your workforce is largely deskless, works from shared terminals, or has low tolerance for another login, a chatbot will not get used no matter how good it is. The thing that works there is a printed card and a phone number. That is not a failure of the technology, it is a correct read of the audience, and it is worth saying plainly because a lot of vendors will not say it.

There is a fifth case that deserves its own line, because it is the one most often misdiagnosed. If your new starters are not asking questions at all, that is not evidence that your onboarding is clear. It is more often evidence that asking feels expensive, socially or practically, and the questions are going unasked rather than unanswered. Silence in week one is a symptom to investigate, not a score to celebrate, and no tool in this category will fix it. That is a management problem and it needs a manager.

What a new starter actually asks in week one

The useful way to plan this is not by category but by the question somebody types at nine in the evening on their first Sunday, when they cannot ask anybody.

When do I actually get paid, and will the first one be a full month? Pay dates and pro rata first payments are the single most common question across every company I have looked at, and they are also among the easiest to answer wrongly. The answer depends on your cut-off date, which is written down, and on the person's start date, which the bot does not necessarily know. A good answering agent gives the rule and says the rest depends on the individual. A bad one guesses the amount, and the guess is remembered.

How much holiday do I have right now? This matters because the honest answer is almost never a single number. It depends on accrual, on whether your year runs January to December, on carryover rules, and on the contract. An answering layer should give the policy and point at the system that holds the balance. It should not try to be the system of record, and a tool that offers to be should be treated with suspicion rather than enthusiasm.

Can I expense this? Expense questions are the best possible use of an answering layer, because the policy genuinely is written down, it genuinely is the same for everyone at a given grade, and the cost of a wrong answer is small and recoverable. If you only ever deploy one thing, deploy this. It is the clearest win in the category and it is available to almost every team immediately.

Who approves my time off, and what happens if they are away? This is a question about your org chart, not your policy, and it is where a lot of deployments quietly fail. The approval chain lives in your HR system, not in your handbook, so an answering agent reading only documents will give a generic answer that is technically correct and practically useless. Either connect it to the system that knows, or accept that it will route this one to a person and plan for that.

Is it weird if I log off at five? This one has no documented answer and never will. It is a culture question, and it is the single most useful thing a new starter can ask a human. Any tool that tries to answer it is doing harm, because the answer it invents will be plausible and will set an expectation nobody agreed to. The job of an answering layer here is to recognise that it should not answer and pass it to somebody who should.

That last one is the test. A tool that answers all five is worse than a tool that answers four and escalates the fifth, and if a demonstration shows you the first kind, you have learned something important about how the vendor thinks.

The three approaches, honestly

A person on call. Somebody is named, the new starter knows who they are, and questions go to them. This is the oldest approach and it is still the best one for the fifth question above. It is right when your hiring is low, your context is unusual, or the relationship matters more than the response time. It fails when the named person goes on leave, when the volume makes them a bottleneck, and when two named people give two answers to the same question in the same week.

A searchable portal or wiki. You write everything down and put it somewhere findable. This is right when your policies are stable, your documents are genuinely good, and your people are the kind who will read. It fails for a reason that is well documented and still surprising: people do not search, they ask. A portal with excellent content and no traffic is the most common outcome of a six month documentation project, and the failure mode is not the writing. It is that searching requires you to already know roughly what the thing is called.

An answering agent over your documents. The agent reads what you already wrote and answers in the channel people already use. It is right when the content exists but nobody can find it, which is the majority of cases. It fails when the content does not exist, when it is out of date, or when the real need was a workflow rather than an answer.

The honest position is that approach three does not replace approach one. It removes the nine answerable questions so the named person has time for the two that matter. Teams that buy it as a replacement are disappointed, and they are disappointed for a reason they could have predicted before signing anything.

It is also worth naming the combination that does not work, because it is common. Deploying an answering agent while leaving the old portal in place, unmaintained, gives you two sources of truth that will drift apart within a quarter. One of them has to become the source the other reads from. Running both as independent destinations is how a team ends up with an agent confidently quoting a policy that was superseded in the portal four months earlier.

Five questions to ask yourself before buying anything

Can you name the ten questions you get most often? If you cannot, you are not ready, and the fix is free. Read the last two months of your HR channel and count. If the top ten account for most of the volume, an answering layer will work. If the distribution is flat, with fifty different questions asked once each, it will not, because there is no repetition to remove and the economics never arrive.

Is the answer written down and currently correct? Not whether you have a handbook, but whether, if you open it today, the expense limit in it is the one you actually apply. The gap between those two is where most deployments fail. An agent grounded in a document that says one thing while your finance team enforces another will produce confident, consistent, wrong answers at a scale no individual human could manage.

Who owns the content after launch? The most common post launch failure is nobody. The policy changes in March, the document is updated in September, and for six months the agent was wrong in a way that nobody noticed because it was wrong quietly. If you cannot name the person, name the review cadence instead, and put it in a calendar with an owner attached.

Does it need to do anything, or only say things? This is the question that separates the product categories, and it is the one buyers skip. If your actual pain is that people cannot get access to a tool, an answering agent that explains the request process has not helped much. You wanted the request raised. Some agents can now do that through an integration, most cannot, and the gap between those two is not visible from a pricing page.

What happens when it does not know? Ask every vendor this and listen carefully. The right answer involves handing off to a person with the conversation attached, so the new starter does not have to repeat themselves. The wrong answers are that it always finds something, and any demonstration where it never once says it cannot help.

How to run the two week log, concretely

Everybody who writes about this tells you to understand your question volume first, and almost nobody says how. Here is the method, and it costs nothing but attention.

Pick a single two week window with at least one new starter in it. Open a spreadsheet with five columns: the question as asked, the channel it arrived in, who answered it, whether a written answer already existed, and where that written answer lives. Fill one row per question, including the ones asked verbally, which is the part people skip and the part that changes the result most.

The fourth column is the one that decides your purchase. Mark it yes only if you can produce the document and point at the sentence. "It is in the handbook somewhere" is a no. "We told everyone in the all hands" is a no. If your yes rate is above roughly sixty per cent, you have a findability problem and an answering layer will pay for itself in the first cohort. If it is below about thirty per cent, you have a documentation problem, and software bought now will spend most of its time saying it does not know.

The fifth column gives you your data sources. Count the distinct locations. If every yes points at one of three documents, your setup is an afternoon. If the answers are scattered across eleven places including two people's private notes and a pinned message from last March, your setup is a project, and knowing that before you sign is worth more than any discount you could negotiate.

One more thing to record, in the margin rather than a column. Note any question where two people gave different answers during the window. Those are not findability problems or documentation problems. They are decisions nobody has made yet, and no tool resolves them. Somebody has to pick an answer and write it down, and that is the most valuable output the exercise produces.

Reviewing the documents without rewriting them

The review is narrower than people fear. You are not editing for tone or structure. You are checking three things per document, and a good reviewer gets through a handbook in a morning.

First, does each factual statement still match practice? Take every number, date, threshold and named role, and confirm it against whoever actually enforces it. This is where drift lives. Expense limits, probation lengths, notice periods and approval thresholds are the usual suspects, because they get changed in a meeting and updated in a document much later, if at all.

Second, is anything true only for some people, written as though it is true for everyone? This is the most dangerous category, because it reads perfectly and is wrong for a minority. Contract type, location and grade are the usual axes. A sentence that begins with the word all deserves a second look. If a statement has exceptions, either write the exceptions down or mark the statement as one the agent should route to a person.

Third, is there anything you would not want quoted back to you? An agent will quote it, in writing, with your branding on it, to somebody who has worked at your company for four days. Internal shorthand, half joking policy, and anything written in frustration should come out. This takes ten minutes and prevents the most embarrassing possible failure.

What you are not doing is restructuring. The temptation to rewrite the handbook while you are in there is strong and should be resisted until after launch, because a rewrite delays the thing that was going to tell you which parts of the handbook anybody actually needed.

Where the agent lives decides whether it gets used

This is the part that determines adoption, and it is almost never discussed in evaluations, which focus on answer quality. Answer quality is necessary. Placement is what makes it matter.

The rule is simple: the agent has to be where the question is already being asked. Your two week log told you this in column two. If most questions arrive in a chat channel, an agent that lives on a web page has already lost, because using it requires somebody to stop what they are doing, open a tab and change context, at the exact moment when they are least confident about taking up space. A new starter in week one is unusually sensitive to that cost.

If your questions arrive by direct message to one person, you have a different problem and a harder one, because the behaviour you need to change is private. The approach that works is to make that person the one who introduces the agent, in their own words, in the same thread where they would have answered. It is a social move rather than a technical one and it works far better than an announcement.

If your questions arrive in person, be honest about whether a tool is the answer at all. For a deskless workforce the realistic options are a phone line and a printed card, and spending on software there is spending in the wrong place.

There is a second placement question that gets missed entirely. A tool that is available in only one channel today, with other channels described as coming soon, should be evaluated on the channel it has now. Roadmaps are not features, and a channel you need in six weeks is not a channel you have.

The tools, and where each one struggles

Matram is our own product, which is stated here rather than buried, and the same criteria are applied to it as to everything else below. It is an answering agent: you point it at your documents, it answers from them, and it declines to answer outside them. Pricing is flat at $29, $69 and $199 a month with unlimited seats and a 30 day trial that needs no card.

Where it struggles is worth being specific about. It has no free tier, so evaluating it costs something even if only attention. It is not an HRIS and does not hold employee records or run approval chains. And its outward actions reach HubSpot, Zendesk and webhooks only, so it can open a ticket or push a captured lead, but it will not provision an account, approve a request or write back to your HR system. WhatsApp support is coming soon rather than available today. If what you need is the system of record, this is the wrong shape of tool and the trial will tell you that in a week.

BambooHR is a real onboarding platform and the most direct comparison here for most mid sized teams. It publishes Core at $10.25 per employee per month, Pro at $17.50 and Elite at $25, for companies above twenty five employees, with flat rates below that threshold. The relevant detail for this article is that Ask BambooHR is bundled into the Pro tier and answers employee questions from your own policies and handbooks. If you are already paying for Pro, you have an answering layer and should use it before buying another one. Where it struggles is that the answering is tied to the platform, so it is a poor fit when your documents live elsewhere and you have no intention of moving them.

Rippling starts from $8 per employee per month plus a monthly base fee, and the base fee is the part people forget when they model it. Its strength is that onboarding, device provisioning and application access sit in one place, so the question about getting access to the design tool can actually be actioned rather than merely explained. Where it struggles is scope. It is a large commitment for a team whose only real problem is that nobody can find the handbook.

Workday publishes no public rate. Its pricing URL returns a 404, so any per employee figure you read attributed to Workday is a third party estimate rather than a published price, and it should be labelled that way in your business case. It is the right answer at genuine enterprise scale and the wrong answer below it, and the implementation is measured in quarters rather than weeks.

Enboarder is built specifically around the onboarding experience rather than the records, and it is the strongest option when your problem is sequencing and nudges rather than answers. It publishes no price. Where it struggles is that it assumes you already know what you want to say and when you want to say it, which is a planning problem it will not solve for you.

Leena AI and Moveworks both sit in the enterprise agent category and both publish nothing. The Moveworks pricing page carries a Forrester study rather than a rate card, and the figures printed on it are claimed savings rather than prices, which is worth knowing before somebody quotes one into a budget. Both are credible at large scale and both carry a procurement cycle to match.

The decision table

The cost of getting this wrong

The obvious cost is the licence, and it is the smallest one. A hundred person company on a flat plan is spending less on this than on its coffee, and that figure is rarely what anybody argues about in the end.

The real cost is the one nobody budgets, which is content debt. Deploying an answering agent over documents you have not reviewed converts a quiet problem into a loud one. Previously, the wrong expense limit in a document was wrong in a file nobody opened. Now it is wrong in an answer given to every new starter, consistently, with the authority that comes from being the official answer. Several teams have found their own policy drift this way, which is genuinely useful, but it is a better experience when it happens during a review than during somebody's first week.

The second cost is trust, and it is asymmetric in a way that makes it hard to see. A new starter who gets one confidently wrong answer in week one will stop using the tool and will not tell you. Your usage numbers will look like low adoption. The cause will look like a change management problem and will be treated as one. It was an accuracy problem three weeks earlier, and by the time anybody traces it back the cohort has formed a habit of asking a person instead.

So the question worth asking is not how much this costs. It is what is currently written down that you would be uncomfortable saying out loud to every new starter, in writing, at scale, with your name on it.

When you are ready to move past a shared document

Most teams start with a document, and the document is usually fine for longer than people expect. The signal that it has stopped working is not its length. It is that people have stopped opening it and started asking instead, which you can see in your own channels this afternoon without buying anything.

The intermediate step that gets skipped is worth taking. Before you buy, spend two weeks answering questions as normal but logging each one and whether the answer already existed in writing. If most did, you have a findability problem and an answering layer will help immediately. If most did not, you have a documentation problem, and buying software will produce an agent that says it does not know, accurately and often, which is an expensive way to learn something a spreadsheet would have told you.

When the content is in order, the move is small. Point an agent at the documents you already have, give it to one cohort of starters, and compare the questions that still reach a human against the list you logged. The ones that still arrive are your real content gaps, and they are now a short list with evidence attached rather than a vague feeling that the handbook could be better.

What you are actually handing over

Pointing an agent at your handbook means giving a third party a copy of your internal documents, and the evaluation rarely says so out loud. It is worth saying.

For most teams the content involved is genuinely low risk. A holiday policy and an expense limit are not secrets, and plenty of companies publish theirs. The risk sits in what gets swept up alongside them. Handbooks tend to live in folders with offer templates, salary bands, performance frameworks and occasionally an investigation note that was saved in the wrong place. If you connect a folder rather than a set of named documents, you have shared all of it, and nobody intended that.

So connect documents, not drives, at least for the first cohort. It is slower by about twenty minutes and it makes the question of what you shared answerable rather than approximate.

The second question is what happens to the conversations. New starters will type things into this tool that they would not put in an email, because a chat box feels private and is not. Somebody will ask about a medical adjustment, or a pay discrepancy, or a problem with their manager, in week one, to the bot. Decide before launch who can read those transcripts, for how long they are kept, and whether they are visible to the person's own manager. Then tell the new starters the answer, in one sentence, where they will see it.

The third question is the one procurement will ask and the one that most often stalls a rollout: whether anything typed in is used to train a model that other customers benefit from. Get the answer in writing rather than from a sales conversation. The answer varies by vendor and sometimes by plan tier, which means a cheaper tier can carry a different data posture than the one you were shown, and that distinction will not be volunteered.

None of this is a reason not to proceed. It is a reason to spend half a day on it before launch rather than a fortnight on it afterwards, when a starter has already asked the bot something they would rather nobody had read.

Designing the pilot so it tells you something

A pilot that runs until everybody feels good about it tells you nothing. Design it to produce an answer, and decide the answer in advance.

Use one cohort, not one department. Departments differ in ways that confound the result, because the engineering team's questions are not the finance team's questions and a tool that suits one will look worse than it is against the other. A cohort of starters who all began within the same fortnight gives you people at the same point in the same process, which is the comparison you actually want.

Set the window at four to six weeks. Shorter than four and you are measuring novelty. Longer than six and the people who stopped using it in week two have been forgotten by the time you look.

Decide the success condition before launch, and make it about composition rather than volume. The condition that matters is that the questions still reaching a human have changed character. Take the ten most frequent questions from your two week log and check how many of them still arrive. If seven of the ten have gone and what remains is contract specifics, culture questions and genuine edge cases, the tool worked. If the ten most frequent are all still arriving, it did not, and the reason will be either placement or accuracy rather than anything subtler.

Watch one counter signal throughout. Total question volume falling is not automatically good. If the repetitive questions have gone and the judgement questions have also gone, people have stopped asking rather than started self serving, and that is a worse outcome than the one you started with. The way to check is to ask three people in the cohort directly, at the end of week three, whether there is anything they wanted to ask and did not. It takes fifteen minutes and it is the only part of the measurement that catches silent failure.

The multi country case, which changes the answer

Everything above assumes one set of policies. Once you employ people under more than one jurisdiction, the shape of the problem changes, and the change is not about volume.

The difficulty is that the questions look identical and the answers are not. Two new starters ask how much notice they have to give. The words are the same, the correct answers differ, and the difference depends on where they are employed and under what arrangement. An agent reading a single handbook will give one answer to both, confidently, and it will be wrong for at least one of them.

There are two workable responses. The first is to keep one document per jurisdiction and let the agent use the person's location to choose, which requires the agent to know the location, which usually means a connection to the system that holds it. The second, which is less elegant and more often correct, is to decline the whole category. The agent answers the questions that are genuinely universal, which is more of them than you would guess, and anything touching notice, leave entitlement, termination or statutory obligation goes straight to a person with no attempt at an answer.

The second approach looks like a limitation and functions as a feature. A new starter who is told that this one needs a person, within a second, and is handed to the right person with their question attached, has had a better experience than one who received a plausible paragraph that turned out to apply to a different country. The cost of a wrong answer in this category is not a correction. It can be a decision somebody made about their own employment on the strength of it.

Write the refusal list down before you launch, treat it as part of the configuration rather than an afterthought, and review it whenever you open employment in a new country. It is the shortest document in this whole project and it prevents the most expensive failure.

Frequently asked questions