Slack Chatbot Development
Slack bots are mostly an internal tool, and the ones that get used share a property: they remove a reason to leave Slack. Looking something up, approving something, or asking a question that would otherwise have gone to a colleague.
Discuss your projectWhat we build
Knowledge assistants
Ask a question in Slack, get an answer from your own wiki, policies and documentation with citations. The most common request, and the one that saves the most interruptions.
System lookups
Customer, order, account or ticket details fetched into Slack, so a sales or support question does not require opening three systems.
Approvals
Purchase requests, time off, discounts, content sign-off — approved with a button, recorded in the system of record, with the audit trail intact.
Alerts worth reading
Routed to the right channel with enough context to act on and few enough of them to be read. A channel of unread alerts is the same as no alerts.
Form filling and record creation
Creating a ticket, logging an issue or raising a request through a modal, without leaving the conversation that prompted it.
Standups and recurring prompts
Collected in a thread and summarised, which suits distributed teams better than a meeting.
Channel summaries
What happened in a busy channel while someone was away, on request rather than automatically.
Permissions, which matter more in Slack than people expect
A Slack bot answering from company documents sits in an environment where everyone can see everything in a public channel. If the bot replies in-channel with content drawn from a restricted source, it has published it to the channel — and permission filtering at retrieval is not enough on its own, because the answer is visible to people who were not the asker.
So the rule we apply is that answers derived from access-controlled sources are returned ephemerally or by direct message, visible only to the person who asked, unless the content is known to be open to everyone. Anything else turns a correctly-permissioned retrieval system into a leak with extra steps.
Scopes deserve the same discipline. Slack's OAuth scopes are granular and it is easy to request broad ones because they make development simpler. We request the minimum the bot actually needs, which also makes the app far easier to get approved by your own IT function.
How we build them
- Slack's Bolt framework, with Socket Mode for internal apps where exposing a public endpoint is unnecessary.
- Block Kit for anything structured, since a wall of text in Slack gets skimmed and buttons get used.
- Threads by default rather than channel replies, so a conversation with the bot does not bury the channel.
- Modals for input, which handle validation properly instead of asking people to format a message correctly.
- The three-second acknowledgement rule respected: Slack requires a fast response, so anything slow is acknowledged immediately and the real answer posted when ready.
- Home tab where the bot has a surface worth having — a dashboard or a list of pending items.
- Installed as a private app in your workspace, not published to the directory, unless you want it distributed.
Common questions
Related in AI Chatbot Development
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch