Separate waiting from blocked
Use at least five states:
- Team preparing: the request is accepted but has not been sent.
- Waiting on client: a complete, dated request is in the agreed channel.
- Blocked internally: the client responded, but the team needs a decision or action.
- Escalated: an approved threshold passed and the ordinary owner cannot close the item.
- Closed: the outcome was accepted, cancelled, or made irrelevant, with evidence.
Without this separation, a dashboard can label a client “late” while the next action actually belongs to the team. That makes automated pressure easier and operational learning harder.
Give each live item one accountable owner
Record contributors separately, but name one person accountable for the next state transition. Ownership does not mean that person must do every task. It means they can answer:
- What are we waiting for?
- When did the current clock start?
- What action happens next?
- Who may change the due date, channel, priority, or outcome?
- What will count as closed?
A queue without this owner becomes a shared view of unowned work.
Define the clock from an observable event
“Follow up after three days” is incomplete. Three business or calendar days? Since the first email, the last complete request, the promised response date, or the last client message?
For each state, write:
entry event → clock rule → normal next action → escalation threshold → owner
Microsoft's current manual-task workflow documentation shows one product pattern: an overdue task can follow a configured escalation path. That proves the configuration concept exists in that system; it does not select the correct threshold, owner, or channel for your service.
Make escalation a decision, not a louder reminder
An escalation should change something. The escalation owner might:
- choose a different approved contact channel;
- split an overly broad request;
- provide missing context;
- accept a revised date;
- pause dependent work;
- cancel the request; or
- involve a business owner for a defined exception.
If escalation only sends the same message more often, the map has encoded noise rather than a recovery path. Preserve client communication preferences and avoid exposing sensitive work in notifications.
Walk real items before configuring software
Take ten recent stale items and trace each from entry to closure. Mark every case where the representative map fails. Look especially for invisible work in personal inboxes, meetings, chat, and spreadsheets.
Then choose CRM fields and automations from the corrected map:
- state;
- accountable owner;
- current entry time or promised date;
- next action and due time;
- escalation owner and reason;
- communication channel; and
- closure outcome with evidence link.
Do not import private message bodies merely to make the dashboard look complete. Store only the data needed for coordination and approved audit.
Acceptance rule
The workflow is ready to automate when different operators classify the same sample items consistently, every open state has one next-action owner, each clock has an observable start, escalation changes a decision or resource, and closure can be proven without searching a private inbox.
The checked-in MulanDream artifact is a reusable representative map. A real team should replace its assumptions through a walkthrough before treating it as operating policy.