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
Support had to resolve the rental journey, not interrupt it.
Customers often needed help during a time-sensitive rental, while agents were handling routine questions and complex exceptions through the same path. I redesigned the service around contextual self-service, clearer escalation and a workable agent model.
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
My role, the team and how success was defined
A short project brief before the detailed story: the setting, my responsibility, the people involved and the outcome we were working towards.
- 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.
What was happening—and why it mattered
Support sat outside the rental context, information was fragmented and asynchronous hand-offs were slow. The redesign had to reduce customer uncertainty without creating an unsustainable live-support queue for the Customer Relations Centre.
- 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.
Response time improved after we gave every support touchpoint a clear purpose, owner and next step.
Evidence that changed how I understood the problem
Behavioural, operational and qualitative evidence did different jobs. Together, they helped define what the team needed to solve before choosing a direction.
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.
What customers saw depended on what happened behind it
The blueprint connects the customer journey, product behaviour and operational responsibilities 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 boardThe choices that shaped the work
The artefacts mattered when they helped the team choose. These are the questions, evidence and decisions behind the final direction.
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.
One problem, viewed through service and product
The operating service and the interface formed one system. Each lens addressed 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
How the work moved from uncertainty to a decision
Reconstruct the service customers experienced
Churn-survey findings, face-to-face interviews and support patterns showed where uncertainty began, which questions repeated and where the journey broke between the product and the CRC team.
Map the customer and agent sides together
A current-state journey connected customer actions, visible support touchpoints, agent work and ownership gaps. This kept the team from treating response time as an interface-only problem.
Give each support layer a clear job
The target model moved from contextual FAQ content to live assistance and agent resolution. Self-service handled repeatable questions; human support focused on unresolved needs and exceptions.
Match the interface to operational reality
I defined in-app entry points, conversation and status patterns alongside what CRC could reliably own and follow through.
Measure the service, not the polish
Turnaround and no-reply tickets were the test of whether the new model was faster and more dependable after rollout.
The constraints that shaped the work
These constraints affected the direction, the order of work and the compromises made with the wider team.
Speed versus agent capacity
The tension
Putting live help everywhere could reduce waiting for some customers while creating a queue the team could not sustain.
My response
Repeatable questions moved to contextual guidance, with human support reserved for needs the product could not resolve.
Context could disappear at escalation
The tension
Customers risked having to explain the same problem again when moving from self-service to an agent.
My response
The target journey carried issue context forward so escalation continued the conversation instead of restarting it.
The interface could over-promise
The tension
A visible status or response expectation only helps if the CRC team can fulfil it consistently.
My response
Customer-facing states and escalation rules were designed alongside operational ownership and follow-through.
What the evidence shows
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
Support turnaround fell from 1.5 hours to 7 minutes.
02
Agent no-reply tickets fell by 92%.
03
Help moved into the product journey and closer to the moment of need.
04
The service model reserved agent attention for more complex exceptions.
What I learned and would do next
I reframed slow support as a service-system problem and gave customers and agents a clearer path through the same journey.
The largest gains came from deciding which work the interface could absorb and which work still needed human judgement.
I would add a contact-reason taxonomy and track self-service success, escalation, repeat contact and CSAT by journey stage.