A transfer is not always a failure; it can be the correct move to a specialist. The problem is unnecessary, repeated, or context-free handoff.
Define the event before the rate
AWS documentation distinguishes transferred contacts, agent transfers, internal transfers, external transfers, and queue transfers. Your operation should also separate initial routing, a consultation that keeps ownership, and an actual transfer. Otherwise, a better automated flow may look like worse human behaviour.
Transferred-contact rate = eligible contacts with at least one transfer ÷ eligible handled contacts. Transfers per contact = total transfer events ÷ eligible contacts. The first shows reach; the second reveals repeated handoffs.
A good transfer preserves accountability
The handoff is appropriate when the destination has the competence, context, and authority to finish. It should include a reason, note or summary, next owner, and acknowledgement. The customer should not reconstruct the case.
Also track returns to the previous queue or contacts with three or more handoffs. These events reveal ping-pong. Do not set a universal target of zero; complex cases and legitimate escalation need collaboration.
| Event | Count in the main transfer rate? | Record |
|---|---|---|
| Automated initial routing | Keep separate | Flow and entry queue |
| Consultation without ownership change | No | Collaboration event |
| Agent or queue handoff | Yes | Origin, destination, reason, and time |
| External escalation | Keep separate | Destination, acceptance, and expected return |
| Return to previous queue | Yes and flag as rework | Full owner sequence |
Read transfer with routing and resolution
An increase in transfers with lower repeat contact may indicate better specialisation. A simultaneous increase in transfers, time, and complaints suggests friction. Segment by reason, origin queue, destination, time, and outcome.
AWS documents how queue and availability metrics can support routing decisions. Use this as an example of useful data, not an automatic rule: momentary capacity does not replace competence, privacy, or decision authority.
Write the metric contract before comparing results
Record the name, management question, numerator, denominator, start event, end event, observation window, calendar, exclusions, and owner. If two people cannot reproduce the same result from the same cases, the definition is not ready.
Keep the formula version with the report. A change in status, channel, business hours, or reopen policy can break historical comparability. Preserve the previous series or mark the break clearly whenever the rule changes.
- A management question written in one sentence
- An explicit numerator and denominator
- Documented eligible population and exclusions
- An observation window long enough for the measure to mature
- Segments for channel, queue, reason, and period
- A conversation sample that explains the change
- A named owner, expected action, and next review date
How to apply this with Signaldesk without claiming more than the data proves
In Signaldesk, use queues, owners, history, states, and conversation context as the operating record. Consistent fields let a manager trace a number back to the conversations behind it. AI can suggest reasons, summarise history, and flag review candidates, but people should validate classifications and decisions that affect customers or staff.
Confirm which events, reports, and exports are available in your workspace before making a formula depend on them. If a calculation needs financial cost, cohorts, or an external rule, combine the operating record with the right source and document the reconciliation. The aim is traceability, not artificial precision.
A four-week pilot
In week one, freeze definitions and establish a baseline. In week two, inspect a conversation sample and correct events or states. In week three, choose one priority cause and test a small change. In week four, compare the same segment, record side effects, and decide whether to keep, adjust, or remove the change. Four weeks is not a promised outcome; it is a practical period for validating the method and the team’s ability to act.