Audit a shared inbox for duplicate work

Export the thread list with timestamps

Begin with a dated export of the shared inbox, including sender, recipient, subject, labels, assignee, and the first and last message times. Export the thread list rather than a folder of individual messages, because duplicates usually appear across a conversation. Store the export read-only so the audit cannot change the mailbox. Record the export window and the time zone.

If the inbox tool cannot export the needed fields, take a consistent screenshot set and record the limitation. Do not rely on memory or a few open tabs. The audit needs the same evidence a reviewer would use to reconstruct the day. A partial export can still be useful if the gap is stated.

Include the sent folder and any shared alias that can send on behalf of the team. A duplicate may never appear in the inbox if one owner replied from a different address. Note the alias in the export so the reviewer can match the sender to a person. The address list is part of the routing evidence.

Group messages by customer and topic

Group threads by customer and by the underlying request, not by subject line. Subject lines drift when people reply or forward, so the same request can appear under three different labels. Use the customer domain, the order number, or the case key when one exists. For each group, count the distinct outcomes requested.

Mark the groups that received more than one substantive reply from different owners. A short acknowledgement from a second person is not a duplicate if the first owner was waiting. Look for replies that answer the same question differently. Those are the threads that create confusion for the customer.

Record the first and last reply in each group so the review can see whether the second answer corrected the first or contradicted it. A correction is less damaging than a contradiction, but both waste the customer's attention. Note whether the customer replied after the duplicate and which answer they followed. That detail shows the real cost.

Find replies sent from more than one owner

Compare the sender list with the assignee field for each thread. When two people reply without a handoff note, the customer sees two voices and may act on the wrong one. Record the time gap between the replies and whether either owner saw the other's message. A gap under five minutes often means both were working the same arrival.

Check the sent folder rather than only the inbox, because a duplicate may be invisible from the receiving side. Look for internal notes that say someone else is handling the request. If the note exists but the reply still went out, the problem is the handoff rule rather than the people. Read the timestamps on those notes to see whether the second owner replied before or after the claim.

Check whether the second reply was sent with a different template or signature. A different template often means the second owner did not see the first reply, while the same template may mean the team is copying an old response. The detail helps distinguish a visibility problem from a training problem. Record it beside the thread.

Check internal notes for conflicting instructions

Read the internal notes on the duplicate threads and mark where the instructions conflict. One note may say the client wants a call, while another says the client prefers email. Record the source and date of each instruction. Conflicting notes are a sign that the client's preferences are not stored in one place.

Look for notes that were copied from an older thread without a date. An instruction without a date cannot be ranked against a newer one. Ask the owner to confirm the current preference and update the source record. The audit should fix the record, not just flag the thread.

Fix routing rules before adding staff

If duplicates cluster around one label or one client, fix the routing rule before hiring another assistant. A rule that sends every message to a general queue guarantees that two people will eventually open the same request. Assign a primary owner by client, topic, or time window, and write the handoff trigger. Then test the rule with a sample of live messages.

Keep one shared view for unassigned work and require an owner before a reply is sent. Make the assignment visible in the thread so the second person can see it. If the tool cannot show ownership, use a short internal note with the owner and the time. The fix should reduce duplicate replies without slowing the first response.

Give the new routing rule a short trial before you change the whole inbox. Apply it to one client or one label and compare the duplicate rate with the rest of the queue. A small trial limits the damage if the rule sends work to the wrong owner. Expand it only after the trial shows a clear improvement.

Recheck a sample after the routing change

Wait one full coverage cycle, then export the same fields and compare the duplicate rate. Check whether the same customers appear again and whether the replies now carry one owner. Read a sample of threads rather than trusting the count alone. A lower count can hide a new pattern of silent handoffs.

Record the before-and-after evidence, the rule change, and the remaining exceptions. Share the result with the assistants who work the inbox, because they will notice the edge cases the report misses. Set a date for the next check. Duplicate work is a process symptom, and the audit is only useful if it changes the process.