How the reply worklist works
Instead of a chat digest you scroll past and lose your place in, your community manager opens one web page: a clean stack of exactly the posts still waiting on a reply, each with a draft already written, ready to copy. They work the list down to zero and they're done.
A look under the hood: the live page that always shows what's left, the watcher that keeps it fresh, and why this one is an actual app, not a message.
The short version
It's a small web app plus a watcher behind it. The watcher notices the moment fresh activity lands in the community, works out which posts still need a reply, and wakes an agent that drafts a reply for each (that's the Facebook group monitoring engine). The web app shows that as a live worklist: open posts, questions first, each as a card with its draft. Your manager copies a reply, posts it, taps the card done, and it vanishes. When the list is empty, they're finished, no inbox to keep checking.
That's the whole idea. The rest of this page is how the page stays current on its own, and why a page beats a chat message for this.
Three parts behind one page. Fresh activity wakes a watcher, which wakes an agent to draft replies, which fills the live worklist (green). The manager only ever touches the last one.
A page that's always current
The worklist always reflects reality. The instant new posts arrive, a watcher recomputes what's actually open, an agent drafts the replies, and the page updates. Items your manager has handled disappear; new ones appear. There's no stale list and nothing to refresh by hand.
A small watcher checks for fresh community activity continuously. When something lands, it recalculates the open posts, the ones from the last few days that haven't been replied to yet and haven't been dismissed, and hands that list to an agent that writes a draft reply for each. The page reads the latest drafts and the current done-state every time it loads, so what the manager sees is always the true state of the queue, not a snapshot from this morning. If the underlying data ever can't be read, the page shows a clean 'being prepared' message instead of anything broken or wrong.
Every post, one tap from handled
Each open post is a card: who posted, how long ago, the post itself, and a highlighted draft reply ready to paste. One tap copies the reply, opens the real post, or marks it handled and fades it away. Questions are sorted to the top, and a progress bar fills as the list empties.
The design is built for momentum. The manager goes down the stack, copies a draft, posts it on the real thread (one button both opens the post and copies the reply, so they land ready to paste), and marks it done; the card fades and won't come back. Customer-service posts are visually flagged so they get the right care. When the last card clears, a small celebration confirms the list is at zero. It turns 'read a long digest and try to keep your place' into 'work a short list to done.'
The unit of work: an open post becomes a card with a ready draft (green), and one tap takes it off the list for good. No re-reading, no losing your place.
A chat digest is something you read. This is something you work, to zero, and then close the tab.
Why a page, not a message
A chat digest is a flat dump with no memory of what you've handled; a spreadsheet has no real actions. A web app gives you live state, one-tap actions wired to real outcomes, the right order, and visible progress, on any device, behind a single private link.
The app owns one simple source of truth: for each post, is it still open, or has it been replied to or dismissed. That's what lets handled items vanish instantly and the list always tell the truth. The reply text is the only part an AI writes; the ordering, the hiding of done items, the progress, and the page itself are plain, predictable code. So it's fast, it's reliable, and it does exactly one job extremely well: show the manager what's left, in order, with the words already written.