We got the rota notifications wrong. Here's what we learned.

The problem we thought we were solving

Before Build 9, managing service unit rosters was a Sunday-morning scramble. Duty coordinators relied on WhatsApp chains and phone calls to confirm who was showing up. People didn't see their assignments until the last minute. Substitutions happened chaotically. We looked at the data and thought the answer was obvious: push notifications every time something changed.

A swap request? Notification. A new roster posted? Notification. Someone marked themselves unavailable? Notification. We reasoned that more information, delivered faster, had to be better. The feature shipped with notification settings buried three menus deep, in a section most users never opened.

We were wrong. Not about the need to notify people. About what notification actually means in the context of a busy church running eight different service units.

What the real coordinators were telling us

The feedback pattern was consistent across our early adopters, from RCCG branches to DLCF congregations to House on the Rock. The coordinators didn't mind getting one alert when a roster dropped. They minded getting pinged twelve times a day because someone in sound requested Thursday off, then changed it back, then requested it again. They minded their phones lighting up during service.

One finance pastor put it plainly: 'I installed your app to manage giving and track our members through baptism and into mature service. My duty coordinator doesn't need her phone exploding every time someone swaps a Wednesday.' That clarity was humbling. We'd optimised for system events, not for human attention.

The real insight came when we looked at actual usage. Coordinators were swiping away notifications within seconds. Some had already turned them off in iOS settings. A few had asked us to disable them entirely. The feature was creating noise instead of reducing friction.

The gap between push and purpose

Here's what we missed: a notification is an interruption. Useful interruptions are rare. They tell you something that requires your immediate action or attention. A swap request submitted at 9 p.m. on a Thursday doesn't require anyone's immediate action unless the service is the next morning. Even then, it's the coordinator's job to manage it, not everyone on the roster.

We'd built the notifications as a broadcast system when we should have built them as a routing system. Swap requests should go to the coordinator, not to all eight people in the backup pool. New rosters should be available when someone logs in to check their schedule, not pushed at them proactively. Urgent conflicts - someone dropping out twelve hours before a service - those deserve a ping. Maybe.

The other thing we underestimated was cultural rhythm. In charismatic churches, especially across the UK and West Africa where most of our users are, midweek is often quieter than we anticipated. A Wednesday notification at 3 p.m. lands differently than a Saturday one at 9 a.m. Coordinators are juggling eight units at once - worship, ushering, children's church, media, security, intercession, protocol, refreshments - plus the core business of membership journey tracking and pastoral follow-up. Every notification is competing for cognitive real estate.

What Build 10 is doing differently

We're pulling back. First, we're making notification settings visible and sensible - not hidden. Coordinators should see four clear options: all changes, critical only (service-day conflicts), roster releases only, or silent mode. The default is roster releases and critical conflicts, not every event.

Second, we're changing who gets notified. Swap requests go to the coordinator and the person being asked to cover, not to the whole unit. Roster posts go live in the app first; a summary notification follows for people with critical role changes. New check-in deadlines get flagged only if you're assigned to that service.

Third, we're adding a summary digest. Once a week, Sunday evening, coordinators can opt in to a single message: which units are fully staffed, where gaps exist, upcoming conflicts in the next seven days. That's one notification instead of thirty scattered ones.

We're also building into the Request to Purchase pipeline a lesson we should have applied here earlier. When you're managing approvals across resident pastor, pastor in charge, and finance pastor, you don't notify everyone of every stage. You notify the next person in the chain. The same principle applies to rosters.

Why this matters beyond notifications

This wasn't really about push notifications. It was about respecting the attention of people doing hard work. A duty coordinator managing eight service units is making dozens of micro-decisions every week. They're also tracking visitors through the establishment ladder, working through pastoral follow-up queues, managing a four-stage RTP chain, and helping their pastor monitor pipeline health.

Every notification we send either makes that job easier or it makes it harder. There's no neutral. We shipped Build 9 thinking we were doing the first. Our users politely told us we'd done the second.

The lesson we're carrying forward is this: good tools don't interrupt more. They interrupt less, and when they do, they interrupt with something that matters. For a duty coordinator in a 500-member branch running sophisticated rosters across eight units, that's a high bar.