A webhook for Slack to ground work on real signals

In part one we covered the mechanics of sending a webhook to Slack, the delivery guarantees, the follow-up tasks, and the reporting that make it dependable. Getting an event to appear in a channel turns out to be the easy half. The harder and more interesting work is deciding which events earn a place in front of your team, who is expected to do something when one arrives, and how you keep the volume low enough that people keep reading. That is the difference between a channel full of noise everyone has muted and a genuine nervous system for the company.

This piece is about that second half. It is less about payloads and more about judgment, the kind you develop after living with event notifications for a while and noticing what helps and what people quietly tune out.

Put events where the team already works

The instinct when you first automate something is to build a place for it. A new dashboard, a new tool, a new tab that everyone is supposed to check. The trouble is that every new surface competes for attention that was already fully spoken for, and the honest outcome is that most of these places go unread within a month or two.

Slack wins here for an unglamorous reason. Your team is already there all day. An event that shows up in a channel they have open is seen without anyone changing a habit or remembering a login. When a payment posts into the finance channel, the person who cares is looking at it within minutes, in the same window where they were already talking about the month's numbers. The event and the conversation about the event live in one continuous place, which is what makes the record worth keeping. Surfacing a signal where decisions already happen is worth far more than surfacing it somewhere technically tidier that nobody visits.

Design the noise, not only the signal

The fastest way to kill an event channel is to send everything to it. A stream that fires forty times an hour trains people to ignore it, and once they have learned to ignore it, the two messages a day that genuinely mattered are lost along with the rest. Good event design is mostly about restraint.

A few habits keep a channel readable. Send high-frequency, low-individual-value events in batches, so the channel receives one summary every few hours rather than a constant trickle. Reserve one-message-per-event for the streams where each occurrence deserves a human look, a new enterprise trial or a failed production deploy, and let the routine volume roll up into a digest. Route different event types to different channels rather than pooling them, so the people watching payments are not wading through deploy logs to find them. When a stream is about a running total more than any single event, a periodic report on a schedule tells the story better than the individual messages ever could. The goal throughout is that anyone glancing at the channel trusts that what they are seeing is worth their attention, because you have already done the filtering for them.

Turn signals into ownership

A notification that everyone sees and nobody owns is only a slightly better version of the event nobody saw. The moment that matters is the handoff from noticing to acting, and that handoff needs a name attached to it.

This is where an event stops being an alert and becomes work. A relayed event can carry a task with it, assigned to a specific person or left open for whoever is free to claim, so the follow-up has an owner from the instant it appears. A scheduled cancellation is a good example. As a bare message it prompts a vague collective concern that fades by lunch. As a message with a task assigned to someone in customer care, with a clear deadline before the billing period ends, it becomes a reach-out that actually happens. The event triggered a response because the response had somewhere to live and someone responsible for it.

Build the habit across the org

Rolling this out well looks less like a launch and more like a series of small, obvious wins. Trying to pipe every system into Slack on day one produces exactly the noise problem described above, and the team's first impression sets whether they trust the channels at all.

Start with a single high-signal event and a single channel. Payments and new signups are usually the best openers, because everyone already agrees they matter and the value is immediate. Let that run until the channel has clearly earned its place, then add the next stream. Give each channel a reason to exist and a person or group who watches it, so ownership is understood rather than assumed. As the habit settles, the reporting takes care of itself, since the Month in Review charts are built from the same events you are already relaying. Within a few weeks the pattern usually reverses on its own, and people start asking for events to be added rather than needing to be sold on them, which is the sign it has become genuine infrastructure.

Viably as event-to-Slack infrastructure

Plenty of tools can move an event from one place to another. General-purpose automation platforms like Zapier, Make, and n8n exist precisely for that, and they are genuinely good at connecting a long list of applications. What they leave to you is everything that happens after the event reaches Slack. You build the message format, you decide how retries behave, you assemble any batching or reporting yourself, and you own the workflow that keeps it all running as your needs change.

Viably takes the opposite starting point. The relay is the product, not a step you wire together. The formatting into clean Block Kit cards, the retries with backoff, the de-duplication, the batching and periodic digests, the reporting charts, the delivery logs, and the follow-up tasks are all there from the first endpoint, set up in Slack from a slash command, and available on the free plan. You get event-to-Slack delivery treated as infrastructure rather than as a workflow you maintain. We wrote a fuller side-by-side of the two approaches in Viably versus Zapier, Make, and n8n if you are weighing them directly.

The practical guides sit in the docs. The Webhook Relay reference covers the generic payload and every event type, and Stripe to Slack walks through payments from the first webhook to the periodic revenue report.

The shape of a team that runs this way

When it works, the change is quiet. Fewer surprises surface in the weekly review because the surprising things already showed up when they happened. Follow-ups have owners instead of hoping someone remembers. The record of what occurred and what the team did about it lives in one place, readable weeks later without asking anyone to reconstruct it. That is what an event-driven workforce feels like from the inside, and it starts with a single webhook posting to a single channel.

If you have not set one up yet, add Viably to Slack, run /webhook-relay, and point your first event source at it. Then come back to part one when you want the full picture of what the relay handles for you underneath.