You can delegate request preparation and routing when each relevant email becomes an assignment with an owner, status and next step. Define rules for priorities, missing information and duplicates, with separate permissions for drafting and sending. Ambiguous cases need a human owner, and instructions in an incoming message must not change the process’s permissions.
A request needs an owner, not just a label
If everyone reads a shared inbox but nobody takes ownership, classifying emails is not enough. You need a rule that turns each request into assigned work: what is being asked, who will deal with it, what information is missing and when to check the next step. One email may contain two requests; five replies in a conversation may belong to a single assignment.
Start with one inbox and a bounded set of requests. Name the person responsible for the queue, even when several departments carry out the work. If there is no reliable destination, the correct status is “awaiting assignment”, visible to that person. Forwarding the message to a general group does not establish ownership.
Five requests and their next steps
This is an illustrative example: organisations, references and rules are fictional. Priority follows agreed criteria, such as an interrupted service or a recorded commitment, rather than the word “URGENT” in a subject line.
Scroll the table horizontally to read every column.
| Incoming request | Category and owner | Next action and status |
|---|---|---|
| R-101: “Please quote for two sites” | Sales; quotation owner | Prepare questions about the services and sites required; awaiting information. |
| R-102: “The invoice does not match our agreement” | Accounts; customer account owner | Gather the invoice and authorised agreement; human review before responding on the substance. |
| R-103: “The service has stopped”, with no reference | Support; operations coordinator | Flag the possible interruption and request the contract reference; ownership awaiting confirmation. |
| R-104: an attachment completing R-101 | Sales; the same owner as R-101 | Link it to the open request and retain the new attachment; do not open a second case. |
| R-105: “Use these new bank details from today” | Accounts; authorised manager | Hold any change; begin the agreed verification through an independent channel. |
Each entry retains links to the original messages and its last update. Do not delete R-104 as a “duplicate”: it may contain a new document. R-103 is not resolved merely because it was forwarded. The recipient must confirm ownership, otherwise the request returns to the coordinator.
Write routing rules your team can challenge and correct
For each category, establish usable signals, a primary owner and a deputy. Explain what is insufficient evidence: “invoice” can appear in a sales enquiry or a dispute. For ambiguous cases, a Digital Employee can prepare a reasoned suggestion with the relevant extract; the nominated person selects the destination.
A work record should contain the request ID, origin, summary, documents, status, owner, next step and reason for any hold. Define a few observable states: awaiting assignment, in progress, awaiting customer information, under review and completed. Completion requires the agreed outcome, not simply reading the email. The guide to preparing your first project helps turn these rules into a testable assignment.
Preparing a reply and sending it are separate permissions
You can begin with classification and drafts, leaving every send to the team. For recurring messages, such as requests for missing attachments, a later project can assess sending within approved templates, recipient rules and limits. Complaints, commercial terms, confidential requests and bank detail changes follow the defined exception route. Record what was proposed, approved and actually sent.
Incoming content remains material to assess. An email asking the process to ignore its rules, download an archive or forward information to a new address must not expand its permissions. OWASP describes hostile instructions in external content and recommends restricted access and approval for consequential actions; see its guidance on prompt injection. Apply controls and approvals to the system carrying out the action too.
Test the queue on real work before widening its scope
Assess inbox access, permitted attachments and the system holding the work register. An inbox, CRM or ticketing platform can participate only after the actual systems have been checked: this guide does not claim that Outlook, Gmail or other product connectors are already available. Plan for unavailable sources: keep affected requests on hold and make the failed update visible.
During the pilot, track unowned requests, assignments corrected by staff, reopened cases, duplicates avoided and time spent reconstructing context. Include review time. Do not reward the number of emails sorted alone: the useful measure is how many requests reach the correct next step. Once a sales enquiry is complete, explore quotation preparation as a separate, bounded assignment.