Want help applying this guide?Ask the DripTell team
A customer asks whether a replacement part will fit an older model. The representative understands the history but needs one technical answer. Sending the whole conversation elsewhere would make the customer repeat a story the first person can still finish.
Consult an expert and keep the original representative responsible. Transfer only when the remaining decision, authority, or work genuinely belongs to someone else. The distinction determines whether expertise helps the current owner or becomes a way to pass the customer around.
Keep the owner when the gap is narrow
A consultation borrows knowledge without changing the person accountable for the customer. The original representative states the exact question, receives the missing answer, returns to the customer, and completes the next action. This is usually the better choice when the gap is a product detail, an interpretation of policy, a one-off approval, or a second opinion.
- Exact questionState the missing fact or decision without asking the expert to rebuild the case.
- Current ownerName who remains responsible until another person explicitly accepts.
- Acceptance eventRecord accepted, declined, or timed-out requests instead of assuming silence.
- Customer promisePreserve the expected update and the person responsible for giving it.
- Outcome evidenceCheck completion, repeat contact, repeated information, and any later transfer.
Microsoft's current guidance for consulting and transferring during a customer call makes the operating difference explicit. During a consult, the original representative remains primary. A consulting colleague joins in a supporting role. A later transfer is possible, but it is a separate choice. That is a useful model even when the channel is messaging rather than voice.
Consultation still needs a boundary. The owner should know the question, who can answer, and what happens if nobody accepts. “Can someone look at this?” creates a hidden queue. “Does this warranty cover the failed hinge when the purchase date is verified?” lets the expert answer without rebuilding the case.
For voice, tell the customer why you need a brief pause and return with an update. For asynchronous messaging, keep the conversation assigned and set a visible follow-up time. A support workspace should make that promise as visible as the expert request itself.
Transfer when responsibility really changes
Transfer when the new person must make the decision, has the required permissions, or will perform most of the remaining work. An adjustment above the representative's authority or a specialist investigation lasting days is not a narrow question. A ceremonial owner adds delay.
The customer should never have to infer that ownership changed. Name the receiving team or role, explain why it now owns the work, preserve what has already been tried, and state the next expected action. In a shared inbox, assignment is not just a name beside a thread. It is a promise about who will notice the next message and move the case forward.
Use this decision matrix before choosing the button.
| Signal in the case | Consult an expert | Transfer ownership | Why it matters |
|---|---|---|---|
| One missing fact blocks an otherwise clear resolution | Yes | Usually no | The original owner can act once the fact is confirmed |
| A second opinion is needed but authority stays with the owner | Yes | No | Advice should not create a new customer handoff |
| The receiving role must approve or execute the resolution | Maybe before handoff | Yes | Responsibility and permissions move together |
| Most remaining work belongs to a specialist queue | Brief first if useful | Yes | The specialist should own future updates |
| No expert accepts the request | Keep and escalate visibly | Do not send blindly | An unaccepted handoff creates an ownerless wait |
Make the decision visible
For either path, send a compact evidence packet with the customer's goal, verified facts, attempted actions, exact decision, deadline, and existing promise. Keep it in the customer record, not a private message.
Record the state change. A consult needs requester, target, time, acceptance, and answer. A transfer needs sending owner, accepting owner, reason, acceptance time, and next action. Until acceptance, the original owner remains responsible.
Automation can remind and route, but silence is not acceptance. Use workflow automation to surface an overdue request, return an unaccepted transfer safely, or remind the owner about a promised update. Keep a human decision where authority or risk changes.
Measure the pattern without gaming it
Do not reward a low transfer rate by itself. A team can reduce transfers by making representatives struggle without help. Do not reward a high consult rate either. It may show healthy collaboration, or it may reveal missing knowledge and unclear permissions.
Start with events. Microsoft documents requested, accepted, unaccepted and timed-out consults, acceptance rate, and average consult time in its representative metric definitions. These describe activity, not quality. Add customer and ownership outcomes.
Review at least these questions together:
- Was the consult accepted, and how long did the customer wait for a useful return?
- Did the original owner complete the case, or did it become a transfer after consultation?
- Did the customer repeat information, contact the business again, or receive a missed promise?
- Which reasons, queues, products, or permissions create repeated expert requests?
- Were transfers accepted by a real owner before the sender left?
Use an inbox report to find patterns by reason and queue, then sample the underlying conversations. Percentages without the actual thread can hide whether a consult saved a handoff or merely delayed one.
Fix what creates unnecessary handoffs
Repeated narrow consultations point to a repairable problem. The approved answer may be hard to find, a permission boundary too low, routing too general, or expert coverage missing when demand arrives.
Fix the common cause before coaching people to ask for less help. Move stable answers into maintained guidance. Clarify who may approve what. Route recognizable specialist work earlier. Give expert requests a safe fallback. Review access through the same security controls that govern the underlying customer data.
The useful rule is simple. Borrow expertise when the original owner can still finish. Transfer when the next person must truly own the decision and the remaining work. In both cases, the customer deserves one visible owner until another one has clearly accepted.
Frequently Asked Questions
What is the difference between a consult and a transfer
A consult adds expertise while the original representative remains responsible. A transfer moves primary responsibility and future action to another person or queue.
Should the customer stay on hold during a consult
That depends on the channel and the question. In voice support, a private consult commonly places the customer on hold, while a public consult can include them. Explain the pause, keep it brief, and return with a useful update. In messaging, keep ownership and the promised response time visible.
How do you measure consult acceptance rate
Use accepted consult requests divided by all consult requests for the same defined period and population. Keep unaccepted and timed-out requests visible, and pair the rate with customer wait and case outcomes.
When is a transfer better than a consult
Transfer when the receiving role has the necessary authority, permissions, or responsibility and will perform most of the remaining work. Confirm acceptance and preserve the customer's context before the original owner leaves.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy