Prompt and scope
A B2B product has many customer touchpoints. High-value customers often message engineers directly, while ordinary tickets wait, causing duplicate investigation and uncontrolled promises. Design an enterprise escalation intake and operating model: what escalates, who decides, and how success is measured. The core skills are problem framing, prioritization, and cross-functional execution, so this belongs to product.
What the interviewer evaluates
The answer should separate “important account” from “high-impact event,” define observable severity, evidence, SLA, owner, and customer communication, and avoid creating another ticket silo. It should also feed recurring patterns into product planning.
Questions to clarify first
- Is the escalation an outage, data or security risk, contractual promise, or feature request?
- How will account tier, affected users, and business loss be evidenced?
- Which teams have on-call, decision authority, and external communication authority?
- Can the current CRM, ticketing, and incident systems share one ID and state?
- Are success metrics response speed, recovery time, retention, or fewer repeat issues?
30-second answer framework
“I define severity from impact and risk, not volume of customer pressure. One intake collects reproduction steps, account, impact, and desired timing, then creates a traceable ID. Rules route outages, security, contracts, and feature requests to separate queues with an owner, SLA, escalation path, and communication template. After resolution, the customer confirms the key workflow works; the ticket closes and recurring patterns feed product planning. Measure response and recovery time, SLA attainment, repeat escalations, customer impact, and retention risk.”
Step-by-step solution
Embed the intake in the existing support center, CRM, or ticketing system rather than creating a new silo. Ask for issue type, affected account or workspace, start time, reproduction steps, sample IDs, and business impact. Generate one escalation ID and retain internal and external communication.
Use an impact-urgency matrix. Unavailability, data integrity, security, and regulatory risk usually outrank one feature request. Account tier can change response commitments and communication frequency, but it should not override factual impact or let routine work displace an incident.
Route outages to on-call, security concerns to security response, contract promises to customer success and legal, and feature requests to product triage. Every state has one owner, a next action, and a deadline. On timeout, notify the duty lead; across teams, one coordinating owner remains accountable to the customer.
Separate internal facts from external promises. Acknowledgement includes the ID, known impact, next update time, and uncertainty; never promise an unverified fix time. After recovery, have the customer confirm the critical workflow, then share root cause, impact, remediation, and follow-up actions. Restrict sensitive security detail by permission.
Aggregate product feedback by theme rather than turning every escalation into a feature. Count affected accounts, revenue exposure, alternatives, support hours, and risk before roadmap review. Frequent but low-impact issues may be solved with documentation, defaults, or automation.
Use three metric layers. Operations: first response, MTTA, MTTR, SLA breaches, transfers, and backlog. Customer: recovery confirmation, repeat escalation, CSAT, and renewal risk. Product: repeat-issue rate, support hours, resolved root causes, and roadmap delivery. Slice by severity, account tier, and issue type so averages do not hide high-risk accounts.
Pilot with one customer segment or issue type. Replay historical escalations to test classification and routing, and verify that a sales message can become the same escalation ID. Review false positives, missed cases, promise variance, and customer feedback weekly; version the severity definitions and form fields.
Model high-quality answer
“I would build the intake in the current ticketing or CRM system, not another silo. It collects issue type, account, impact, start time, reproduction steps, and business loss, then creates one escalation ID. Severity is based on availability, data or security risk, and impact; account tier changes SLA and communication frequency but does not replace facts.
Outages, security, contracts, and features route to on-call, security, customer success/legal, and product triage. One coordinating owner exposes state, next update, and timeout path. After recovery, the customer confirms the critical workflow, the team records root cause and remediation, and recurring patterns enter the roadmap. I evaluate MTTA, MTTR, SLA breaches, repeat escalations, recovery confirmation, and renewal risk.”
Common mistakes
- Use account value as impact severity → real incidents are displaced → let tier affect service promises only.
- Create a separate escalation inbox → history and state fragment → reuse CRM or tickets with one ID.
- Let several teams promise externally → customers hear contradictions → assign one coordinating owner.
- Use MTTR while the customer is still blocked → service closure is not business recovery → require workflow confirmation.
- Put every escalation on the roadmap → anecdotes drive product → aggregate themes, impact, and alternatives.
- Collect description without evidence → engineers cannot reproduce → require time, sample IDs, logs, and scope.
- Promise a fix too early → trust worsens → state the next update and uncertainty boundary.
- Look only at averages → a few high-risk accounts disappear → slice by severity, tier, and type.
Follow-up questions and responses
Follow-up 1: Should every VIP issue be highest priority?
No. VIP status changes service commitment and communication frequency, while severity still uses impact, risk, and business loss so incidents are not hidden.
Follow-up 2: How does a sales message enter the system?
Provide a create or forward path that copies context, customer, and promises into one escalation ID and requires an owner and SLA. A private message must not remain a side channel.
Follow-up 3: Who may change severity?
The duty lead or incident commander may adjust it from evidence, recording reason and time. Product or sales should not silently change the level.
Follow-up 4: When does an escalation become a product request?
When the issue repeats across accounts, impact is clear, and a generalizable root cause or alternative exists. A one-off contractual customization is evaluated separately.
Follow-up 5: How do you stop duplicate reports?
Show state and next update time, and let customers link an existing escalation ID. Merge similar issues while retaining each account’s impact and communication history.
Follow-up 6: Can security issues use ordinary tickets?
Sensitive details should not be exposed. Detect the security type and route to a restricted queue; share only necessary external status and retain internal audit evidence.
Follow-up 7: How do you validate routing rules?
Replay historical escalations and pilot data to measure false routing, missed cases, transfers, SLA, and recovery confirmation. Review continuously and version the rules.