01Customer evidence
Churn surveys and face-to-face interviews exposed moments where unresolved questions interrupted confidence in the rental journey.
Design implication
Support needed to appear inside the product, at the point of uncertainty.
BlueSG
Customer support should resolve the journey—not become another one.
I redesigned BlueSG’s customer-support service around faster in-app answers, clearer escalation and a more workable agent model—cutting turnaround from 1.5 hours to 7 minutes.
Service DesignProduct DesignUX Research
- My role
- Lead Product Designer — service research, journey mapping, stakeholder alignment, channel strategy, interaction design and measurement
- Scope
- Discovery → service rollout
- Focus
- Contact centre · Service blueprint · Support experience
- Evidence status
- Operational outcomes were measured after rollout. The linked Miro board contains the original service-design exploration and supporting detail.
Measured service impact
1.5h → 7msupport turnaround
−92%agent no-reply tickets
In-apphelp at the point of need
What I owned—and the environment around the work
A concise project brief that makes my individual contribution, collaborators and definition of success clear before the detailed process.
- 01Service context
- Customers were often seeking help during a time-sensitive reservation, access or rental moment—not during a relaxed support journey.
- 02My ownership
- I led service discovery, mapped frontstage and backstage gaps, aligned stakeholders and translated the target service into in-app support behaviour.
- 03Core collaborators
- Product, Engineering, Growth, Operations and the Customer Relations Centre worked across the same service problem.
- 04Success definition
- Faster response, fewer unanswered tickets and a support journey that reduced customer uncertainty without overwhelming CRC agents.
The decision behind the screens
Customers needed help while navigating time-sensitive rental journeys, but fragmented information and slow, asynchronous hand-offs made support feel like a separate obstacle. The redesign had to improve the customer experience and reduce avoidable pressure on the CRC team.
- Help was disconnected from the rental context in which problems occurred.
- Customers waited too long to understand whether anyone owned their request.
- Repeated questions consumed agent capacity needed for complex exceptions.
- No-reply tickets exposed gaps in channel design, ownership and follow-through.
The service improved when every support touchpoint had a clear purpose, owner and path forward.
Three signals changed the shape of the problem
I connected behavioural, operational and qualitative evidence before choosing a solution. Each signal created a concrete design implication.
02Operational evidence
Ticket and response patterns showed that routine questions and genuine exceptions were entering the same service path.
Design implication
The service needed progressive triage rather than a single queue.
03Stakeholder evidence
Customer, agent and product needs were interdependent: faster answers could not come at the cost of unmanageable CRC workload.
Design implication
Frontstage changes had to be designed with backstage ownership and escalation.
The experience only works when the backstage works
The blueprint keeps the customer journey, visible product behaviour and operational responsibilities connected across the same sequence.
StageCustomerFrontstageBackstage
1 · Need help
Encounters a question or problem during the rental journey.
A contextual help entry point is visible inside the app.
Issue categories connect the request to the appropriate response path.
2 · Find an answer
Checks concise FAQ guidance without leaving the task.
Self-service content answers common, repeatable questions first.
The knowledge layer absorbs demand that does not require an agent.
3 · Escalate
Starts a live conversation when guidance is not enough.
The conversation carries the issue context forward.
CRC receives a clearer case instead of asking the customer to restart.
4 · Resolve
Gets an answer and understands what happens next.
Response and status patterns make ownership visible.
Agents handle exceptions with a defined follow-through path.
5 · Learn
Returns to the rental journey with less uncertainty.
Resolution closes the loop in the same service context.
Recurring contact reasons inform content and product improvements.
Scroll horizontally on smaller screens to follow the complete service.
Explore the original CRC service-design boardComplexity, compressed into three decisions
The artefacts were useful because they helped the team make choices. This is the evidence-to-decision trail behind the final experience.
Question
Where should help begin?
Evidence
Customers needed answers while they were already inside a rental task.
Decision
Make in-app support the primary, contextual entry point.
Question
Which contacts need an agent?
Evidence
Routine questions and situational exceptions were competing in one path.
Decision
Use FAQ guidance first, then live support for unresolved needs.
Question
How do we reduce silence?
Evidence
No-reply tickets reflected weak ownership and fragmented follow-through.
Decision
Carry context into escalation and make service status clearer.
Service Design and Product Design, deliberately connected
I treated the operating experience and the interface as one system. Each lens solved a different part of the same problem.
Service Design
Shaping the ecosystem, hand-offs and operating model.
- Reconstructed the support journey from customer and CRC perspectives
- Separated repeatable questions from cases needing human judgement
- Clarified entry points, escalation and ownership across the service
- Connected service performance to measurable response outcomes
Product Design
Turning service decisions into clear, usable product behaviour.
- Brought FAQ guidance and live assistance into the app
- Designed a progressive path from self-service to agent support
- Preserved conversation context during escalation
- Used clear status and response patterns to reduce uncertainty
From ambiguity to a decision the team could act on
Discover the service customers actually experienced
Combined churn-survey findings, face-to-face interviews and support patterns to understand where uncertainty began, which questions repeated and where the journey broke between product and CRC.
Map frontstage and backstage together
Created stakeholder personas and a current-state journey spanning customer actions, visible support touchpoints, agent work and ownership gaps. This prevented the team from treating response time as an interface-only problem.
Design a progressive support model
Structured the target service from contextual FAQ content to live assistance and agent resolution. Each layer had a clear job: answer quickly, preserve context or handle an exception.
Translate the service into product behaviour
Defined in-app entry points, conversation and status patterns, then aligned the experience with what CRC could reliably deliver behind the scenes.
Measure the operating outcome
Tracked turnaround and no-reply tickets to judge whether the redesigned service was actually faster and more dependable—not simply more polished.
What made the work difficult—and how I responded
These constraints shaped the solution, the order of work and the compromises I made with the wider team.
Speed versus agent capacity
The tension
Offering live help everywhere could improve responsiveness while creating an unsustainable queue.
My response
I separated repeatable questions from exception cases and designed a progressive path from FAQ guidance to human support.
Fragmented channel context
The tension
Customers risked repeating the problem when moving from self-service to an agent.
My response
The target journey carried issue context forward so escalation felt like continuation rather than a restart.
Frontstage promise versus backstage reality
The tension
The interface could not promise speed or ownership that CRC operations could not consistently deliver.
My response
I designed customer-visible status and escalation rules alongside operational ownership and follow-through.
Evidence that moved the work forward
7 minsupport turnaround after redesign
1.5 hrprevious turnaround
92%reduction in agent no-reply tickets
2 lensescustomer experience + CRC operations
Operational outcomes were measured after rollout. The linked Miro board contains the original service-design exploration and supporting detail.
Explore the original CRC service-design boardWhat changed
01
Cut support turnaround from 1.5 hours to 7 minutes.
02
Reduced agent no-reply tickets by 92%.
03
Placed support inside the product journey instead of outside it.
04
Created a service model that reserved agent effort for higher-value exceptions.
Looking back and ahead
I reframed a slow-support problem as a connected service-system problem and gave both the customer and CRC team a clearer path.
The largest experience gains came from deciding which work the interface should absorb and which work needed human judgement.
I would add a contact-reason taxonomy and track self-service success, escalation rate, repeat contact and CSAT by journey stage.