How to Use Slack Notification Sounds to Improve Team Innovation in Remote Work
We spent about a year treating notification sounds as something worth experimenting with rather than something to switch off. A few of those experiments changed how the team works. Most of them did not. This is the honest version, including the parts that were a bad idea.
Where we started
Eight people, fully remote, three time zones. Everyone had Slack's default knock sound on, and about half the team had muted Slack entirely because the knock fired for everything. That is the actual failure mode: a notification system with one sound and no priority collapses into either constant interruption or total silence. Nobody picks the middle.
Experiment 1: a distinct sound per channel
The first thing we tried was the obvious thing. Every channel got its own sound. We had eleven active channels, so eleven sounds.
This was a bad idea and we knew it inside two weeks. Nobody can learn eleven audio cues, and the ones people did learn were the wrong ones. Two engineers reported they had started recognising #random because it fired most often, which is exactly backwards. The sound budget got spent on the least important channel.
The lesson was that the number of sounds a person can actually distinguish while concentrating on something else is small. Our working estimate now is four. Beyond that you are just adding noise with extra steps.
Experiment 2: sounds tied to urgency, not location
We rebuilt around three tiers instead of eleven channels.
- A short chime for direct messages and
@mentions from anyone on the team.
- A lower, two-note sound for anything in
#prod-*, matched with a wildcard so new incident channels were covered automatically.
- Silence for everything else, checked on a schedule rather than announced.
This one stuck, and it is still what most of the team runs. The wildcard mattered more than we expected. Before it, every new #prod-payments-outage channel arrived with no sound rule and got missed until someone noticed manually.
Experiment 3: a "shipped" sound for deploys
We gave successful deploy notifications a bright three-note sound. The idea was that hearing the team ship things would feel good.
It did, for about a month. Then deploy frequency went up, the sound fired eleven or twelve times a day, and it turned into wallpaper. Worse, because it was pleasant and frequent, people stopped reacting to sounds in general. A cheerful sound that fires constantly trains you to ignore your own alerts.
We deleted it. If you want an audible signal for something good, tie it to an event that happens weekly, not hourly.
Experiment 4: personalised sounds per teammate
Assigning each person their own sound sounded useful for a small team. In practice only two of them ever got learned: our manager's, and the one belonging to whoever was on call.
That is not a failure exactly, it is a narrower success than we planned. We kept two person-specific rules and dropped the rest. If a rule exists to make you react differently, and you do not react differently, the rule is decoration.
What we would skip next time
Skip the taxonomy phase. We spent two afternoons in a doc mapping channels to sound categories before anyone installed anything. All of that was thrown out after the first experiment. Start with two rules, live with them for a fortnight, and add a third only when you can name the specific alert you keep missing.
Skip the volume calibration spreadsheet as well. One of us set per-rule volumes to precise percentages based on how far each sound needed to carry. Nobody's room stays the same for a year. Setting the incident sound obviously louder than the rest and leaving it alone got the same result in ninety seconds.
Skip team-wide standardisation, too. We briefly tried to get everyone on identical rules so we could talk about sounds in shared terms. People's jobs are different. The support lead needs a rule the backend team has no use for. Shared vocabulary is fine; shared configuration was overhead.
Running the experiments
Chirpy is what we used for all of this. It is a native macOS menu bar app that reads notifications through the Accessibility API and plays a sound based on rules you write, so nothing is connected to your Slack account and no message content leaves your Mac. Setup is install, grant Accessibility permission, set Slack's own notification sound to None, then write your rules. Rules match on app, channel, person, or keyword, with wildcards, priority ordering, and per-rule volume.
Try two rules for a week and delete anything you stopped noticing. The guides cover the wildcard and priority syntax if you want to skip the part where we learned it the hard way.