Asyncbot vs spreadsheets, calendars & Slack user groups

Spreadsheets

The classic approach. A Google Sheet with names down the left, dates across the top, and a color code that three people understand.

Where it works

• Small team (3-5 people), one rotation
• Everyone is full-time, same timezone
• Someone reliable remembers to update it

Where it breaks

• No notifications. The spreadsheet doesn't tell anyone the rotation changed. People have to remember to check it.
• Manual everything. Every swap, every holiday, every new team member is a manual edit. And edits don't notify anyone.
• No conflict detection. Double-book someone? The spreadsheet won't warn you.
• Stale data. Someone goes on vacation and forgets to update the sheet. Now the "on-call" person isn't actually available.
• Formula fragility. Complex rotation formulas break silently. The person who wrote them left six months ago.
• No audit trail. Something went wrong last Tuesday — who was on call? Scroll through the sheet and hope nobody edited it since.

The core problem: a spreadsheet tracks a plan. It doesn't track reality. When plans change — and they always do — the spreadsheet and reality diverge.

Google Calendar

A step up from spreadsheets. Create events like "On-call: Alice" and share the calendar with the team. At least people get notifications.

Where it works

• Simple weekly rotation with no exceptions
• Everyone uses Google Workspace
• You need a visual timeline (Calendar is good at that)

Where it breaks

• No custom recurrence. Google Calendar doesn't support "every 3rd week" or "6-day rotation" natively. Users on Google's support forums have been asking for this for years.
• Max 5 side-by-side. Scheduling more than 5 people side-by-side isn't supported. For larger teams, you can't see the full picture.
• No availability tracking. Calendar knows when events happen. It doesn't know if someone is actually available, sick, or on vacation.
• Work-life bleed. Shift notifications land on personal Google accounts, buzzing during vacations and family time.
• No Slack integration. Google Calendar has no native way to update a Slack user group when the rotation changes. You end up building Zapier glue or updating manually — which defeats the purpose.

Google Calendar was designed for meetings, not rotations. The data model doesn't support rotation concepts like "skip this person, they're out."

Slack user groups

Create @on-call as a Slack user group. Anyone in the workspace can type @on-call to reach whoever is on duty. Simple, Slack-native, no extra tools.

Where it works

• Tiny team, one rotation
• Someone (usually the team lead) reliably updates the user group
• No OOO or part-time complexity

Where it breaks

• Entirely manual. Someone must remember to update the user group at every rotation boundary. No reminders, no automation, no safety net.
• The "forgot to update" failure. This is guaranteed to happen. The rotation changes, nobody updates @on-call, and last week's person gets pinged.
• No OOO awareness. If the on-call person is sick, the user group still points to them. There's no way to handle this automatically.
• No history. Who was on call last Tuesday? No way to find out. User groups only show current membership.
• Admin bottleneck. On most Slack plans, only admins can modify user groups. The team can't self-manage their own rotation.
• No escalation. @on-call someone and they don't respond? Nothing happens.

User groups solve the discovery problem ("who's on duty?") but create a reliability problem ("is that information current?").

Slack Workflow Builder

Some teams try to automate rotations with Slack's Workflow Builder — scheduled messages, forms for swap requests, that kind of thing.

Where it breaks

• Can't update user groups. Workflow Builder cannot programmatically change Slack user group membership. That's the one thing you need, and it's not available.
• No state. Workflows are stateless. There's no concept of "whose turn is it" or "who was last."
• Linear only. No branching logic. No "if this person is OOO, pick the next one."
• Paid plans only. Workflow Builder isn't available on Slack's free tier.

Teams usually try Workflow Builder because it's already in Slack, discover it can't actually automate the rotation, and end up adding a third-party app anyway.

Internal bots and scripts

The DIY option. A senior engineer builds a bot over a weekend: a simple round-robin script that posts to Slack. "How hard can it be?"

Where it breaks

• Bus factor of 1. The person who built it is the only one who understands it. When they leave, the bot becomes a black box.
• Slack API changes. Slack deprecated legacy custom bots in March 2025. Classic apps follow in November 2026. Every API change requires someone to update the bot.
• Edge cases accumulate. Holidays, timezones, OOO, part-timers, temporary team members. Each edge case is another if statement the original developer didn't plan for.
• Hosting and maintenance. Someone has to keep the server running, manage SSL certs, handle token rotation, monitor for failures. Invisible work until it breaks.

The initial build is the easy part. Maintenance is where it gets expensive. Custom Slack bots range from modest to significant ongoing investment — and that's for a "simple" rotation tool.

When manual works

Don't fix what isn't broken. Manual approaches work fine when:

• You have 2-5 people and one rotation
• Everyone is full-time, same timezone
• One person reliably manages the schedule
• You don't need history or fairness tracking

If that's your team, you don't need Asyncbot or any other tool. Save the $29/month.

When to switch

The signals are usually obvious:

• "Who's on call?" gets asked more than once a week
• Someone was skipped because they were OOO and nobody noticed
• The same two people keep ending up on duty
• You're managing more than one rotation
• The spreadsheet/calendar/user group hasn't been updated in a week
• Your internal bot broke and the person who built it is on vacation

Comparison at a glance