Nobody Owns the HR Chatbot, Which Is Why It Decays

TL;DR

• HR owns the content, IT owns the platform, and the answers belong to neither, which is why answer quality is the thing that silently degrades.
• Three jobs need a name against them: keeping documents current, reading the gap log and acting on it, and owning the answers as a service. The third is the one nobody assigns.
• The decay curve is predictable. Launch quality is the peak, it holds for about a quarter, and then every policy change that nobody told the corpus about takes a little more off it.
• Ownership failures look like product failures. A team that concludes the tool stopped working is usually looking at eleven months of unmaintained documents.
• Two hours a month, held by one named person with the authority to change a document, is the whole job at mid-size. The problem is almost never capacity.
• Write the owner's name, the time allocation and the three jobs into the launch plan, because retrofitting ownership after decay means first rebuilding trust.

Eleven Months of Nobody

A 480-person company launched an HR chatbot in February and declared it finished in March. The launch was genuinely good: the top twenty topics restructured, a 30-question test set, an announcement that said what it could and could not do, and an answer quality nobody complained about.

In January of the following year somebody raised it in a leadership meeting as a thing that had not worked. Usage was down by roughly two thirds from the April peak. The HR team had gone back to answering the same questions by email, and the assumption in the room was that employees had simply not taken to it.

What had actually happened, reconstructed afterwards: the leave policy changed in June and nobody updated the corpus, so for seven months the assistant gave the old notice period. A new benefits provider arrived in September with an entirely new enrolment process, documented in a slide deck that was never added. Two policies were superseded and the old versions stayed in the corpus alongside the new ones, so the same question got different answers depending on which passage matched. The gap log had 340 unanswered questions in it and nobody had opened it since April.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

None of that is a product problem. Every one of those is a job that was nobody's.

So the system did not decay because it was badly built. It decayed because launch was treated as the deliverable, and the thing being launched was a service that needed somebody to run it.

The Three Jobs, and Which One Goes Missing

Almost every deployment assigns the first two jobs and misses the third, and the third is the one that determines whether the thing still works in a year.

Job one: the documents are current. Somebody checks that what the policies say is still true, updates them when a policy changes, and removes superseded versions. This usually has an owner, because documents had owners before the chatbot existed, and it is usually distributed across whoever owns each policy.

Job two: the platform runs. The integration works, the credential has not expired, the ingestion ran, the bill is paid. This almost always has an owner, because it is visibly IT-shaped and IT teams are good at noticing when a thing is down.

Job three: the answers are right. This is not the same as either of the above, and it is the job nobody holds. It means reading the unanswered-question log and turning it into document work. Re-running the test set after any change. Noticing when two passages contradict each other. Catching the answer that is technically derived from a current document and is still wrong for the population asking. Deciding that a question needs a policy written rather than a document edited.

Job three fails in a specific way: invisibly. A document being out of date produces no alert. A contradiction between two passages produces no error. The platform is up, the documents each have an owner, every dashboard is green, and the answers are getting worse. There is no monitoring for this and there cannot be, because the only test is whether an answer is correct, and that requires somebody who knows the answer to look.

The third row is the article.

Why the Natural Owners Each Decline It

This is not negligence. Each candidate has a defensible reason why it is not theirs, and the reasons are what make the gap persistent.

HR says it is a system. The HR team sees a piece of software with an admin console, an integration and a vendor contract, and software belongs to IT. They are also, reasonably, not confident about configuration work and they have no time allocated to it. The part that is genuinely theirs, the content, they already do.

IT says it is content. The IT team sees a working platform whose output depends entirely on documents they did not write, cannot verify and have no authority to change. They cannot tell whether an answer is right. Asked to improve answer quality, the only honest response is that somebody who knows the policies has to do it.

Both are correct about their own half. That is why the gap survives conversations about it. Each party accurately describes the limit of their competence, everybody agrees the other has a point, and the work in the middle does not get assigned because it belongs to a job description nobody wrote.

And the project sponsor has moved on. The person who championed the deployment got it live, reported the win, and is now on something else. Launch had a deadline and an owner. Operation had neither.

The resolution is not to persuade HR to learn the platform or IT to learn the policies. It is to name the middle job as a job, with a person, a time allocation and the authority to change a document without asking permission each time.

What the Owner Actually Does, Monthly

The reason this gets no owner is partly that nobody has said how much work it is. At mid-size it is about two hours a month, and here is the whole of it.

Read the unanswered-question log. Not all of it. The top recurring themes, which will be five or six things. Each one is either a document gap, a vocabulary gap where the content exists under a word nobody uses, or a genuinely missing policy. Sort them into those three piles and act on the first two.

Re-run the test set. Thirty questions, recorded answers, scored three ways. Twenty minutes. This is what catches regression, including the regression your own fix caused last month by adding a passage that now competes with an older one.

Check what changed in the business. New provider, new policy, new office, new contract type, acquisition, anything that makes a current document wrong. This is a two-line email to the HR team asking what changed, and it is the single highest-value question in the monthly cycle because it catches the June leave policy before January.

Read ten real conversations. Aggregate numbers will not tell you that the tone is wrong, that answers have become long and hedged, or that people are rephrasing because the first answer missed. Reading conversations will. Ten is enough.

Write down what you changed. One line each. Six months later this is the only record of why the corpus looks the way it does, and it is what makes the job handover-able rather than resident in one person's head.

That is it. Two hours, once a month, by one person. The job is small and the gap is structural, which is an unusual combination and the reason it goes unfilled: everybody assumes something this consequential must be a large commitment, and nobody wants to take on a large commitment.

What People Get Wrong About This

Should it be a committee?

No, and this is the most common wrong answer. A steering group with representatives from HR, IT, legal and communications meets monthly, reviews a dashboard, and changes nothing, because a group cannot edit a document. Committees are good at deciding policy and incapable of operational maintenance. One person with two hours beats six people with an agenda.

Should it be the person who installed it?

Only if that is written down and resourced. The installer is usually an enthusiast with a day job elsewhere, and enthusiasm has a half-life of about two quarters. When they move role, the knowledge leaves with them and nobody inherits a job that was never defined, which is the second commonest route to decay.

Does it need to be somebody senior?

No, and senior ownership is often worse, because the work is unglamorous and gets displaced by everything else on a senior calendar. What it needs is somebody who talks to employees often enough to know what they ask, who can edit a policy document without a three-week approval cycle, and who has the two hours protected.

Can the vendor own it?

Partly, and be clear about which part. A vendor can tell you that ingestion failed and can advise on configuration. A vendor cannot know that your June leave policy changed, cannot decide whether a gap needs a document or a policy, and should not be the party reading your employees' questions. The judgement half is not outsourceable.

Is it an HR job or an IT job?

Content judgement means it has to sit with somebody who knows HR, and the practical answer at most companies is an HR operations person with a named IT counterpart for anything platform-shaped. The split that works: HR owns answers, IT owns availability, and the owner of answers can raise a platform issue without a ticket queue in between.

The First Month, Which Sets Whether the Job Survives

A named owner with two hours a month still fails if the first month is spent wrong, and it usually is. The instinct is to start by exploring the admin console, which produces familiarity with a dashboard and no improvement anybody notices.

Spend the first month building the three things the job needs, in this order.

Week one: the test set. Thirty real questions from actual inbound, in the words people used, with the correct answer written next to each one by somebody who knows the policy. This is the asset everything else depends on and it is the thing most deployments never create. It takes a morning and it is the difference between a job with a measurement and a job with an impression.

Week two: the source inventory. Every document in the corpus, listed, with its owner and its last-reviewed date. Expect two findings, because they occur almost every time: documents in the corpus that nobody can account for, and documents with no identifiable owner at all. Both are worth more than any configuration change.

Week three: the first gap-log pass. Read the unanswered questions accumulated so far, sort them into document gap, vocabulary gap and missing policy, and fix the first two. The missing-policy pile goes to whoever decides policy, as a list rather than a conversation.

Week four: the change notification. Find out how you will learn that a policy changed, and make it somebody's one-line habit rather than your monthly guess. This is the control that prevents the single most expensive failure in this article.

Then the cycle is two hours a month forever, and it starts from a baseline rather than from zero. An owner who skips the first month is doing job three without a measurement, which means they cannot show the work and will lose the time allocation to the first busy quarter.

The Decay Curve, and Where It Bends

Knowing the shape of this helps, because it tells you when to look rather than leaving it to a complaint.

Launch to about week twelve: the peak. Everything was just restructured and tested. Answers are as good as they will ever be. This is the period in which the deployment gets evaluated and declared a success, which is the trap, because it is being evaluated at its best moment with no information about its trajectory.

Week twelve to about month six: the first drift. One or two policies change. A new process arrives. Nothing is catastrophically wrong, individual answers go stale, and the gap log starts accumulating. Nobody notices because the common questions still work, and the common questions are what anybody spot-checking would try.

Month six to month twelve: compounding. Superseded documents now sit alongside their replacements, so the same question gets inconsistent answers. The gap log is long enough that opening it feels like a project rather than a task, which makes it less likely to be opened. Employees who got a wrong answer have started going back to email, and the usage decline begins.

After a year: the rebuild. By now the fix is not two hours a month. It is a content audit, a deduplication pass, a new test set and a re-announcement, because trust has to be rebuilt as well as answers. Call it a fortnight of real work, plus the credibility cost of relaunching something that was already announced as working.

So the whole argument for naming an owner is arithmetic. Two hours a month for twelve months is 24 hours. The rebuild is more than that, and it arrives with a conversation about whether the project was a mistake.

The Options, and What Each Asks of an Owner

Matram, named below, is owned by the same people who publish HROpsLab. Its limitations are stated as plainly as everybody else's.

Matram

A document-trained answering agent, flat at $29, $69 and $199 a month with unlimited seats. Strict mode makes it decline rather than guess when the corpus does not cover a question.

What it asks of an owner: the strict-mode decline log is the gap list, which makes job three concrete rather than exploratory. The ownership burden is content work rather than platform work, because there is no ticketing layer, no workflow and no agent seats to administer. Its cons are unchanged: no free tier, it answers rather than actioning tickets, and it is not an HR or ITSM workflow platform.

Freshservice

Service management with Freddy AI, at $19, $49 and $99 per agent per month plus a $29 per agent per month AI add-on.

What it asks of an owner: more, and from more people. A ticketing platform has queues, categories, assignment rules and escalation paths, each of which is a configuration decision that rots when nobody owns it. The knowledge base lives inside the product, which is good for consistency and means content ownership and platform ownership are harder to separate cleanly.

Zendesk

Suite Team at $55 per agent per month and Copilot at $50 per agent per month, so $105 per agent per month together. At twelve agents that is $1,260 a month.

What it asks of an owner: the most administration of anything on this list, and the best tooling to do it with. It assumes a support operation with someone whose job is running it, which is accurate at scale and heavy for a three-person HR team.

Leena AI and Moveworks

Enterprise answering and actioning platforms. Neither publishes a price, both sell with implementation attached.

What it asks of an owner: ongoing engagement with the vendor rather than hands-on configuration, which genuinely reduces the internal burden and replaces it with a relationship somebody has to maintain. The failure mode shifts from decay to dependency: when the implementation partner's engagement ends, the same gap appears unless somebody internal has been named.

Crisp

A messaging platform with a chatbot layer, per workspace at a free tier and then $45, $95 and $295 a month.

What it asks of an owner: little, because there is less to configure. The knowledge layer is lighter, so answer quality depends more directly on documents, which pushes the work back to job one where it is already owned.

SiteGPT

A document and site-trained agent at $59 and $129 a month billed monthly, or $468 and $948 per year billed yearly. The annual plans work out near $39 and $79 a month billed yearly and should not be quoted without that qualifier.

What it asks of an owner: re-crawling and source management, which is a small recurring task and a real one. If your content lives as pages it largely maintains itself; if it lives as files behind a login, somebody re-uploads.

The Comparison

The second column is the one to read if your owner has two hours a month rather than two days.

The Decision Table

Writing the Ownership Down

Four lines in the launch plan, and this is the entire intervention.

The name. A person, not a team and not a role that nobody currently holds. If the honest answer is that no individual can be named, the deployment is not ready to launch, and that is a more useful finding before go-live than nine months after it.

The time. Two hours a month, in the calendar, recurring. Unprotected time does not survive a busy quarter, and the whole failure mode here is a small task displaced by larger ones indefinitely.

The three jobs, listed. Documents current, platform running, answers correct, with the name against each. Writing all three makes it visible that the third has an owner, which is the point, and it also makes the first two easier to chase because they are now part of a named arrangement rather than general good practice.

The authority. The owner of answers can change a policy document, or can get a change made within a week by somebody who will. An owner who has to raise a request and wait a month cannot do the job, and this is the clause most often missing. Decay is as often a permissions problem as an attention problem.

Add one more thing if you can: a review date at month three and month nine, with the test set rerun as the agenda. Two meetings in a year, each twenty minutes, and the decay curve above does not get past its first bend.

One sentence on what not to write. Avoid making the owner accountable for a usage target, which is the clause a well-meaning sponsor tends to add. Usage is not within the owner's control and tying the job to it changes the behaviour in the wrong direction: it rewards broadening the scope and discourages the strict-mode declines that make gaps visible. Make them accountable for the unanswered rate and the staleness of the corpus, both of which they can actually move.

Proving the Two Hours Are Worth It

The owner of job three will eventually have to defend the time, usually to somebody who sees a monthly recurring task on a calendar and asks what it produces. Three numbers answer it, and they should be collected from the first month rather than assembled retrospectively when the question arrives.

The unanswered rate, tracked monthly. Not the count, the rate, because volume moves for unrelated reasons. A rate falling from fourteen per cent to five over two quarters is the clearest evidence this work exists, and it is directly attributable: each fall followed a specific document being written.

Stale answers caught before an employee hit them. Count them. When the monthly what-changed question surfaces a policy update that the corpus did not have, that is one wrong answer prevented for everybody who would have asked that question in the following month. Write down the policy and the date. Four of those in a year is the entire business case, and nobody will reconstruct them later.

Repeat questions from the same session. The proxy for answers not landing. Falling means the answers are better; rising after a change means the change hurt and the test set should have caught it.

What not to measure, because it will mislead whoever reads it. Total question volume goes up when the thing is trusted and also up when answers are bad and people retry, so it tells you nothing on its own. Satisfaction ratings are barely used by employees and heavily skewed by whoever is annoyed enough to click. Time saved figures built by multiplying question counts by an assumed handling time are arithmetic dressed as evidence, and quoting one invites a sceptic to attack the assumption rather than the result.

So present the unanswered rate as the headline, the prevented-stale-answer list as the proof, and the repeat rate as the quality check. Three numbers, one page, two minutes to produce from a cycle that is already running.

When the Owner Leaves

The second commonest route to decay, after never naming an owner, is naming one who then moves role. The job was never written down, so there is nothing to hand over, and the successor inherits a working system with no idea that it requires anything.

The whole defence is one document, maintained by the owner as a side effect of the monthly cycle rather than written at handover time.

What is in the corpus and why. The list of sources, with one line each saying what it covers and who owns the underlying document. This is also the only way anybody later works out that a source is in there for no reason, which is how corpora get bloated.

The test set, with current scores. Thirty questions and the answers they should produce. Without this a successor cannot tell whether they have broken something, which means they will be reluctant to change anything, which is its own kind of decay.

The change log. One line per change, which the monthly cycle already produces. Six months of it explains why the corpus looks the way it does and stops a successor undoing a deliberate decision because it looked like an oversight.

The access list and the credentials arrangement. Who can read conversations, who holds admin, what the retention setting is. This is the part that quietly becomes wrong when people change role, and the part with the sharpest consequences.

The three jobs with current names against them. Including the IT counterpart, because that person changes role too and the owner of answers needs to know who to call.

Five sections, none longer than a page, all of them produced by work that is happening anyway. The test is whether somebody who has never seen the system could run next month's cycle from it. If the answer is no, the job still lives in one person's head and the system has an undocumented dependency on their continued employment.

When the Corpus Has Several Owners

Everything above assumes one owner over one document set, which holds at a single-country company of a few hundred people and stops holding as soon as there are separate entities, countries or business units with their own policies.

The failure here is different from decay. It is divergence. Two HR teams each maintain their own documents, both sets end up in one corpus, and the assistant now has two answers to the same question with no way to choose between them. Worse, each team believes their own documents are the current ones, so both are confident and neither is wrong from where they are standing.

Name an owner per document set, and one owner for the corpus. The per-set owners do job one for their own policies. The corpus owner does job three across all of them and is the only person who can see that two sets contradict each other, which is a view nobody else has. Without that single role the contradictions are structurally invisible.

Make the scope explicit in every document rather than in the arrangement. A document that does not say which population and which country it covers becomes a wrong answer the moment it shares a corpus with its counterpart. This is the same scope problem that affects contractors in a single-entity deployment, and it gets much sharper here because both answers are plausible.

Decide whether it is one assistant or several. Separate corpora per entity removes the divergence problem entirely at the cost of maintaining shared content in several places, which then diverges in a different way. One corpus with strict scoping keeps shared content in one place and demands discipline about scope lines. Neither is free, and picking one deliberately beats arriving at a hybrid by accident, which is what happens when each new entity is added to whatever exists.

So the rule scales like this: one owner per document set, exactly one owner for answers, and a written decision about one corpus or several. The two-hours-a-month figure holds per corpus, not per entity.

What Getting This Wrong Costs

The visible cost is the rebuild: a fortnight of content work against two hours a month that nobody spent.

The larger cost is the conclusion people draw. A deployment that decays gets recorded internally as a failed experiment with AI in HR, which is the wrong lesson and an expensive one, because it makes the next attempt harder to fund and sets the organisation's view of the whole category on the basis of an unmaintained document set. Nobody writes down that the leave policy changed in June and the corpus did not.

And there is the cost to the people who used it. Employees who got a wrong answer about notice or enrolment acted on it. They also learnt that the system is unreliable, which is a lesson they keep, so even a well-executed relaunch starts from behind. Trust is cheap to maintain monthly and expensive to recover once.

Ask the question this way before launch. If nobody does anything to this for a year, what will it be answering in January? The answer is knowable, it is bad, and it is the most persuasive argument available for two hours a month.

When You're Ready to Formalise It

Once an owner has been running the monthly cycle for two quarters, two things are worth adding and neither needs more time.

Turn the change notification into a routine rather than an email. The monthly question about what changed in the business works and depends on somebody remembering to ask. The better version is that whoever approves a policy change has one line in their own checklist: tell the person who owns the answers. That moves the trigger to where the change happens, which is the only place it is reliably known.

Put the owner's name in the assistant's own answers. When it declines a question or a document is out of date, the reply can name who to tell. That turns every employee into a reporter of gaps, which is the cheapest monitoring available for a job whose defining property is that failures are invisible. It also makes the ownership real to the organisation rather than a line in a plan nobody reads.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements.