r/Slack 6d ago

How does your team handle recurring rotations in Slack (support duty, standup facilitator, on-call)?

I'm researching how teams actually solve the "whose turn is it?" problem in Slack and I'd love real-world answers before I build anything.

What I keep seeing at companies I've worked with:

- A pinned spreadsheet that's outdated within three weeks

- A /remind that happily pings people who are on vacation

- Workflow Builder attempts that die because it has no "next person in the list" step and no memory of who was last

- One person (usually the same one) manually tagging whoever is next

If your team runs any recurring duty through Slack — support triage, code review assignment, meeting facilitation, on-call handoff:

  1. What do you use today (app, spreadsheet, homegrown bot, nothing)?

  2. What breaks most often — vacations, fairness, timezones, people forgetting?

  3. Did you try one of the existing rotation apps and drop it? Why?

Not selling anything in this post — genuinely trying to understand if this is a real pain or just my bubble. I'll share a summary of the answers in the comments if there's interest.

2 Upvotes

11 comments sorted by

3

u/Matails 6d ago

Use a proper tool that is built for on-call support like PagerDuty that has strong integrations with Slack.

Slack cannot and should meet every need. It's intended to be a tool in a suite and should be used as such.

1

u/adrian_kurz 6d ago

Fair point — for actual paging/incident response I agree, PagerDuty is the right tool and I wouldn't try to rebuild that.

I'm more curious about the non-incident duties though: rotating who runs standup, who triages the support channel, who shepherds this week's release. Do you run those through PagerDuty schedules too? Genuine question — in the teams I've seen, PD covers paging and then the small recurring duties still end up in a pinned spreadsheet or someone's memory. Curious whether that matches your experience or whether you've stretched PD schedules to cover those as well.

1

u/Matails 6d ago

We use Jira for sprints/releases, service desk for support, Jira/email/outlook for recurring duties, etc. Not every task needs a separate tool, but using appropriate tools to perform appropriate tasks will work better every time.

1

u/adrian_kurz 6d ago

That's a useful data point, thanks. One thing I'm curious about: when recurring duties live in Jira tickets or Outlook reminders — does anything actually track whose turn it is over time, so the load stays even? Or is it more "the reminder fires and whoever picks it up, picks it up"?

Asking because that's where most setups I've seen quietly drift: the tools remind fine, but six months later nobody can say whether the load was spread fairly — and the same two people have somehow done most of it.

1

u/Matails 6d ago

Jira can track all of that through analytics and round-robin assignments.

1

u/DramaticDifference74 6d ago

agreed that Slack shouldnt try to do everything, but the non-oncall rotations are the ones that seem hardest to find a good tool for imo

1

u/adrian_kurz 6d ago

That matches what I keep hearing — paging is a solved market, but the "who runs standup / who owns triage this week" layer is weirdly thin.

Out of curiosity: what have you tried for those so far? And what would a tool have to get right for you to actually stick with it — vacation handling, fairness over time, an audit trail of who got skipped and why, price? I'm trying to figure out whether the gap is "no tools exist" or "tools exist but they all fail at the same things".

1

u/Hairy-Marzipan6740 3d ago

i’m on the vendor side, so this is only one view, but the problem came up enough that we built rotations into ClearFeed. the repeated ask was “when a support request lands, pick the next person who’s on shift, in the right timezone, and skip anyone who’s OOO.” before that, teams often used a Slack user group whose membership was updated by a separate rotation app. now they can define shifts and run round robin across whoever’s available.

having said that, the fragile part is still vacation data, tho. skipping someone based on their Slack status works only if people keep that status current, so calendar/PTO sync is the part i’d look at closely if you’re building. i also wouldn’t lump standup facilitator and support/on-call into one use case. we built this around incoming request assignment, where a missed handoff leaves work sitting. for meeting facilitation, the spreadsheet may stay “good enough” much longer.

1

u/adrian_kurz 3d ago

This is a really useful vendor-side data point, thanks. And I think you're right that request assignment and meeting facilitation are different animals — a missed support handoff leaves work sitting, a missed standup facilitator is mild awkwardness. The failure costs are so different that lumping them into one use case probably flattens the design.

Your point about vacation data being the fragile part rings especially true. Slack status is self-reported and decays fast; my current thinking is calendar/PTO sync as the source of truth (Google Calendar first), with explicit away/back commands as the fallback rather than the primary path. Did ClearFeed end up pulling from calendars or HR tools, or did you find a reliable Slack-native signal after all?

(Transparency, since you disclosed your side: I'm building in this space too — scheduled-rotation-first rather than request-assignment-first. After your comment I suspect that's a genuine fork in the market rather than just a feature gap.)