Process Discovery
Part of Process mining and operational evidence
Identifying repeated handoffs in a process
Trace ownership changes by case, count returns and check why work crossed the same team boundary more than once.
To identify repeated handoffs, follow each case as responsibility moves between roles or teams. Count transfers across a defined boundary and returns to a previous owner. A repeated activity on a process map is a lead, but it does not prove that ownership changed or that the repetition was wasteful.
Steps to Identify and Investigate Repeated Handoffs
- Select a case type and define what constitutes a handoffUse formal dispatch records, not just messaging
- Track ownership changes by case over timeList owners in chronological order
- Count transfers and returns across teamsDistinguish intra-team repeats from cross-team returns
- Investigate why returns occurredReview cases with sending and receiving teams; assess missing info, review needs, or wrong routing
- Record required improvementsDocument input gaps, sender/recipient roles, acceptance signals, and return rules
Define a transfer of responsibility
Choose a case type and decide what constitutes a handoff. Intake assigning a request to a reviewer may transfer responsibility; copying the reviewer into a message may not. Identify the records that establish dispatch and acceptance, if both are available.
A log may contain a resource or department attribute; check whether it records the person who acted, the team owning the queue or a technical identity. The field's meaning may differ between systems. Where there is no reliable ownership record, use source cases or a bounded manual review instead of inferring transfers from adjacent activity names.
Valid vs. Invalid Indicators of Responsibility Transfer
- Valid transfer indicator
- Recorded assignment to a reviewer or queue ownership change
- Invalid transfer indicator
- Copying a reviewer in a message without formal dispatch
- Reliable ownership source
- Person who acted, team owning the queue, or technical identity
- Unreliable inference
- Assuming handoff from adjacent activity names only
Count returns by case
For each case, list recorded owners in time order. Mark each transfer from team A to team B and any later return to A. Keep repeated events within one team separate from cross-team returns. Report both the number of cases with a return and the total number of returns: one case can contribute several moves.
| Measure | What it shows | Qualification |
|---|---|---|
| Cases with at least one return | How widely the pattern occurs | Define the eligible case population |
| Returns per affected case | Whether affected cases move repeatedly | Does not explain the reason |
| Dispatch-to-acceptance interval | Where time passed before recorded acceptance | Requires reliable events at both ends; may include legitimate waiting |
| Team pairs involved | Which interface to review | Does not measure individual performance |
Segment results by request type, route and outcome when those differences matter. Show open cases explicitly. A high count on a busy route may be ordinary; a rarer return may matter more when it blocks an important result.
Key Metrics for Tracking Repeated Handoffs
- Cases with at least one return
- High frequency indicates widespread pattern
- Returns per affected case
- Measures repetition intensity within cases
- Dispatch-to-acceptance interval
- Time between handoff and acceptance (if reliable)
- Team pairs involved
- Identifies most frequent interface points
Pros and Cons of Using Automated Process Mining for Handoff Analysis
- ProsEnables scalable tracking of ownership changes across large volumes of cases
- ConsMay misinterpret informal actions (e.g., copying someone) as formal handoffs if data quality is poor
- ProsHelps identify high-impact interfaces where repeated returns block outcomes
- ConsCannot determine intent behind returns—requires manual investigation
Investigate what the return achieved
Review representative cases with sending and receiving teams. Ask whether information was missing, independent review was required, the wrong team was chosen, or the case changed after the first decision. The transition count cannot answer those questions.
For a hypothetical purchase request, a return from procurement to the requester may be the intended way to obtain a missing specification. Repeated returns for the same missing field could prompt a review of the intake question. A second procurement review after a material change may be necessary. Keep these routes distinct before removing a handoff.
Record the interface that needs attention: required input, sending owner, accepting owner, acceptance signal and rule for returning work. If the route changes, compare later returns with the quality of completed outcomes.
