When it alerts
- The agent hands a conversation to a person
- A customer flags their case as urgent
- A topic repeats often enough to deserve an article
- An action against your API fails and nobody has seen it
Slack is not a channel where your customers write: it is where your team works. When the agent hands off a conversation, flags it as urgent or spots a repeating topic, the alert lands in the channel you already have open, with the case summarised and a link to open it.
What it solves
The invisible work of a small team is checking every half hour whether something came in. With alerts in Slack that habit disappears: if the agent closes it, there is no message; if it cannot, it lands in the channel you are already in. The inbox stops being something to watch and becomes something you open when it calls you.

What it solves
An alert saying "you have a new ticket" forces you to open the conversation, read it all and look up which plan that customer is on. Ours carries the plan, how long they have waited and what the agent already tried before handing off. Whoever picks it up decides whether it is theirs without leaving Slack.

What it solves
The temptation of any alerting integration is to notify everything, and the result is a channel the team mutes within two weeks. Here you choose what triggers an alert and which channel each thing lands in: conversations the agent resolves alone make no noise, which is half the point of having an agent.

What it does
An integration is not useful for being on the list: it is useful for what it lets the agent do. This is what Slack puts on the table, and what the agent does with it without anyone watching.
When it alerts
What lands in the channel
Three concrete things that change the team day, not a feature list.
The team stops checking every half hour to see whether something came in. If the agent closes it, there is no alert; if not, it lands where you already are.
Whoever picks it up does not have to open three tabs to understand it: plan, wait time and what was already tried come in the message itself.
You choose what alerts and in which channel. Conversations the agent resolves on its own make no noise, which is half the point.
Three steps, and only the first needs a Slack admin. The rest you change later without reconnecting anything.
You open the integrations panel, pick Slack and authorise access with the account your team already uses. You need to be an admin in Slack, so if you are not, this is the only step you will have to ask someone for.
You tick the channels, events and account fields it can reach. What you do not tick does not exist for it, and you can change that whenever you want without reconnecting anything.
From the first conversation the agent looks that data up before replying, resolves what it can close on its own and passes to a person what it cannot, with the case already assembled.
Minutes, not an afternoon. You authorise access and choose what it can see; nothing needs rewriting and no development work is needed to start.
Yes, and from either side: revoking the connection in Intake or withdrawing the permission from Slack. The agent stops reading that data immediately and keeps answering with the rest.
No. Every integration sits inside the per-resolved-conversation price: 0.41 EUR on annual billing. There is no add-on to buy and no call meter.
The agent answers with what it does have and, if the question depended on that data, hands off to a person explaining why. It never invents the value it could not look up.
No. Slack is for your team. Customers write through your product widget, email or WhatsApp; what reaches Slack is the alert about what needs a person.
The alert carries a link to the conversation, which is where you reply. That keeps everything in one thread and the customer does not get two different answers.