Escalate a Support Case With Full Context
Design a support workspace that helps an agent escalate a difficult customer case without losing evidence, ownership, or response commitments.
The brief
Understand the problem
Background
Frontline agents often recognize when a case needs specialist help, but escalation forms can strip away conversation history and leave customers repeating themselves. The receiving team also needs a clear reason, priority, and expected response time.
User context
Samira is handling a billing case that now involves a duplicate charge, a failed refund, and a customer who leaves for a long trip tomorrow. She needs payments support to take over while keeping the customer informed.
Product problem
Agents need to package the decisive context, choose the right escalation route, and transfer responsibility without creating a second disconnected ticket.
Objective
Create a focused case workspace for preparing, handing off, acknowledging, and tracking one customer support escalation.
What to design
Define the experience
Required experience
- Review the conversation, account history, and current service commitment
- Select an escalation reason and receiving team
- Edit a concise handoff summary with supporting evidence
- Confirm ownership and communicate the next update to the customer
Screens and states
- Case workspace
- Escalation builder
- Handoff confirmation
- Escalation status
Core user flow
Follow the critical path
- 01
Samira opens the active case and sees the unresolved refund timeline
- 02
She starts an escalation and chooses failed refund as the primary reason
- 03
She reviews the proposed summary, removes an irrelevant note, and attaches the payment references
- 04
Payments support accepts the handoff with a response target
- 05
Samira sends the customer a specific update and remains visible as the relationship owner
Product rules
Requirements and constraints
Requirements
- Keep the original case and customer conversation as the source of truth
- Show why the case qualifies for escalation and what has already been attempted
- Separate the customer-facing update from internal handoff notes
- Require an accepting owner or a clearly named unassigned queue
- Record every priority, ownership, and deadline change in the case history
Constraints
- Payment details must be masked unless the receiving role is authorized
- The flow must fit an agent's existing case workspace rather than open a separate product
- An escalation cannot silently reset the original response commitment
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Case history
- Duplicate charge reported at 09:12
- Refund submitted at 09:40
- Refund failed at 11:05
- Customer departure tomorrow at 07:00
Routing choices
- Payments operations
- Account security
- Senior support
- Merchant disputes
Finish line
What to deliver
- Four desktop screens showing escalation preparation, acceptance, and one rejected handoff state
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.