Slack chatbot: when Slack's own is enough and when to build one

The short version

• A Slack chatbot is a Slack app that receives messages as events, finds an answer in your own systems or through a language model, and posts the reply back.
• The app is the small part of a Slack chatbot. Most of the work is retrieval, permissions and keeping the knowledge current.
• An answer posted in a shared Slack channel can be read by everyone in that channel, so checking only the asker's permissions is not enough.
• Slack's May 2025 rate limit change targets non-Marketplace commercial apps, while internal customer-built apps keep 50+ requests per minute and 1,000 objects per request.
• A Slack chatbot is not worth building when there is no maintained source of answers or too few people ask the same questions.

What is a Slack chatbot?

A Slack chatbot is a Slack app that reads messages and replies inside Slack. Older ones matched keywords or ran fixed commands. Most new ones pass the question to a language model, along with passages found in company documents, and post the answer back in a thread.

You will also see it called an internal chatbot, an employee chatbot or a team chatbot. The job is the same: it answers staff rather than customers. That difference shapes the design. Staff have accounts, documents have access rules, and a colleague may act on a wrong answer without checking it.

How does a Slack chatbot work?

A Slack chatbot works as a loop. Slack sends your app an event, the app works out who asked, retrieves what that person may see, asks a model, and posts the reply. The steps below are the same whether you call it a chatbot in Slack or a chat bot for your team.

An internal app can receive events over a public HTTP endpoint or over Socket Mode, which needs no public URL. For a bot that only serves your own workspace, Socket Mode is often the simpler start.

What are the steps in a Slack chatbot's loop?

1. Slack sends your app an event when someone mentions the bot or messages it directly.
2. The app acknowledges the event and maps the Slack user to an identity your other systems recognise.
3. It searches only the documents that person may see, and works out who will be able to read the reply.
4. It sends the question and those passages to a language model.
5. It posts the answer with its sources, in a thread, a direct message or an ephemeral reply.

What goes wrong first when you build a Slack chatbot?

Slow replies and unknown users. Slack expects an event to be acknowledged within a few seconds and retries if it is not, while retrieval and a model call often take longer. So acknowledge first, do the work in a background job, and ignore repeated events, or people will see the same answer twice.

Identity is the second problem. An event gives you a Slack user ID, not an identity your document systems recognise. You have to map one to the other, usually by email address, before any permission check means anything.

Who can see a Slack chatbot's answers?

Everyone who can read the channel can see what the bot posts there, whoever asked. So a permission check against the person asking is not enough. The answer has a wider audience than the question did.

Take a manager who can open the salary spreadsheet and asks the bot about it in a team channel. The bot checks the manager's access, finds the file and answers correctly. Everyone in that channel has now read it, including guests and, in a Slack Connect channel, people from another company.

There are three workable rules. Answer restricted questions in a direct message. In a channel, use an ephemeral reply, which only the asker can see. Or answer in the open only from sources every member of that channel may read. We would default to the first two, and allow open replies only from content marked for all staff.

The index has its own version of this problem. Content copied into a search index does not carry the source system's permissions unless somebody carries them across and keeps them current. Check permissions before the search, not after it.

Should you use Slackbot or build your own Slack chatbot?

Try Slackbot first, unless you already know it cannot reach the knowledge you need. It is Slack's own assistant, so there is no app to build or host. Slack publishes limits and credit usage for it, so compare those with the volume you expect before you rely on it.

Build your own when answers depend on systems outside its reach, when your access rules are unusual, or when the bot has to take actions such as raising a ticket or updating a record. A third-party platform sits between the two. It is quicker than a build if a connector exists for your sources, but ask how it carries source permissions across and where it stores your content.

Which route suits which need?

Do Slack's rate limits affect a Slack chatbot?

Yes, if the bot reads channel history or threads, and the effect depends on what kind of app it is. Slack changed the rate limits on conversations.history and conversations.replies for non-Marketplace commercial apps created after 29 May 2025, and for new installs of existing ones.

Internal customer-built apps are treated differently. The same Slack page says they keep 50+ requests per minute and 1,000 objects per request. So a bot you build for your own workspace is not caught by the change that applies to a commercial tool outside the Marketplace.

This matters most for bots that use Slack history as a knowledge source. Before you sign with a vendor, ask whether its app is on the Slack Marketplace and how it reads history. Reading one thread to answer a question is a light load. Indexing every channel is not.

What does a Slack chatbot cost?

It depends on the route, and no honest single figure covers them all. Slackbot's cost is your Slack plan and its usage limits. A built bot's cost is engineering, model usage per question, hosting and upkeep.

On the Slack side, the June 2025 price announcement gave $15 on annual billing, with a footnote setting monthly billing at $18. Salesforce's Slack pricing page listed $18 billed monthly when read in November 2026. Check which plan and features that covers for you before comparing it with anything else.

On the build side, we have no number worth quoting without seeing your sources. Upkeep is the line that is easiest to leave out. Connectors break when source systems change, permissions drift, and answer quality needs re-testing whenever the model or the documents change. Someone has to own that after launch.

Does a Microsoft Teams chatbot work the same way?

Mostly, yes. A chatbot for Microsoft Teams runs the same loop of event, identity, retrieval and reply. What changes is the packaging and the identity system.

A Teams bot is packaged as a Teams app and registered with Microsoft, and it identifies people through Microsoft Entra ID. If your documents live in SharePoint, that helps, because the chat user and the document permissions come from the same directory. On Slack you usually have to build that mapping yourself.

The audience problem is identical: a reply in a Teams channel can be read by the whole channel. Check Microsoft's own Copilot offering before you build, for the same reason you would try Slackbot first. If you run both platforms, keep retrieval and permissions in a service of their own, so that each chat platform is only a thin adapter on top.

When is a Slack chatbot not worth building?

It is not worth building when there is no maintained source of answers, or when too few people ask the same questions. A bot over a stale wiki gives out-of-date answers with more confidence than the wiki ever had.

A small team where everyone can ask the person who knows has little to gain. A fixed form or workflow is better when a request always has the same shape, such as booking leave. And where a wrong answer has legal or regulatory consequences, plan for a person to review it, or leave that topic out of the bot's scope.

If stale documents are the real problem, fix those first. That work pays back whether or not you ever build a bot.

Is there evidence that workplace chatbots help?

Not evidence you can apply directly to a bot in your own Slack. The two closest studies we can point to are field experiments in different settings, and both are preprints with Microsoft-linked authors.

One is a randomised trial on a support chatbot for Microsoft's internal developers, covering 3,296 sessions from May to October 2023, with traffic of only 5 to 20 cases per week. No peer review is shown. The other covers 7,137 knowledge workers across 66 firms from September 2023 to October 2024, with access to a generative AI tool in email, meeting and writing software randomly assigned. It thanks anonymous referees but names no journal.

We have no case study of our own to add. So measure it yourself: how often the same question reappears in your channels before and after launch, how many questions end with no source found, and how many answers people mark as wrong.

What should you test before a Slack chatbot goes live?

• •Ask about a restricted document in a shared channel and confirm nobody else can read the reply.
• •Repeat the test with a guest account and, if you use them, a Slack Connect channel.
• •Remove someone's access at the source and confirm the bot stops using that document for them.
• •Delete a document and confirm it stops appearing in answers.
• •Send the same event twice and confirm only one reply comes back.
• •Ask something the documents do not cover and confirm the bot says it does not know.
• •Put instructions inside a test document and confirm the bot does not follow them.