Slack HR chatbot: what it answers, what it can read, and what it refuses to guess

Type "Slack HR chatbot" into a search box and two different kinds of product come back under one name. The first is a general-purpose assistant in a Slack window: ask anything, get a fluent paragraph assembled from the internet at large. The second is wired into your company's own facts — it reads a specific source before answering, and it can act on what was asked. AI HR Bot is the second kind, scoped to HR: policy questions, leave, and the small requests in between.

This page is the long version of what that second kind does, section by section, with the numbers and the Slack permissions named rather than summarised. If you are comparing a few of these, the last section is a checklist you can point at any vendor, including us.

The boundary before the argument: the Free plan covers a Slack workspace of up to 5 people, and every plan has every feature — policy answers, Leave Requests, Employee Memory and Leave Policies with monthly Accrual alike. From the sixth person, the Team plan is $5 per person per month: every person, not only those past five. Nothing below depends on reading the pricing page generously.

Here is the second kind, in a channel:

What a Slack HR chatbot is for

The problem it solves is not that HR answers are missing. It is that they go unread. The handbook is thorough, the policy page is current, and the same five questions arrive every week anyway — because looking something up costs more attention than asking a person.

An HR tool that lives behind a login is one people visit when they already know what they want, and most HR questions are not like that: they are small, immediate, and slightly embarrassing to ask out loud. Slack is where those questions already happen, so putting the answer in the same place removes the only real barrier.

So the job splits in two. A chatbot that only talks is a search box with manners. A useful one answers the question and does the thing the question was leading to — files the Request, starts the approval, moves the balance. Both halves are below, in that order.

Where the answers come from

A policy question is answered from your own Knowledge Base entries, matched against the question that was asked — the handbook your HR Head uploaded or taught, not the internet's idea of one. The bot has no browsing tool: when it lacks an answer, it cannot reach for the web and present some other company's policy as yours. An answer joins the Knowledge Base only when your HR Head uploads it or teaches it.

The Knowledge Base holds two kinds of retrievable thing, searched together on every lookup. A Knowledge Base entry is an authored question-and-answer pair — wifi password, vacation policy, working hours — written by a person and added to over time. A Passage is a contiguous stretch of a document your HR Head gave the bot: a Knowledge File they uploaded, or a Write-up they typed on the dashboard. A Knowledge File's extracted text is kept and the original binary is not, so a revised edition replaces the old one whole rather than being edited in place.

That is the part the "AI" in the name tends to hide. The model is a commodity, and every vendor's model writes the same fluent paragraph. What separates one Slack HR chatbot from another is what it is allowed to read — and what it does when the reading comes up empty.

What happens when it has nothing to read

This is the half that matters more, because it is where a confident wrong answer would come from. A vacation policy improvised with perfect grammar, and someone books a week they do not have.

You cannot fix that by asking the model nicely. A prompt is an instruction, not a guarantee, and any vendor claiming their bot "never hallucinates" is making a claim no prompt can carry. What can be trusted instead is the structure around the model — what it reads before it answers, and what happens the moment it has nothing to read. Here is that structure, in both places it runs:

When no entry clears the similarity bar, the system prompt prescribes the exact wording of the refusal — down to "Do NOT guess" — instead of leaving the model to improvise, and the unanswered question is recorded as a Knowledge Gap either way. The bot then opens a fresh direct-message thread with the first HR Head listed for the Workspace — one person, not a broadcast — asking to be taught, and the reply in that thread becomes the saved answer for the next person who asks.

When the same question returns within a day it is recorded again but sends no second message: a popular Knowledge Gap is a signal, not a stream of interruptions. The prescribed refusal is still an instruction to a model, and this page will not pretend an instruction is a physical law — but the record, the direct message and the saved answer are structural, and they hold whatever the model does.

What that buys you is a list of the questions your handbook failed to answer, in the order your team actually asked them. The handbook then grows exactly where it was thin. The full walkthrough is what happens when an HR bot doesn't know the answer.

What it does, not just says

"Can I take next Friday off?" files a Leave Request and starts the Approval Chain in the same step — the card lands in the Lead's Slack as a direct message with Approve and Deny buttons, not in a queue nobody opens.

A Request is a formal submission of one of four kinds: a day off (sick, paid, or unpaid), vacation, remote work, or arriving late. It walks an Approval Chain — an ordered sequence of approvers, scoped per Workspace and per Request type. A fresh install seeds every Request type with a Chain, so nothing has to be designed before the first Request works. The seeded default is the Employee's Lead, then their HR Contact. Your own steps, in your own order, are on every plan.

The card carries everything the decision needs — who is asking, which department, which dates — with no covering note and no link out. Denying asks for a reason, and the Employee sees it; a denial with a sentence attached is a conversation, a bare one is a mystery somebody has to go and solve.

An HR Head is never stuck behind somebody else's step: they can approve or deny any pending Request in the Workspace, whether or not the Chain is currently waiting on them. And the dashboard's Requests view is deliberately read-only — decisions happen in Slack, where the card already is. The Approval Chains page draws the card set, and how a leave request gets approved walks one Request through the whole sequence.

The numbers it quotes

Ask how many vacation days you have and the answer is a number like 11.66. The specificity is the point.

A Leave Balance grows by one Accrual per completed month, landing on the Employee's monthiversary in the Workspace's own timezone — hired on the 15th, you complete a month on the 15th. Hired on the 31st, you complete February on the 28th, because the count is clamped to the end of a shorter month; the clamp borrows a day, it does not move your anniversary.

The rate is held to four decimal places, so 20 days a year is 1.6667 a month, and twelve of those come to 20.0004 on the books. What the bot reports is cut to two decimals and rounded down — told "11 days" when you hold 10.99, you would book a day you do not have. The error always favours caution, never the appearance of generosity.

Three edges worth naming, because naming them is what makes the middle believable. Accrual is anchored at the later of the Hire Date and the moment the Leave Policy was created, so a Workspace never owes back-pay for service predating its own policy. Without a Hire Date nothing accrues at all — the bot does not guess a tenure, and the absent date is surfaced to your HR Head as the one failure they can actually fix. And a balance is the sum of its grants rather than a figure recomputed from tenure, so an HR Head's manual adjustment is never silently overwritten by the next run.

The Leave Balance moves when the Request is approved, not when it was filed — so the number the chatbot quotes while a card is still waiting is the balance actually held. The full arithmetic is in how a Leave Balance accrues, the same sums run standalone in the vacation accrual calculator, and the day-to-day version is how to track PTO in Slack.

One asymmetry people miss: the day-off balance covers paid day-offs only. Sick and unpaid day-offs are untracked and consume nothing.

What it can read

This is the question to ask any HR bot first, and Slack answers it precisely on the consent screen, in a language most people close without reading — scopes.

Ours are named publicly, as one list you can diff against what Slack shows you, and exactly two of its Slack permissions read messages: im:history covers the direct-message threads the bot is part of — the conversations with the bot itself, so an exchange keeps its context — and app_mentions:read covers the messages that mention it in a channel, so it can answer. Everything else in your Slack is outside the request.

That exclusion is the whole point of reading the list. There is no channels:history, no groups:history, no mpim:history — it cannot read your channels, your private channels, or your direct messages with other people, even in a channel it has been added to. There is no workspace search scope. And the request has no user half at all: without a user_scope, it never acts as you.

The rest of the list writes, or resolves names. chat:write and im:write post replies and open a direct message. assistant:write runs Slack's own assistant pane. files:read and files:write carry a voice note in and a spoken answer back out. reactions:write adds the :eyes: acknowledgment the moment a direct message arrives. users:read matches a Slack account to an Employee and resolves their Lead and HR Contact, and users:read.email reads the address a Google Calendar invitation has to be sent to, which is what meetings need.

Every one of them, with the reasoning, is in what a Slack HR bot can read.

What else lives in there

Two capabilities that are neither questions nor leave. Birthdays are part of the assistant on every plan including the free one: a Reminder up to seven days ahead to the HR Heads and the Employee's own Lead, and one shared Wish on the day, never before nine in the morning in the workspace's own timezone. A birthday is stored as a month and a day — the year is stripped on arrival, so nothing in the system can answer how old somebody is. The rules are on the Birthdays page, and the cost comparison people usually arrive with is the free BirthdayBot alternative.

Employee Memory, on every plan, is what lets a conversation continue across weeks rather than restarting cold each time. It is per-Employee and private to that thread: a Birthday Wish never draws on it, because a public post revealing something told to the bot in confidence is an incident, not a personal touch.

What it costs

Free covers a Slack workspace of up to 5 people; only active, full members count, never bots, guests or deactivated accounts. From the sixth person, Team is $5 per person per month — $4 a month billed annually ($48 a year) — and every person is billed, not only those past five. People who join are billed from the day they join, and people who leave stop being billed at the next renewal. Team starts with a 14-day free trial that begins by itself, no card needed. Every plan has every feature, with no cap on Knowledge Base entries or HR Heads, so the plans differ only in size and price. Enterprise is custom terms by contract, with invoicing and priority support and onboarding. Prices are in USD, excluding tax, and billing is self-serve: your card, invoices, monthly or annual billing and cancelling are all in the dashboard.

How to choose one

Five questions that separate these products, in the order they matter. They are the questions we would want asked of us.

Where do its answers come from? If a vendor cannot name the source, the source is the internet, and what your team gets is some other company's policy in your company's voice.

What does it do when it doesn't know? "It never gets things wrong" is not an answer. Ask what is recorded on a failure, and who is told. A product with no answer here has no path from a bad answer to a better one.

Which Slack scopes does it request? Read the consent screen before you click Allow. channels:history means it can read every channel it is in. A user_scope means it can act as you. Ask why each scope is there, and be suspicious of a list longer than the features you were sold.

Can it act, or only reply? Answering "how many vacation days do I have" is a search box. Filing the Request and routing the approval is the part that removes work from somebody's week.

What happens to the arithmetic at the edges? Ask how it rounds, what it does with someone hired on the 31st, and what it does when a hire date is absent. The answers tell you whether anyone thought about it — and rounding up is the tell.

Getting it running

Installing takes an HR Head, a Slack workspace, and the consent screen above. Chains are seeded, so the first Request works before anything is configured. What is worth doing on day one is teaching it: upload the handbook, write up the policies that live nowhere else, and answer the first few Knowledge Gaps as they arrive. A Knowledge Base with your real answers in it is the whole difference between the two kinds of chatbot this page opened with.

The install guide covers the setup, the HR Head guide covers keeping the handbook honest, and the employee guide is the one to paste into a channel afterwards. If you would rather see the shape of the whole thing first, HR automation in Slack is the four-chore version of this page.