Multi-concern requests and handoff to a human

In support, a customer rarely writes about just one thing. “I want to return the jacket, I was charged twice for shipping and I moved” is three problems in one message. And sometimes one of them is beyond the agent and has to go to a human. Both situations have a clear pattern.

One message, several problems

A multi-concern request is resolved in three steps:

1. Split the message into distinct items: return, duplicate charge, address change.
2. Investigate each item in parallel with shared context: the same customer, the same account, the same order. The account looked up for one serves the others.
3. Build a unified resolution before acting, and reply once covering everything.

Step 3 is the one most often forgotten. If each problem is handled by an isolated subagent that doesn’t look at the others, they can act twice on the same thing: three subagents compensating the customer for the same broken item. Splitting is fine; what’s missing is integrating the decisions before executing.

Resolve what you can, escalate what you can’t

Each item is handled according to policy. If the message mixes an address typo, a wrongly charged shipping fee and a refund above the agent’s limit, the agent resolves the first two and escalates only the refund. Escalating everything because of one item makes the customer wait for things the agent could have handled and lowers first-contact resolution.

Handing off to a human

The person who receives the case works in another tool and cannot see the conversation. The summary is all they have. That’s why the structured handoff has to be a self-contained summary with fixed fields:

Field	Example
Customer ID	C-20417
What they asked for	Full refund for a laptop
Root cause found	Manufacturing defect confirmed by technical service
Amount at stake	US$ 640 (agent limit: US$ 200)
What was already done	Address corrected, shipping fee refunded
Recommended action	Approve the refund or offer a replacement

With that, the person can resolve the case without investigating again or asking the customer to repeat everything.

The usual traps

• Resolving only the first problem and leaving the rest for “another conversation”: the customer has to write again.
• Opening one conversation per problem: the shared account context is lost.
• Escalating every compound request: multi-concern requests are normal; sending them all to humans defeats the purpose of the agent.
• Sending the full transcript as the handoff: someone has to read all of it, find the cause again, and it carries no recommended action.
• A vague summary (“customer upset about a charge”): without ID, amount or cause, the person starts from zero.
• Quietly moving the limit: approving 640 when the agent can approve 200, or turning a full refund into a partial one without the customer’s agreement.

In the exam

If the scenario says the person receiving the case “has no access to the chat” or “uses a separate tool”, the answer is the summary with concrete fields. If one customer brings several problems, look for the option that splits them, investigates in parallel with shared context and replies once.