A good handoff tells a shopper when a person is needed, routes the request to the right team, and gives that team enough relevant context to continue. It also limits private information to people who are authorized to see it.
For a Magento merchant, the practical challenge is coordinating the storefront, support channels and customer verification. Design the escalation path before the assistant starts answering customers.
Decide when a person should take over
List situations where the assistant should offer a human: a complaint, an unresolved product-compatibility question, conflicting store policies or repeated failed attempts. A customer should also have a clear way to request a person without proving the assistant wrong.
Define which issues the assistant can resolve from verified public information and which require an authorized agent. Do not promise a refund, change an order or disclose account details merely because a shopper asks.
Build a routing table with the support team
Start with a small set of situations and assign an owner for each. A question about an unverified product attribute might go to product support; a damaged-item complaint might go to the service team; and a request for private order details should enter the store’s verified order-support process. The exact destinations and verification steps must match the merchant’s own setup.
For every route, agree on the information the receiving team needs, the channel to use, and what happens outside staffed hours. Keep a named owner for updating the table when queues or policies change. If there is no suitable destination, show a real contact option instead of assigning the request to a queue that cannot handle it.
Make the next step clear to the shopper
Before handing off, say what will happen next: whether the conversation is being sent to support, which channel will be used and whether the team is currently available. Give a realistic response expectation only when the merchant has established one.
If the support channel is unavailable, explain the alternative rather than claiming a request was sent. Keep the message useful even when the customer chooses not to provide additional details.
Give the agent a useful, limited summary
A support agent needs the shopper’s question, relevant product or order context when authorized, steps already attempted and the unresolved issue. Separate verified facts from the customer’s statements and flag anything that is uncertain.
Share only information needed to resolve the request. Avoid passing payment credentials, one-time verification codes or unrelated conversation history. Apply the merchant’s access controls and retention practices to any stored summary.
Adobe documents the types of customer information that may flow through Commerce storefront and administrative systems; use its reference when mapping what your own integration can expose.
Example: an unanswered compatibility question
A shopper asks whether a replacement part fits a device. The catalog does not contain a verified compatibility list, so the assistant offers human help rather than guessing. A useful handoff can say: “The shopper asked whether this part fits their device; compatibility is not confirmed in the catalog.” Include the relevant product reference and the device model only when the receiving team needs them.
In a test, check that the receiving queue actually gets the summary and that the shopper sees a clear next step. If the transfer fails, show the store’s available contact option instead of saying an agent has received the request.
Separate facts from statements in the summary
In the compatibility example, a useful record distinguishes three things: the product reference retrieved from the catalog, the device model as stated by the shopper, and the unresolved question of whether the two fit. The receiving agent can then consult an approved compatibility source without mistaking the shopper’s description for a verified match.
The same distinction matters for an order question. A shopper saying “my parcel is late” is a report of a problem, not proof of a carrier delay. An agent should see a current authorized order or tracking result when one is available, together with its source or update time if the support workflow provides it. If no verified result is available, the summary should say so.
Agree on what a successful transfer means
Write down what the sending and receiving systems need to exchange: an authorized destination, the unresolved question, a reference the team can use to find the request, and a status that shows whether the receiving system accepted it. Agree who owns the request after acceptance and what the shopper should see at each stage.
A successful handoff is more than a button click. Check the receiving queue for the expected request and summary; acceptance into a queue does not mean that an agent has read or resolved it. Test a delayed or failed transfer and repeated clicks so the team can identify duplicates and the shopper is not given a false confirmation.
Keep order access behind verification
A product catalog question does not establish that the visitor owns an order. When the request concerns private order details, follow the store’s existing customer verification and authorization process before showing or passing protected information.
Test both a verified customer and a visitor who is not verified. A failed verification should lead to the defined safe support process, not an invented order status or an agent receiving another customer’s data.
Assign ownership and close the loop
Decide which queue owns each escalation and how the team recognizes a new, assigned or resolved request. If the conversation is transferred between channels, confirm that the receiving team can identify the request without asking the shopper to repeat every step.
Review unresolved handoffs with support staff. Look for unclear summaries, transfers to the wrong team and cases where the assistant said a person would respond but no request was created.
Test the complete experience before launch
Use fictional shopper details and a controlled test order. Try an explicit request for a person, a product question with missing compatibility data, an unavailable support channel and a private-order question before verification. Check both the shopper’s view and the agent’s received context.
For each test, record the expected destination, the confirmation shown to the shopper, the request received by support and whether sensitive details were excluded. Include a failed transfer and a repeated request; investigate any duplicate or missing record before launch.
Record the sample size, response time, successful transfers and any privacy or routing failures. Re-test after changes to the storefront integration, support workflow or permissions. A fast answer alone does not prove the handoff succeeded.
Measure the handoff, not just the answer
Choose a review period and count handoff attempts, transfers accepted by the receiving system, transfers that failed or timed out, and requests found in the wrong queue. Review a permitted sample of received summaries for missing context or unnecessary private information. Define the denominator for each measure and keep retries separate from distinct shopper requests.
Track time to acceptance separately from time to a human response and time to resolution. A quick queue acceptance can coexist with a long wait for an agent. Discuss outliers with the support team and compare like-for-like periods; a small sample or a change in staffing can make a percentage misleading. Use the findings to improve the workflow rather than claiming a specific business result from a single metric.
Should every question go to a person?
No. Simple questions grounded in current, permitted store information may be suitable for the assistant. The right boundary depends on the merchant’s policies, the risk of a wrong answer and the customer’s preference.
What if no agent is available?
State the actual support availability and offer a real alternative, such as a supported contact channel. Do not claim that a ticket was created unless the system confirms it.
How much conversation history should be shared?
Share the minimum relevant context the receiving team needs and is authorized to access. Follow the store’s privacy and retention policies, and leave credentials and verification codes out.