In 2017, my webshop Pasfoto.nu was eight years old. Over that time, I had added a separate application for almost every part of the business: orders, customer support, analytics, outages and errors. Each system had its own notifications. I had plenty of information, but I had to look in too many places to know whether anything needed doing.
I wanted one place where the important signals arrived. The aim was not to squeeze an entire business into a chat window. It was to see sooner what needed attention and who should handle it. At the time, that place was Slack.
One entrance, different kinds of signals
I created channels for orders, customer support, reports, status, opportunities and bugs. That separation mattered more than my choice of Slack. A new order calls for a different response from an error. Put everything in one stream and the busy items crowd out the urgent ones.
In the orders channel, I could see what was being sold and which photos had arrived. I had outsourced shipping; the person handling it received the relevant notifications so he knew when to act. The channel was therefore more than a dashboard for me. It put information in front of the person doing the work.
For customer questions, I had set up an autoresponder and a self-service area. Requests that still needed a person, such as correcting a wrong address, went to a separate channel. I wrote more about that support setup in Robots Rock. The point here is what happens next: making sure a remaining request does not get lost in an inbox.
What needs immediate action?
The status channel received alerts about the website and the passport-photo checking software. If either went down, I wanted to know quickly so someone could investigate. Bugs had their own channel. The developer could follow those reports and respond when needed.
Reports were different: they were not alarms. The main web statistics were ready for me on Mondays. I used them to decide what to improve on the site. In an opportunities channel, I collected mentions related to passport photos. Sometimes they prompted a product or blog idea. Those signals were interesting, but not urgent. It helps to keep that distinction visible.
Start with the decision, not the integration
If you want a similar overview today, first write down the questions you return to every week. Is something broken? Is a customer waiting? Does an order need shipping? Which figures could change a decision? Only then choose which systems should send notifications and where they should go.
Give each stream an owner and decide what a notification asks that person to do. A status alert without follow-up is noise. So is a report nobody reads. I would start small: include only signals for which you can name a clear next step. Add others when you actually miss them.
My 2017 setup reflected the tools and business I had then. Another app, or even a simple shared overview, could serve the same purpose. The lesson that stayed with me is that centralising information helps only when it is sorted, understandable and actionable.