<p id="tldr"></p>
TL;DR
- Switching HR chatbot vendors is easier than most software migrations and harder than vendors imply, because the thing that transfers is the least valuable part.
- Your documents move cleanly. They were always yours and they are usually the smallest part of the work.
- What you rebuild: refusal behaviour, tone configuration, the audience scoping, every integration, and the accumulated corrections somebody made over a year.
- The asset most often lost is the conversation log, which is the record of what your employees actually ask. Export it before you give notice, not after.
- Expect two to four weeks of overlap and budget for running both at once. A hard cutover produces a visible gap in a service employees have come to rely on.
- The best time to prepare for a switch is before you sign the first contract, by asking what comes out and in what format.
The Year of Tuning That Did Not Come With Them
The migration was supposed to take a weekend. The documents were the same twenty-two files, the new vendor imported them in about ten minutes, and the answers in testing were good. On that evidence the team gave notice on the old contract and cut over on a Friday.
The complaints started on the following Wednesday and they were not about accuracy. They were about tone, about the assistant answering questions it used to decline, and about managers suddenly seeing guidance that had previously been scoped away from them. None of that was in the documents. All of it had been configured, slowly, over fourteen months, by a person who had since changed roles and who had never written any of it down because each individual change had taken four minutes.
Best tools for AI HR Tools
What they had actually migrated was the corpus. What they had lost was a year of accumulated judgement about how the thing should behave, which existed nowhere except in the old vendor's configuration screens. Reconstructing it took six weeks and was never quite complete, because nobody could remember which questions had prompted which refusal rules.
The real issue in switching HR chatbot vendors is not whether your content moves. It is everything that is not content.
What Actually Transfers
Short list, and it is worth being clear-eyed about how short.
Your documents. They were always yours, they exist in your own storage, and any product worth evaluating will ingest them. This is the part vendors demonstrate and it genuinely is easy.
Your document structure, if you did the work. If you restructured your policies for retrieval, that investment carries across products, because good structure is good for any retrieval system. This is the strongest argument for doing that work properly: it is the only part of the setup that is portable.
Your own notes, if you kept any. Which brings us to the point of this article.
That is the list. Everything below is rebuilt.
What You Rebuild
Refusal rules. Every decision about what the assistant should decline to answer. Accumulated one incident at a time, usually undocumented, and the configuration that most affects whether employees trust it.
Tone and register. The warmth setting, the length of answers, the handling of sensitive topics. We have written about the register a bot should use, and the relevant point here is that the configuration is per-product and does not export.
Audience scoping. Which groups see which documents. If you built a separate manager corpus, you are building it again, and the mapping between your identity groups and the product's scoping model will not be the same shape.
Integrations. Identity provider, chat tool, any HRIS connection. Each one is a fresh piece of work and each one needs its own security review, which is often the longest pole.
Custom answers. Most products let you override an answer for a specific question. Teams accumulate dozens of these and they are the single most useful thing in the configuration, because each one represents a question the documents answer badly. They do not export in any standard format.
Whatever the prompt said. If you tuned a system instruction, that text is yours in principle and useless in practice, because it was written against a different product's behaviour.
The Asset You Will Lose If You Are Not Careful
The conversation log. This is the most valuable thing the deployment produced and the thing most likely to disappear at cutover.
A year of real questions, in your employees' own words, with the answers given and whatever signal exists about whether those answers were any good, is an irreplaceable record of what your organisation does not understand about its own policies. It tells you where your documentation is thin, which topics recur, what vocabulary people use, and which answers were wrong. It is the input to every content improvement you will make for the next two years.
It is also, in most products, not a first-class export. You can usually see it in a dashboard. Getting it out as data is a different question, and the answer ranges from a clean CSV through an API you have to script against to a support ticket and a wait.
So: export it before you give notice. Not after, and not during the migration when everybody is busy. The moment you start seriously evaluating a replacement is the moment to pull the full history, because your standing with the incumbent is strongest before you have told them you are leaving and your access ends when the contract does.
Ask the incoming vendor whether they can import it, too. Most cannot use it directly to improve answers, but several can accept it as a test set, which turns your own history into an evaluation suite for the new product. That is the single best use of the data and almost nobody asks.
When You Shouldn't Switch
The problem is your documents. If answers are wrong because the source text is wrong or contradictory, a new vendor will produce the same wrong answers from the same text. This is the most common reason for a switch that does not help. Diagnose before you move.
You never configured the current one. If nobody tuned refusals, scoped audiences or added custom answers, then the thing you are unhappy with is an out-of-the-box deployment, and a different out-of-the-box deployment is a coin flip rather than a fix. Try configuring what you have first.
Nobody owns it. A switch requires an owner for four to six weeks. Without one you will arrive at a new product configured as badly as the old one, having spent the money and the goodwill.
Mid-contract with a long remaining term. Run the sum including the unused term. Sometimes it still makes sense and often it does not, and the answer is arithmetic rather than judgement.
Switching HR Chatbot Vendors Without a Gap in Service
Six steps, in this order, and the order matters.
Export everything first. Conversation log, custom answers, any configuration you can get as text or screenshots. Do this while the incumbent relationship is still normal.
Write down the current behaviour. Not the configuration, the behaviour. What does it decline. How long are its answers. Who sees the manager material. This document is what you will configure the new product against, and producing it is the step everybody skips.
Build the test set. Thirty to fifty real questions from the exported log, with correct answers written by somebody who knows the policies. This is how you tell whether the new product is actually equivalent rather than merely functional.
Run both in parallel for two to four weeks. Point a small group at the new one, usually the people team plus a friendly department. Compare against the test set and against the behaviour document.
Cut over by audience, not by date. Move one group, wait a week, move the rest. A staged move turns a potential incident into a contained one, and the first group will find the three configuration gaps your testing missed.
Keep the old one readable for a month. Not answering, just accessible, so you can check what it used to say when somebody disputes a new answer. This is worth negotiating into the exit if the contract allows.
| Step | Timing | Who | Failure if skipped |
|---|---|---|---|
| Export log and config | Before giving notice | Owner | Lose a year of question data |
| Document current behaviour | Week 1 | Owner plus HR | Rebuild from memory, incompletely |
| Build the test set | Week 1 to 2 | Owner | No way to judge equivalence |
| Parallel run | Week 2 to 5 | Pilot group | Configuration gaps reach everybody |
| Staged cutover | Week 5 to 6 | Owner | A single visible incident |
| Keep old readable | Week 6 to 10 | Procurement | No way to settle disputes |
What Switching HR Chatbot Vendors Costs
Mostly time, and the time is concentrated in one person.
Budget four to six weeks of part-time ownership, which in practice is somebody spending a day a week on it plus a heavier fortnight around cutover. The document work is small if you did it properly the first time. The configuration rebuild is the bulk and it is unavoidable. The integration work depends entirely on how many systems you connected and how quickly your security review moves, and the security review is the step most likely to add a month you did not plan for.
Then there is overlap cost, meaning paying two vendors for two to four weeks. On the published figures in this market that is a modest number. Matram is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats. Crisp is $0, $45, $95 and $295 a month per workspace, with additional agents charged on top. A month of double-running at either level is cheap insurance against a visible gap in a service your employees now expect.
| Cost of switching | Typical size | Notes |
|---|---|---|
| Document re-import | Hours | The part vendors demonstrate; not the work |
| Configuration rebuild | Two to three weeks | Refusals, tone, scoping, custom answers |
| Integration and security review | One to four weeks | Usually the longest pole, and the least predictable |
| Overlap subscription | Two to four weeks of both | Small on flat bases; a sunk term on annual ones |
| Lost conversation log | Irrecoverable if skipped | Export before giving notice |
| Adoption recovery | Four to twelve weeks | Only if the cutover goes badly |
The exception is annual-commitment products. SiteGPT is one yearly payment of $468, $948 or $3,108, equivalent to $39, $79 or $259 a month when billed yearly, which means leaving mid-term is a sunk cost rather than a cancellation. Factor the remaining term into the switch decision rather than treating it as spilt milk, because it sometimes changes the timing even when it does not change the destination.
The Three Reasons People Actually Switch
Worth naming, because teams rarely give the same reason for switching HR chatbot vendors that the evidence supports, and only one of the three is well served by moving.
Cost, usually because the billing basis stopped fitting. A per-seat or per-agent product bought when the team was eight becomes expensive at twenty-five, and a per-resolution product becomes expensive precisely because adoption worked. This is the cleanest switch motivation because it is arithmetic, and a move to a flat basis genuinely resolves it. Check the sum at your current and projected headcount before committing, because the saving is sometimes smaller than the migration cost in year one.
Capability, usually refusals or scoping. The product cannot be told to decline a category of question, or cannot show managers something employees should not see. These are architectural rather than configurable, so a switch is the right response. Verify the replacement actually does the specific thing, with your own groups and your own awkward questions, during a trial rather than on a feature list.
Dissatisfaction with answer quality, which is the one to interrogate. This is the most commonly stated reason and the least often the real problem. Poor answers come from poor source documents far more often than from a weak product, and moving a bad corpus to a new vendor reproduces the badness faithfully. Before switching for this reason, take ten questions the assistant answered badly and check whether a careful human reading your documents could have answered them well. If the answer is no, you have an editorial problem and a switch will cost money and change nothing.
There is a fourth motivation that is rarely admitted and worth being honest about: the person who chose the original product has left, and the new owner wants something they understand. That is a real and partly legitimate driver, because an owner who is confident in the tool maintains it better. It is just worth distinguishing from a product failure, and worth weighing against the year of accumulated configuration you are about to discard.
What Employees Notice, and What to Tell Them
Employees do not notice a vendor change. They notice behaviour changes, and the three they notice most are worth managing deliberately.
Answers getting longer or shorter. A different product's default verbosity is immediately obvious to regular users and reads as the system having got worse even when accuracy improved.
It answering something it used to refuse. This generates the most alarming feedback, because an employee who was previously routed to a person for a sensitive question now gets an answer. Rebuild the refusal rules before the cutover, not after the first report.
Different answers to the same question. Inevitable at the margins and worth pre-empting. A one-line note saying the assistant has been upgraded and asking people to report anything that looks wrong converts complaints into useful bug reports.
Tell people something, briefly, and give them a route to report problems. A switch announced as an improvement with a reporting channel generates helpful feedback. A silent switch generates a theory that something is broken.
How to Choose the Replacement
Test against your own log, not their demo. You now have a year of real questions. Use them. This is the single advantage a switching buyer has over a first-time buyer and most switchers waste it.
Ask what exports. You are switching because something did not work. Do not sign the next contract without knowing what comes out, in what format, and whether the conversation log is included. Ask for it in writing.
Match the behaviour, then improve. Configure the new product to behave like the old one first, verify with the test set, and only then make the improvements you switched for. Changing two things at once means you will not know which caused what.
Check the scoping model matches your groups. This is the most common late surprise. Your identity provider's group structure and the product's audience model may not map cleanly, and discovering that in week five is expensive.
Confirm the refusal behaviour is configurable at all. Some products treat declining as a tuning parameter and some treat it as a fixed behaviour. If you need specific refusals and the product cannot be told, that is disqualifying regardless of answer quality.
Six Options Worth Knowing
Matram. Best for teams wanting flat, seat-independent billing after a per-seat product got expensive, which is a common reason for switching. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site. It is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats, and a 30-day trial that takes no card, which is genuinely useful for a parallel run because you can evaluate without a second commitment. Where it struggles, stated plainly: there is no free tier, so no indefinite zero-cost fallback; it answers questions but does not action tickets; and it is not an HR workflow platform, so if you are switching because you wanted workflow, this is not the product that provides it.
SiteGPT. Best for teams who want a predictable annual cost. One yearly payment of $468, $948 or $3,108, which is $39, $79 or $259 a month billed yearly. Where it struggles for a switcher specifically: the annual basis means a trial-then-commit pattern, and leaving again mid-term is a sunk cost.
Crisp. Best where you also want the shared inbox, and a reasonable destination if you are consolidating tools. Flat per workspace at $0, $45, $95 and $295 a month, with additional agents charged separately. Where it struggles: support-shaped defaults that need configuring away for internal use.
Chatbot.com. Best for website-first deployments. $19 per user a month entry, $29.50 Essential, $79 Growth. Where it struggles: per-user pricing is a poor fit for a whole-company internal audience, which is often the thing people are switching away from.
Leena AI. Best for large organisations moving from an adapted support product to an internal-first one. Where it struggles: no published pricing, so the evaluation is an enterprise cycle rather than a trial.
Staying and configuring properly. Best for the large group of teams whose current product was never tuned. Chosen because it costs nothing and resolves a meaningful share of switch motivations. Where it struggles: it requires admitting the problem was the configuration, and it needs the owner you did not have.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Answers wrong because documents are wrong | Any | Any product | Content, not vendor | Fix documents, do not switch |
| Never configured the current product | Any | Out of the box | Untuned behaviour | Configure what you have |
| Per-seat bill grew with headcount | 200 plus | Per-seat product | Cost scales with growth | Flat-basis product |
| Need refusals the product cannot do | Any | Fixed behaviour | Not configurable | Switch, test refusals first |
| Switching because you need workflow | Any | Answering layer | Wrong product shape | A workflow tool, not another assistant |
| Mid-term on an annual commitment | Any | Yearly contract | Sunk cost | Run the sum, consider timing |
| No owner available for six weeks | Any | Any | Will land misconfigured | Delay until there is one |
Running the Parallel Period Properly
Two to four weeks of overlap is the recommendation when switching HR chatbot vendors, and it is easy to waste by treating the period as a soak test rather than as a comparison.
Pick the pilot group deliberately. The people team is obvious and insufficient, because they know the policies and will not ask the naive questions that break things. Add one department with ordinary users, ideally one with a mix of tenure, and ideally one whose manager will actually pass on feedback. Twenty to forty people is plenty.
Give both systems the same questions rather than letting the pilot group drift. The most useful comparison is deliberate: run the test set against both weekly, and separately ask the pilot group to put real questions to both and say which answer they preferred. That second signal catches the things a test set cannot, particularly tone and length, which are the changes employees notice most.
Keep a single list of differences as you find them, with a decision against each: configure the new product to match, accept the difference, or treat it as an improvement. That list is your cutover checklist and it is the artefact that prevents the week-three surprise. Teams that run a parallel period without maintaining this list generally discover the same gaps later and more publicly.
Watch for the specific failure of the pilot group being too expert. If every tester knows the correct answer already, they will judge accuracy well and findability not at all. Include at least a few people who genuinely do not know the policies, because their confusion is the signal you need and it is the signal the people team cannot generate.
And set an end date before you start. Parallel periods drift, because running two systems is comfortable and committing is not. Four weeks is ample for a deployment of this kind, and a parallel period that reaches eight weeks has usually become an avoidance of the decision rather than an evaluation.
If the Switch Goes Badly, How to Go Back
Worth planning, briefly, because a rollback plan is cheap and its absence turns a bad week into a bad quarter. Most teams switching HR chatbot vendors never write one.
The rollback condition should be written down before cutover and should be specific. Something like: if the test set accuracy drops below the old system's score, or if more than a handful of refusal failures are reported in the first week, we revert. A vague intention to revert if things go badly is not a plan, because in the moment there is always an argument for pressing on, and that argument usually wins against a feeling.
Technically, reverting is straightforward if you have not cancelled the old contract, which is the main argument for a staged cutover that completes before the incumbent's notice period expires. This is a scheduling decision rather than a technical one and it is frequently got wrong: teams give notice on day one of the migration, leaving no route back by the time they know whether they need one. Give notice after the cutover is proven, not before, and accept a few weeks of overlap as the cost of optionality.
If you have already cancelled and the new product is not working, the honest options are narrower. Configure harder, which is usually the right answer because most early problems are configuration rather than capability. Or fall back to the shared inbox temporarily and say so plainly, which is unglamorous and better than leaving a misbehaving assistant in front of three hundred people while you work on it.
What not to do is quietly tolerate it. An assistant that is noticeably worse than the one it replaced trains people to stop using it, and that lesson sticks after the configuration is fixed. If the first fortnight is bad, it is better to pull it back to the pilot group, fix it properly, and relaunch than to leave it live and hope adoption survives.
Reconstructing Configuration Nobody Wrote Down
The hardest part of switching HR chatbot vendors is recovering decisions that were never recorded, and there is a method for it that works better than trying to remember.
Do not start from the configuration screens. Start from the questions. Take the exported log and sort it by frequency, then work down the top fifty topics asking one thing of each: what does the current assistant do with this, and is that right. You will recover most of the important behaviour in an afternoon, because the configuration that matters was almost always added in response to a question somebody actually asked.
For refusals specifically, look for the questions where the current system declined. Most products mark these or you can spot them by the shape of the response. Each one is a rule somebody decided on deliberately, and the set of them is your refusal specification. This is far more reliable than reading the configuration, because a rule in a settings screen does not tell you which real question prompted it, and the question is what you need in order to recreate the rule correctly in a different product's model.
For custom answer overrides, the same approach inverted. Find the questions where the answer given does not match anything in your documents. Those are overrides, and each one is evidence that a document answers something badly. Worth noting as content fixes rather than carrying across as overrides, because an override is a patch and the switch is a reasonable moment to fix the underlying text instead.
Interview the previous owner if they are still reachable, with the top-fifty list in hand rather than open-ended questions. "Why does it refuse this one" produces a useful answer. "How was it configured" produces a shrug. If they have left, the log is all you have, which is the argument for exporting it while you still can.
Then write the behaviour document as you go. One line per decision, with the question that prompted it. That document is the thing that makes your next switch a two-week job instead of a six-week one, and it is the only artefact in this whole process that compounds.
Negotiating the Exit While You Still Have Standing
Two things are worth asking the incumbent for before you give notice, and both are easier to get while you are still a renewing customer rather than a departing one.
A full data export, including the conversation history, in a documented format. Frame it as a routine data request rather than as a migration step, because it is one, and most vendors will comply without friction. If your contract has a data portability clause, cite it. If it does not, that is a lesson for the next contract.
And read-only access for a period after the service ends. Thirty days is a reasonable ask. The value is that when an employee disputes a new answer, you can check what the old system said, which turns an argument into a fact. Not every vendor can do this and some will, and it costs nothing to ask.
While you are in the contract, check two things that will shape the timing. Whether notice is calendar-based or anniversary-based, because an anniversary clause can mean waiting months or paying for an extra term. And whether there is any auto-renewal window you are close to, which is the single most common way teams end up paying for a year they did not want. We have written separately about what you keep when a contract ends, and the short version is that the answers are usually in the agreement and almost never read before they matter.
One more point on sequencing, because it is counter-intuitive. Do the export and the behaviour document before you tell the incumbent anything. Not out of bad faith, but because a vendor who knows you are leaving has less reason to prioritise an export request and your own team has less time once the clock is running. Nothing about this requires concealment; it simply requires doing the preparation in the order that works.
What Getting This Wrong Costs
The licence overlap is trivial. The expensive outcome is a service your employees had learned to trust becoming unreliable for a month, because trust in this category is slow to build and quick to lose.
An assistant that was answering well for a year has trained a few hundred people to check it before asking a human. A botched switch reverses that in about two weeks, and the reversal is sticky: people who got a wrong answer during the transition go back to asking colleagues and do not return on their own. You then have a correctly configured new product with the adoption of a fresh launch, which is the worst of both positions because you have paid for the migration and inherited the cold start.
The second cost is the lost log. A year of questions discarded at cutover removes the evidence base for every content decision you would otherwise have made, and there is no way to reconstruct it. Teams notice this about three months later, when somebody asks which topics generate the most questions and the answer is that nobody knows any more.
So the question is not which vendor to switch to. It is whether you have exported the log, written down how the current one behaves, and found somebody to own six weeks of careful work.
When You're Ready to Move
Export the conversation log today, whatever else you decide. It costs an afternoon, it is useful if you stay, and it is irreplaceable if you go.
Then write the behaviour document. One page describing what the current assistant declines, how long its answers run, and who sees what. That page is the specification for the replacement and it is the thing that makes a switch a configuration exercise rather than an act of reconstruction.
And ask the question you did not ask last time, of every vendor you now consider: what comes out, in what format, and does it include the questions my employees asked. The answer tells you how easy your next switch will be, which is the only part of this process you can influence before you need it.
One final reframing, because it changes how much of this work feels worth doing. A switch is the one moment when somebody is obliged to look closely at an assistant that has been running unexamined for a year, and that examination is worth more than the vendor change. You will find refusal rules that no longer make sense, custom answers patching documents that should have been rewritten, audience scoping that predates two reorganisations, and a list of the fifty things your employees actually ask. Most of that is actionable regardless of which product you end up on. Teams who treat a migration purely as a lift-and-shift get a working assistant on a new bill. Teams who treat it as an audit come out with a better-configured assistant, a tidier document set, and a written record of why it behaves as it does, which is the thing that makes the next person's job possible. The second outcome costs perhaps a week more than the first and is worth considerably more than a week.
So if you are going to do this, do the version that leaves something behind.
Frequently Asked Questions
How long does switching HR chatbot vendors take?
Four to six weeks of part-time ownership for a typical deployment, concentrated in one person, with two to four of those weeks running both products in parallel. The document import itself takes minutes and is not the work. The work is rebuilding refusal rules, tone settings, audience scoping, custom answers and integrations, plus whatever your security review takes for the new vendor, which is the step most likely to add unplanned time.
What actually transfers between chatbot vendors?
Your documents, and your document structure if you invested in making it retrieval-friendly. That is more or less the complete list. Refusal rules, tone configuration, audience scoping, custom answer overrides, prompt tuning and integrations are all product-specific and get rebuilt. The practical implication is that the time you spent restructuring your policies was portable and the time you spent configuring the product was not, which is worth knowing when deciding where to invest effort in the first place.
Will we lose the record of what employees asked?
Very possibly, and it is the most valuable thing you have. Most products show the conversation history in a dashboard without treating a full data export as a first-class feature, so getting it out can mean an API script or a support request. Export the complete history before you give notice, while the relationship is still normal and your access is not time-limited, and ask the incoming vendor whether they can accept it as a test set.
Should we run both products at the same time?
Yes, for two to four weeks, with a small pilot group on the new one. A hard cutover means your configuration gaps are discovered by the whole company at once, in a service they had come to rely on, and the resulting loss of trust takes longer to repair than the overlap costs. On the published prices in this category a month of double-running is a small sum, and some products offer a trial that covers the evaluation period entirely.
What will employees notice about the switch?
Not the vendor, but three behaviour changes: answers becoming noticeably longer or shorter, the assistant answering something it previously declined, and different answers to questions people remember asking. The second is the one that generates alarmed feedback, because somebody with a sensitive question who used to be routed to a person now receives an answer. Rebuild the refusal rules before cutover and tell people briefly that an upgrade has happened with a route to report anything that looks wrong.
Is it worth switching if we are mid-contract?
Run the arithmetic including the unused term rather than treating it as already spent, because it sometimes changes the timing even when it does not change the destination. This matters most with annual-payment products, where the whole year is committed up front, so leaving in month four means the remaining eight months are a sunk cost sitting alongside your new subscription. If the motivation is cost, that sum can invert the decision for a year.
How do we know the new product is actually better?
Build a test set of thirty to fifty real questions from your exported log, with correct answers written by somebody who knows the policies, and run it against both products. This is the advantage a switching buyer has that a first-time buyer does not, and most switchers never use it, relying instead on a vendor demo. Score accuracy, but score refusal behaviour separately, because a product that answers slightly less accurately while declining honestly is usually better in practice than one that guesses confidently.
What should we ask the new vendor that we did not ask the old one?
What comes out and in what format, specifically whether the conversation log is exportable as data rather than only viewable. Also whether refusal behaviour is configurable at all, since some products treat declining as a tunable setting and others as fixed, and whether their audience scoping model maps onto your identity provider's group structure. Those three questions cover the gaps that caused most switches we have seen, and asking them now determines how easy your next move will be.
