Turning a shared inbox into an action list Copilot or Claude can actually maintain

Background

Every organisation has one of these - info@, admin@, accounts@, enquiries@ - a shared inbox everyone can see and nobody quite owns. The usual "fix" is a better filing system: more folders, more flags, a colour-coded category for every sender. None of that touches the actual problem, which is that a shared inbox fails on ownership, not organisation. A thread sitting unread for four days isn't lost - it's just nobody's job yet, and a folder doesn't change that.

Asking an AI tool to "summarise the inbox" doesn't fix it either. You get a summary - a paragraph per thread, competently written, and still just prose. You still have to sit there and turn forty lines of summary back into "who does what, by when", which was the actual job you wanted help with in the first place. The fix is to stop asking for a summary and ask for a worklist: a table with an owner and a deadline column, built from the same five-part shape every reusable prompt on this site uses - role, context, inputs, task, constraints.

Setup

The shape every template below follows:

• Role - what kind of triage the model is doing, so it doesn't default to a generic summary.
• Context - what you're pasting in, and what you want back (a table, never a paragraph).
• Inputs - the actual thread content, who's on the team and what they cover, and any deadlines or SLAs that already exist.
• Task - what counts as "actioned", what counts as "needs a decision", what counts as safe to close.
• Constraints - the failure modes to rule out: nobody gets assigned work who isn't on the list, nothing gets marked done that wasn't actually closed.

Daily triage table

For turning a morning's worth of unread threads into a worklist before you've read a single one properly yourself:

You're triaging a shared team inbox into a worklist, not summarising it.

Context: I'll paste subject lines and the first and last message of each
thread. Return a markdown table, one row per thread - nothing else.

Inputs:
- Threads: [PASTE SUBJECT + FIRST MESSAGE + LATEST REPLY, ONE BLOCK PER THREAD]
- Team and what each person covers: [NAME - AREA, NAME - AREA]
- Anything already known to be urgent or time-sensitive: [LIST, OR "NONE FLAGGED"]

Task: for each thread, output columns for Subject | What it actually needs
(one sentence, not a summary of the whole thread) | Suggested owner, from
the team list only | Deadline or "no deadline stated" | Status - New /
Awaiting reply / Needs a decision / Safe to close.

Constraints: never assign a thread to anyone not in the team list - if
nobody obviously owns it, say "unassigned - needs a decision" instead of
guessing. Never mark anything "safe to close" unless the thread's own
content shows the request was actually resolved, not just that nobody
replied recently.

Long thread to single action

For the ten-message back-and-forth that's really about one thing, buried somewhere in the middle:

You're distilling a long email thread into the one action it's actually
asking for.

Context: this thread has drifted - side conversations, CCs added partway
through, maybe a change of mind halfway down. Return the real, current ask
in one sentence, plus who owns it now.

Inputs:
- Full thread, oldest message first: [PASTE]
- Team and what each person covers: [NAME - AREA]

Task: read the whole thread in order, not just the latest message - the
most recent reply is sometimes a side comment, not the live ask. State what
is actually being requested right now, by whom, and what would count as it
being resolved. If the ask changed partway through the thread, say so and
give the current version, not the original one.

Constraints: one sentence for the ask, one line for the owner, one line for
"done looks like". If the thread genuinely doesn't resolve to one clear ask,
say that explicitly rather than inventing one.

Ageing and escalation flag

For catching the threads that have gone quiet for the wrong reason, not the right one:

You're flagging threads that have gone quiet and shouldn't have.

Context: return only the threads that need escalating, with why.

Inputs:
- Threads with their last-activity date: [SUBJECT - LAST ACTIVITY DATE]
- Today's date: [DATE]
- What counts as overdue for this inbox: [e.g. NO REPLY WITHIN 2 WORKING DAYS]

Task: flag any thread past the stated threshold that isn't already marked
resolved, and estimate why it's stalled - waiting on an external reply,
waiting on an internal decision, or just missed. Don't flag anything that's
quiet because it's genuinely finished.

Constraints: don't invent a reason you can't support from the thread
content - "waiting on external reply" only if the last message in the
thread is actually outbound. If you can't tell, say "unclear - needs a
human look" rather than guessing.

Weekly outstanding digest

For the Monday-morning "what's actually still open" view, built from the week's triage tables rather than re-reading everything:

You're building a weekly digest of what's still outstanding in a shared
inbox, for a team that doesn't want to re-read every thread themselves.

Context: I'll paste this week's daily triage tables. Return one combined
table, deduplicated, grouped by owner.

Inputs:
- This week's triage tables: [PASTE]

Task: merge duplicate threads (same subject appearing on more than one
day - keep the latest status only), group by owner, and flag anything that
has appeared "outstanding" for three or more consecutive days as needing
attention regardless of its stated deadline.

Constraints: one row per unique thread in the final table. Never drop a
thread silently - if you're removing a duplicate, keep the most recent
status, not the oldest.