Conversational analytics in Slack and Teams
What should you know before deploying a Slack analytics bot or Teams data bot?
A Slack or Teams bot answers metric questions with charts, cutting the data team's ad-hoc request queue to the hard questions. It works when it uses the dashboards' governed metric definitions, respects each asker's permissions even in channels, replies in-thread with chart and query, and hands off when stuck.
A Slack analytics bot succeeds or fails on one question: does the answer arrive where the conversation is already happening, with a chart, in under a minute, and is it the same number the dashboard shows? If yes, the data team's request queue shrinks to questions worth an analyst's time. If no, people go back to messaging the analyst directly. This article covers what a good conversational analytics bot in Slack or Teams does, the design decisions that matter in a chat surface, the permission problems chat introduces, and what it takes to build one on a safe text-to-SQL foundation.
What conversational analytics in chat is and why it works
The bot is a natural-language query tool, with a semantic layer and access controls underneath, delivered as a Slack app or a Teams bot. A user types "@data how many signups last week by plan?" in a channel or a direct message; the bot replies in a thread with a short sentence, a chart, and a link to the query it ran. Follow-ups ("now by country", "compare with the week before") modify the previous request. The reason chat works better than a separate web tool is simple: the question was already being asked in Slack, of a person. The bot answers the same question in the same place without the person.
The foundation is the same as any natural-language data querying build: governed metrics, row-level security, validation, a golden set. Chat changes the interface and the permission model, not the engine.
Web tool versus chat bot: what changes
| Concern | Web analytics tool | Slack or Teams bot |
|---|---|---|
| Where the question starts | User opens a tool | Where the conversation already is |
| Identity | App login | Slack or Teams user mapped to your identity provider |
| Audience | One user | A channel; the answer may be visible to people with different permissions |
| Output | Tables, dashboards | One sentence, one chart, a link to more |
| Follow-ups | Edit filters | Thread replies that modify the last request |
| Failure | Error message | "I could not answer that; here is who can" plus a ticket |
| Latency tolerance | A few seconds | Under a minute, with a typing indicator or a "working on it" reply |
The channel problem: who can see the answer?
In a web tool the answer goes to the person who asked. In a channel, the answer is visible to everyone in it. If a regional manager asks a revenue question in a company-wide channel and the bot answers with her region's permissions, people who cannot see that region now can. The rules we use: in direct messages, the bot answers with the asker's permissions; in channels, the bot answers with the intersection of the channel members' permissions, or, more simply, only with metrics marked as safe for that channel's audience; anything else it answers in a DM and posts "sent you the answer privately" in the thread. Channel-to-audience mapping is configured by the data owner, not guessed by the bot. The enforcement is at the query layer as described in row-level security for AI analytics; the channel rule sits on top.
Design for a thread, not a dashboard
The best reply is one sentence with the number, one chart, and a "details" link. Not a table of forty rows, not a paragraph. The sentence states the metric, the period and the filter exactly as the bot understood them ("Signups, last 7 days, by plan: Pro 412, Starter 388, Free 1,204") so a misunderstanding is obvious at a glance. The chart is rendered as an image with sensible defaults: a line for time series, bars for categories, never a pie. The details link opens the query, the SQL or pipeline, and the option to save it as a scheduled report.
Follow-ups and thread memory
Thread replies carry state. "Now by country" changes the dimension; "last quarter instead" changes the period; "why?" triggers a narrative insight over the same metric. State is per thread and expires, so a question in a new thread starts clean. Users learn this in minutes if the bot's first message explains it.
Scheduled and triggered posts
Once people trust the bot, they ask it to post the same answer every Monday. Scheduled reports into a channel are a small addition and a large part of the value. Threshold alerts ("tell #ops if on-time rate drops below target") are the next step, and they are where a chat bot starts to replace a dashboard nobody opened.
Building the Slack and Teams integrations
Slack apps use the Events API and Block Kit for rich replies; the Slack API documentation covers app manifests, scopes and the message formats. Teams bots use the Bot Framework and Adaptive Cards for the same purpose. In both, the important engineering is not the message formatting but identity: mapping the chat user to your identity provider so permissions are the user's, handling the acknowledgement window (Slack expects a response within seconds, so long queries need an immediate "working on it" and a later edit), and keeping the bot's own credentials to the minimum scopes. The engine sits behind an internal API so the same brain serves Slack, Teams and the web app.
Measuring whether it worked
The number that matters is the data team's ad-hoc queue: how many requests arrived, how many the bot answered, how many escalated, and what the escalations were about. Add answer accuracy from the golden set, the share of questions that got a follow-up (a proxy for usefulness), and the share of "could not answer" replies, which is the roadmap for the semantic layer. Do not measure message volume alone; a bot that is asked a lot and wrong a lot is worse than no bot.
A worked example
A B2B SaaS company's two-person data team spent most mornings answering Slack questions from sales, customer success and product. The questions were repetitive (signups, activation, churn by segment) and the definitions were contested. The first release of the bot covered fifteen metrics from the company's existing semantic layer, answered in DMs with the asker's permissions, and in three named channels with a metric allow-list per channel. Every reply had a chart and a details link; failures created a ticket in the data team's queue with the original question attached. Shadow mode ran inside the data team's own channel for two weeks. After launch, the team's queue changed character: the repetitive questions stopped arriving, the escalations were mostly definition questions that led to new metrics, and the Monday scheduled posts replaced a dashboard that leadership had stopped opening. The same company's in-product analytics later reused the engine, which is the pattern in the in-app copilot case study.
Team and timeline
A Slack or Teams analytics bot on top of an existing safe query engine is an AI engineer and a full-stack engineer over three to four weeks: identity mapping, channel rules, Block Kit or Adaptive Card replies, charts, threads and scheduled posts. Without the engine, the full build is four to eight weeks and is priced as natural-language data querying from $12,500 or ₹8L, with the bot surface as part of the scope. The integration work itself fits the API development and integrations service. A three-week ProofRun puts a working bot in one channel with your data and an accuracy number; see the pricing page.
Before you start: a checklist
- Log the data team's ad-hoc questions for two weeks; that is your golden set and your scope
- Confirm the metric definitions are governed somewhere the bot can use
- Map Slack or Teams users to your identity provider and roles
- Decide the channel rule: DM-only, per-channel metric allow-lists, or intersection of permissions
- Design the reply: one sentence, one chart, a details link
- Define the failure path: who gets the ticket when the bot cannot answer
- Set the acknowledgement and timeout behaviour for slow queries
- Name the data owner who reviews unanswered questions weekly
Glossary
- ChatOps analytics: asking and receiving data answers inside the team chat tool
- Block Kit / Adaptive Cards: Slack's and Teams' formats for rich, interactive messages
- Thread state: the remembered last request that follow-ups modify
- Channel allow-list: the metrics a bot may post in a given channel
- Scheduled post: a saved question the bot answers into a channel on a timetable
- Escalation ticket: the record created when the bot cannot answer, routed to the data team
Questions clients ask
- Can the bot answer in Hindi or other languages? Yes. The model handles the language; the metric catalogue carries synonyms per language so "bikri" maps to sales as reliably as "revenue" does.
- What if two people in a thread have different permissions? The bot answers the first asker in the thread with the channel rule applied; a follow-up from someone with different permissions is answered privately.
- Will it work in Slack Connect channels with external partners? Only with an explicit allow-list of partner-safe metrics per shared channel; by default the bot stays silent in external channels.
- How do we stop people relying on it for board numbers? Board numbers come from the same semantic layer, so they match; the details link shows the query so finance can verify.
- Can it be installed in both Slack and Teams? Yes, from one engine behind an internal API; the two surfaces differ only in message formatting and identity mapping.
Related reading
Read ask your database for the engine, the semantic layer for the definitions, and natural-language reporting for turning saved questions into dashboards.
Put the answer where the question was asked, keep the permissions honest in channels, and the data team gets its mornings back.
Frequently asked questions
Can a Slack analytics bot respect data permissions?
▾
Yes, if it maps the Slack user to your identity provider and enforces row-level security at the query layer. In channels, restrict it to metrics safe for that audience or answer privately.
Does the bot replace our dashboards?
▾
It replaces the dashboards nobody opens. Scheduled posts and threshold alerts in a channel are read; a saved dashboard often is not. Complex exploration still belongs in a BI tool.
How long does a Teams or Slack data bot take to build?
▾
Three to four weeks on top of an existing safe query engine; four to eight weeks including the engine. A ProofRun delivers a working bot in one channel in three weeks.