Stabilization
Peak Season
Kaizen Event
CRM Launch
NPS
TTR
6
4
0
20
0
40
60
2
Stabilizing Routing After a CRM Redesign
Case Study by Chris Glasky
Achieved:
A reduction in Time to Resolution from 3.5 days to 0.8 days and restored operational stability across Airbnb's Customer Support organization
Background
In 2023, we launched a net-new CRM system that represented a full redesign of both the agent UI and the backend routing logic across our global Customer Support organization. Early feedback on the UI was overwhelmingly positive.
Unfortunately, we started to see serious regressions in operational performance tied to routing shortly after the launch.
As I led the efforts to address this issue, we defined success as restoring TTR below 2.0 days, stabilizing routing ownership, and improving agent trust in the CRM during our winter peak season.
Time to Resolution (TTR)
2.0
2.0
Net Promoter Score (NPS)
48
48
My role
I owned the transfer product, which sat at the intersection of the CRM UI and the backend routing systems that determined case assignment and ownership.
This launch impacted every Customer Support department and specialty team across a 500+ person internal organization, ultimately supporting 10,000+ frontline agents. While many stakeholders focused on the visible UI changes, the routing transformation was the most critical and least understood component of the redesign.
My first priority was alignment through clarity. Teams were reacting to symptoms (bouncing cases, agent frustration) without a shared mental model of the system.
I created a process map to show end-to-end routing behavior across tools, a wireframe to illustrate how agent actions and system logic interacted, and facilitated a Kaizen event with department heads and key stakeholders to get cross functional alignment and identify the true root cause so we could fix it before our winter peak.
Kaizen Analysis
Timeline - intended to reduce time to resolution (get caught up quickly on a case)
Transfer Tool (to another agent) - volume tier is available to use, but no instructions exist to use it (other tiers use it)
Set to Open - moves to in queue, open concurrency sets to open; tool to manage inbox
Push Prioritization - we have different queues, reasons for case reopen; cases getting “stuck” in queues
Concurrency Slots (set to 2) likely leading to re-routing to back office queue
PAR (< 1 hr) - cases move to the back office queue when not able to push to open to OA
There is no baseline metric for operations to drive or compare against
Metrics that operations is managing to are not driving resolution time
Incentive metrics - Still focused on old behaviors of SPD & NPS
Instructions for breaks and lunches - pending before breaks/lunches/end of day - these instructions have been inconsistent across various articles
Content - the messaging in our workflows is inconsistent about pend times
Training - agents may not have had to show performance that they understood all tools within atrium (i.e. pending) - knowledge checks exist
Delivery Management Console (DMC) - leads how to use these tools
Outliers are not well defined (and/or visible
We have not fully taught leads how to manage pending and review/coach
Team Leads are not doing proper performance management
Ambassador receiving case late in shift
Not adhering to the pending process as defined
Pending process is not specific to every scenario - may drive incorrect behavior
Strong correlation to push prioritization; unclear how prioritization works
Inbound Calls prioritization - number one priority
Workflows are ambiguous and required a lot of investigation to come to a decision
Unresponsive guest and/or Host - we use pending to set follow up time
Ownership of Cases - I don’t understand how I am supposed to manage cases/interactions
Case Avoidance - I set to pending for a time period they know they will not receive it back
Case Avoidance - I set to pending without interacting with the customer in the first contact
Case Avoidance - I set to pending without interacting with the customer when I should be (not first contact)
Ownership of Cases - other agents take over cases and the new tool makes it difficult to get ownership back
Knowledge & Training
New Product
Metrics
People
Process & Policy
Management
SS
SV
SV
VV
SV
SS
NS
NS
SS
VS
SS
SV
VV
VV
VV
VS
VS
SS
SV
SV
SN
VS
VS
SS
SV
VS
VV
VV
I led a cross-functional Fishbone root cause analysis to uncover the full set of issues driving the TTR increase.
Cause & Effect Diagram
I guided the team through impact and effort scoring to prioritize the most actionable drivers
Cause Screening
VS
SV
VN
VV
SS
SN
SV
NS
NN
NV
I mapped VV, SV, VS, and SS relationships to identify true root causes based on influence and dependency patterns.
Root Cause Relationship Analysis
Kaizen Findings
Why we fell short
The new product configuration was a complete 180° of our existing product and process. We attempted to immediately enable a low-ownership / high-touch model, allowing multiple agents to work a case in pursuit of faster responses. In practice, this model amplified negative behaviors and eroded accountability.
Product Strategy & Key Tradeoffs
Reframing the Problem
Rather than treating the TTR spike as a collection of routing bugs, I reframed it as a breakdown in system ownership and behavioral incentives created by the new product model.
Strategic Bet
The long-term vision of low-ownership, high-touch collaboration was sound, but required guardrails to prevent case fragmentation and accountability erosion.
Deliberate Tradeoffs
Prioritized stability and clear ownership over maximum agent flexibility
Chose predictable routing behavior over aggressive automation during peak season
Sequenced behavior change before reintroducing advanced collaboration features
Product Strategy & Direction
A key constraint was maintaining peak readiness while redesigning routing behavior across a 10,000-agent support organization.
I reframed the TTR regression as a systemic ownership breakdown rather than isolated routing defects and defined a phased product strategy:
• Restore ownership and predictability
• Introduce guardrails and monitoring
• Reintroduce collaboration selectively
This sequencing protected near-term stability while enabling long-term transformation.
Solution
Product Changes Implemented
To execute on the phased strategy, I partnered with product and engineering to:
Reconfigure routing to assign clear primary case ownership
Increase case stickiness to reduce uncontrolled transfers
Introduce guardrails to prevent duplicate case creation
Add monitoring to detect bounce patterns in real time
These changes stabilized routing performance while creating the foundation for selectively reintroducing collaborative workflows.
Outcomes & Impact
The target was to return TTR from 3.5 days back to the pre-launch baseline of ~2.0 days.
This phased product strategy not only reversed performance regressions but materially outperformed pre-launch benchmarks.
1.9 days TTR during winter peak
0.8 days TTR stabilized within two months
NPS improved from 18 to 25 during peak, then stabilized at 37
These improvements were sustained, not short-lived. The organization regained confidence in the CRM, and leadership had a clear path forward for future optimization.
Key Learnings
The most important takeaway from this work was:
System design must account for real human behavior, not just ideal workflows.
Adoption, incentives, and ownership dynamics are as critical as technical correctness.
By creating shared understanding, using structured decision frameworks, and sequencing change intentionally, we were able to not only recover from a high-risk launch, but materially outperform prior benchmarks.
• Product Ops • Internal Tools • CRM Transformation • Program Delivery • Continuous Improvement
Turning complex operations into scalable product execution
