A messenger usually appears in a company as a place to talk, and a year later it becomes a place for everything: invoices, error screenshots, voice notes, memes, contracts and the phrase "please take a look, urgent". Information flows through it, but it flows like water through a basement after a flood: everywhere and nowhere. And here an interesting question appears. If people live in the chat anyway, why not turn it from a swamp into the company's nervous system?
This approach is called ChatOps, and behind the fashionable word stands a very simple idea. Important events from all company systems arrive where people already are, in a readable form and in the right channel. And some actions can be performed right from there, without opening five different tabs.
A company as an organism
Imagine an organism that has hands, legs, eyes and ears but no nerves. A hand gets burnt, and the brain learns about it from a weekly report. It sounds absurd, yet this is exactly how many companies work. A client paid for an order, and the manager finds out when he happens to open online banking. A server went down at three in the morning, and they learn about it in the morning from an angry client. A new lead came from the website on Friday evening and lay there until Monday, going cold like yesterday's tea.
Integrating services into a shared chat is exactly those nerves. CRM, payment system, website, task tracker, code repository, server monitoring: each of them can send events. The task is to make these signals arrive where they will be seen and acted upon, instead of piling up in separate mailboxes that nobody opens.
What exactly should go to the chat
The most common mistake I see: a company connects integrations and sends absolutely everything to the chat. A week later the channel becomes a waterfall of notifications, people mute it, and we are back at the start, only now with the feeling that "automation doesn't work". A nervous system that constantly screams in pain is as useless as having none.
So the rule is simple: the chat receives only events that someone must react to or that someone needs to know right now. From my practice, these work well:
- a new request or lead from the website, straight to the sales channel, with contacts and source;
- an incoming payment, to the finance channel and the responsible manager;
- the website going down or a server error, to the technical channel, with a link to the log;
- a task that is overdue or stuck in one status longer than usual;
- a new customer review, especially a negative one;
- a daily digest: how many leads, how many payments, what the team got done, compiled by a bot into one message.
And here is what is better kept out of the chat: every commit, every task status change, every user login. That is noise. Noise belongs in logs and dashboards that people check when they need to.
From notifications to actions
The first level of ChatOps is notifications. The second, much more interesting one, is actions right from the chat. The bot posts "new request from a client" with the buttons "take it" and "pass to a colleague" underneath. The manager clicks a button, the CRM assigns the owner automatically, the client gets an email, and the channel shows who took the request. Nobody opened the CRM, yet the process went all the way through.
The same goes for approvals. A contractor's invoice arrives in the director's channel, he clicks "approve", and accounting gets a payment task. An employee's vacation, a purchase, publishing an article: plenty of small processes that used to need an email, a call and a reminder three days later fit into a single button.
The key is not to overdo it. A chat is good for short yes-or-no decisions and bad for complex work with data. If an action requires filling in ten fields and looking at history, it is done in the system, and the chat gives a link to it. The chat is nerves and reflexes, not the brain. A company's brain lives in its business system.
How it works technically and what it costs
The good news: in most cases there is nothing complicated. Almost all modern services can send webhooks, notifications about events to a given address. Telegram, Slack and most corporate messengers let you create a bot in a few minutes. Between them you need a layer: a small service that receives events, decides who should get them and in what form, and performs actions in other systems when needed.
For simple connections, builders like Make or n8n are enough. For serious processes where reliability, access rights and business logic matter, it is better to write your own small integration service. It costs more at the start, but it does not break when the builder changes its pricing and does not fall apart when the number of events grows tenfold.
At Ingello a large part of our internal processes lives exactly like this. A bot reports new requests from our websites, publishes reports on how our automations performed, and warns if something broke during the night. I learn about problems before a client has time to notice them. It is not magic, just nerves wired to the right organs.
Pitfalls
The first: security. Passwords, full card data and more personal client data than necessary must never end up in a chat. A messenger is not a safe, and more people have access to it than you think.
The second: dependence on one channel. If the whole company reacts only through the chat, a messenger outage paralyses work. Critical notifications should be duplicated, for example by email or SMS.
The third: blurred responsibility. Everyone sees a message in a shared channel, and that is exactly why often nobody reacts. Every event needs a specific recipient or a rule for who picks it up. Otherwise you get the well-known bystander effect: thirty people saw the server go down, and each was sure someone else was already on it.
Where to start
Write down three events in your company that you learn about too late. Usually these are new requests, payments and outages. Connect exactly those, each to its own channel and with a specific owner. Live like that for a month, see what really helps and what turned into noise, and only then add the next one.
If your processes already live in a business system like Forma, chat integrations are connected on top of it, and the bot becomes the voice of the system rather than a separate piece of amateur work. If there is no business system, a chat bot will not save you: nerves need something to lead to. But you can start with them tomorrow, and the effect will show with the very first request that did not spend the weekend waiting.
