Reimagining the Complaint & Feedback Lifecycle
At a large financial company, the way complaints and employee feedback were handled had become hard to manage. People used many tools that didn't talk to each other, sorted the same kind of issue in different ways, and relied on workarounds to get through the day. I worked on a project to rethink the whole journey, from the moment someone raises an issue to the moment we confirm it's fixed. It covered seven types of people, both employees and customers, who are part of that journey.
My Role: UX Research, Product Strategy, UX Design, Stakeholder Workshops
Methods and Tools: Discovery Interview, Thematic Analysis, Persona Development, Validation Workshop, Prioritization Exercise & Concept Creation, Future-State Journey Mapping
The Problem Space
Complaints came in through many different channels. To look into one case, people had to use dozens of systems. They typed the same issue in again and again because the systems didn't share information. And once a complaint was logged, nobody could see who owned it, where it stood, or whether it ever got fixed. It just disappeared.
“My team works out of dozens different systems just to do research.”
Discovery
We started by understanding how complaint handling actually worked across the organization, who touched a complaint, what systems they relied on, where handoffs happened, and where people were creating workarounds to get the job done
-
Before writing a single interview question, we reviewed existing process documentation and worked with the core team to map who needed to be at the table.
Complaint handling touches frontline banking, contact centers, compliance, legal, risk, IT, and multiple lines of business — each with a different relationship to the same system.
This mapping shaped the 13+ stakeholder groups selected for discovery.
We also ran periodic stakeholder alignment syncs throughout the project to keep leadership updated between formal milestones.
-
Because a compliance specialist and a frontline banker experience the same system completely differently, we created a distinct interview guide for each role rather than relying on a single generic script.
Every session followed a consistent arc:
Understand the role → Walk through the lifecycle → Identify pain points → Explore opportunities
This allowed us to compare experiences across very different roles while still surfacing the nuances of each one.
-
With perspectives coming from 13+ stakeholder groups, the challenge was moving beyond individual anecdotes to understand the patterns connecting them.
Each transcript was coded stage by stage across the complaint lifecycle:
Capture → Research → Resolve & Close → Insights → Root Cause → Hand-off
We tagged what was happening today, the pain points and needs raised, and opportunity ideas volunteered by stakeholders. Verbatim quotes were preserved alongside each coded point so the context behind each finding wasn't lost during synthesis.
Discovery
We started by understanding how complaint handling actually worked across the organization, who touched a complaint, what systems they relied on, where handoffs happened, and where people were creating workarounds to get the job done
01. Kickoff & Stakeholder Alignment
Before writing any interview questions, we read through the existing process documents and worked with the core team to list who needed to be involved. Complaints touch frontline teams, call centers, compliance, legal, risk, technology, and several business lines, and each group sees the same system differently. That list became the 13+ groups we interviewed.
02. Discovery Interviews
Because a compliance specialist and a frontline banker experience the same system completely differently, we created a distinct interview guide for each role rather than relying on a single generic script.
Every session followed a consistent arc:
Understand the role → Walk through the lifecycle → Identify pain points → Explore opportunities
03. Finding patterns
With perspectives coming from multiple stakeholder groups, the challenge was moving beyond individual anecdotes to understand the patterns connecting them.
We tagged what was happening today, the pain points and needs raised, and opportunity ideas volunteered by stakeholders.
Key Findings
Through thematic analysis, we saw the same problems come up again and again across different teams and user groups. Five themes stood out.
*Quotes are reworded from interviews to protect confidentiality.01 |
02 |
03 |
BURDENSOME COMPLAINT CAPTURE
Logging a complaint was hard to do while helping a customer. It took effort, broke people's focus, and was easy to put off or skip when things got busy.
"We just don't have enough time to spend [several minutes] filling out a complaint."
A complaint passed through many separate tools with nothing tying them together, so someone had to rebuild the story by hand at every handoff.
SYSTEMS THAT DON’T CONNECT
"When a customer calls back, I'm starting from zero because I can't see what happened the first time."
04 |
LIMITED VISIBILITY AFTER SUBMISSION
Once a complaint was submitted, it was hard to tell who owned it or where it stood. Follow-up depended on people chasing each other.
"We just take care of logging the request… we're not sure what happens after that."
05
There were no clear rules for how to label an issue. The same complaint could end up in different categories depending on who logged it, which made reports and root-cause work less reliable.
NO SHARED WAY TO CLASSIFY COMPLAINTS
"There are so many options that by the time I get to the end of the list, I just pick 'other.'
KEY FINDINGS
Different people file identical complaints under different categories.
There are no shared steps or templates to follow.
Some important fields are optional, so records can come in incomplete.
That makes reporting and routing less reliable
Some automation and AI was already in place, but it didn't cover the full process. Much of the work, especially escalations and reporting, still ran on paper checklists, email threads, and informal workarounds.
LIMITED AUTOMATION, HEAVY MANUAL EFFORT
"I've asked you this, this, this, this, and this… and out of the five things I need, you may have answered two."
KEY FINDINGS
It can take several minutes, which is a long time in the middle of a customer conversation.
When time is tight, people put it off or skip it.
So the system may not show the full picture of what customers are raising.
KEY FINDINGS
They arrive through many channels, with no single front door.
Nobody has one complete view of the customer or the case.
Teams fall back on email and informal follow-ups.
Context often has to be pieced back together by hand.
KEY FINDINGS
It's hard to tell where a case stands, like looking into a black box.
Ownership gets fuzzy as cases move between teams.
Follow-up is hit and miss, and hard to see.
Nobody hears back about what happened, so there's no loop to learn from
KEY FINDINGS
Paperwork and compliance checks are manual.
Escalating a case means sending emails and chasing people.
Reporting and quality checks take a lot of manual effort.
Checklists and calculations still happen on paper or in spreadsheets, not in the system.
IMPLICATION
Logging is hard enough that the system may not show everything customers are raising. That can leave gaps in how the organization sees risk, reporting, and the customer experience.
IMPLICATION
Reports and root-cause work start from data that's hard to trust.
IMPLICATION
At every handoff, someone has to rebuild the context from scratch. That takes time, invites mistakes, and makes customers repeat their story.
IMPLICATION
Complaints that aren't tracked can come back, and fixes are applied unevenly. Customers end up chasing answers, and no one can say for sure whether a problem was really solved.
IMPLICATION
Important steps still rely on people coordinating by hand, work that a system could support.
Who we designed for- no of people we talked to and stakeholder groups
Across the interviews, we spoke with people in many different roles. We grouped what we heard into seven personas: six employee roles and one customer. For each one, we captured what they do, what gets in their way, and what they need.
"I log it, and then it's gone. I never find out if it got fixed."
👆
Then we looked at where the pain points concentrated. One persona came up in most of the themes: the person who first hears a customer's complaint. They sit at the start of the process, so what happens at their step, or doesn't, shapes everything after it. That's why we start with them.
is usually the first person a customer reaches when something goes wrong. They have to recognize a complaint while it's being described, record it while still on the call, and sometimes sort it out right there.
The First Listener*
*All seven personas come from the research, not from assumptions. Each is based on the people we interviewed and what we observed about how they work. The First Listener is one example of the six employee personas. We also built a customer persona, drawing on conversations with a few customers, so we could see the experience from their side: how it feels to raise a complaint and what they expect to happen next.why highlighting one and everything else we considered.
JOBS TO BE DONE
When a customer tells me something went wrong, I want to record it accurately without losing the conversation, so they feel heard and the right team can act.
WHAT THEY NEED
Clear guidance on what qualifies as a complaint
Support for capturing details without relying on memory
A way to see progress and outcomes
PAIN POINTS
No clear definition. Without simple rules, they go by tone and keywords, so two people can treat the same call differently.
Two jobs at once. Talking and typing together splits their attention, and when time is short, logging gets delayed or skipped.
A long form. Too many fields and options, and only one slot for calls with several issues.
No follow-up. They can't see what happens next, so they can't update the customer or learn from the outcome.
Current State Journey Map
To see how all of this fits together, we mapped the complaint journey as it works today, from the moment a customer raises an issue to the moment a fix is checked. The map has five phases. It shows what people do, where the process breaks down, and who is involved at each step.
We used the journey as a working artifact in the stakeholder workshop, where teams validated the findings, added gaps, and identified opportunities for improvement.
👆
Current-state journey used as a collaborative workshop artifact. Stakeholders annotated pain points, gaps, handoffs, and opportunities across the complaint lifecycle.
Validation & Defining the North Star
We took the journey, personas, and findings back to stakeholders who work in the process every day.
They confirmed the key pain points, added missing context, and challenged our assumptions.
That gave us a shared direction: our North Star.
Every complaint is recorded easily the first time, categorized the same way by everyone, visible to the people who need it, and followed through to a fix that's tracked until it's done.
From
Every person recording complaints in their own way, so the data can't be relied on
Teams in separate corners, customers repeating themselves
North Star.
No clear owner, no follow-through
Progress that depends on individual effort
Divided attention, missed, or half recorded complaints
To
Effortless capture with full focus on the customer
One shared standard, so a complaint reads the same no matter who records it
One team, one story carried forward
Clear ownership people can trust
Support built in, so insight becomes action
From Insights to Concepts
With the direction agreed, we turned the findings into five concepts, one for each theme. For each, we framed a "how might we" question and ran a co-creation session where stakeholders added reactions, concerns, and ideas.
Get It Right at Hello
How might we make it effortless for whoever hears a complaint first to get it right, so they can focus on the customer, not the paperwork?
Tailor Every Entry
How might we fit logging to each person’s role, while everyone still speaks one common language?
Tell It Once
How might we let customers tell their story once, and never lose it between teams?
Retire “Any Update?”
How might we make every case’s status clear to everyone, without anyone having to chase it?
Fix It at the Root
How might we turn a pile of complaints into the fixes that stop them coming back?
One concept in depth: Get it Right at Hello with Intelligent Capture
Today, the person taking a complaint has to listen, type, search other systems, and pick a category, all at the same time. Complaints get rushed, sorted differently, or skipped, and customers end up repeating their story.
Automatic capture flips that. The system does the remembering, writing, and sorting, and the person focuses on the customer. They get the right help at the right moment, a complaint record that’s already filled in, and a simple review before submitting.
WHAT WE HEARD
Supported: drafting the record automatically, and using voice instead of typing where typing isn't practical. People wanted to stay in control, able to review and edit before anything is saved.
Key Callouts: Automatic Capture
Customer impact: faster answers, and no repeating themselves.
Business impact: complete, consistent complaint data that every later step depends on, from routing to reporting to fixing root causes.
Concerns: consent and privacy requirements around recording had to be resolved before scaling, and a quick interaction needs a lighter path than a full workflow.
Why it matters: less admin during each interaction, more attention for the customer, and complete, consistent records that every later stage depends on.
The right help at the right moment
Before the customer speaks, the assistant shows why they’re likely calling, their open case, and their recent contacts, so the call starts with context instead of questions. As the call goes on, it shifts to how the customer feels and what to do next, with only one thing open at a time. Customers get help faster, and every call is handled consistently.
Consent comes first
A short script and a clear yes or no come before anything is recorded, with typed notes as a fallback if the customer declines. Customers stay in control of their data, and the business has a clear record that consent was given.
Listen, don’t type
The call is written out as it happens, and issues are tagged the moment they’re mentioned. The person can focus on the customer, and fewer details get lost or misremembered.
A draft that’s almost done
The system suggests the product, the issues with a confidence level, and a summary, and links everything to the open case. The person only reviews and submits. Logging takes seconds, so fewer complaints are skipped, and every complaint is sorted the same way.
How we got from 22 ideas to 6 that ship first
The concepts gave us a vision. The harder question was what should launch first, and what would deliver the most value with the least friction.
In a co-creation workshop, operations, compliance, technology and front-line teams placed concept features on a 2×2 of value against feasibility. We then tested each choice for desirability (what research told us), viability (which measures it moves) and feasibility (technology and regulatory limits).
Fill-ins 4
Do first 10
Deprioritize 2
Strategic bets 6
Illustrative, based on the workshop.
Why these six made the cut
Hands-free call notes
The only feature chosen by two groups. Manual note-taking is the biggest time sink on a call, and the most common reason details go missing.
Category suggestions
Every later step depends on the right category at intake. The agent confirms it, so they stay in control.
Auto-assignment
Complaints were being passed between teams with no clear owner. Assigning an owner at the start fixes that, using rules we already know how to build.
Tailored forms
A branch banker and a specialist need different depth. Teams asked for a lighter form for quick conversations.
One common category list
Without one shared set, reporting and compliance can't compare like with like. Low cost, high leverage.
Due-date warnings
A missed regulatory deadline is the costliest failure. Simple threshold rules make this one quick to ship.
The other four "do first" features need the MVP's clean data, so they follow in Next.
The design call
Our prototype shows mood detection and suggested next steps, but the workshop placed both as strategic bets. We kept them in the vision and out of the MVP. The MVP is the part that earns the right to get there.
A roadmap in three layers, each earning the next
We sequenced the work so every layer builds the data and trust the next one needs. The MVP ships first, because everything after it depends on the clean records it creates.
The MVP: solve most of the problem first
Capture every complaint accurately, classify it consistently and route it to the right owner, so agents can focus on the customer while the system does the work.
Nothing missed
Every complaint is captured automatically the moment a call begins.
One-click accuracy
Every case gets a suggested category, and the agent confirms it.
Nothing unassigned
Every complaint lands with the right owner and a clear deadline.
Every feature tied to a number that matters
To support pilot planning and win leadership backing, we framed value around time saved, cost per complaint and customer trust. We estimated what a complaint costs today, then modelled each feature against the pain points from research. The same levers became how we'd measure success.
Shorter calls
No manual typing or after-call write-up.
Resolved first time
The right category and owner from the start.
Fewer callbacks
Proactive updates replace "just checking in" calls.
Lower cost per complaint
Automation and fewer escalations.
Feature impact mapping
LayerShorter calls, no missed details
EfficiencyNowResolved first time, consistent records
AccuracyNowAnswered in under 45 sec, no unassigned cases
EfficiencyNowFaster branch intake, comparable data across channels
RiskNowFewer missed regulatory deadlines
RiskNowFewer callbacks, updates within 36 hrs
ExperienceNextLower cost per complaint, 15% fewer repeat complaints within 90 days
GrowthLaterIndicative targets based on financial-services contact-center benchmarks. Not client data.
Outcome: from concept to an aligned plan
A validated direction, a first release everyone agreed on, and a clear way to judge whether it's working.
Future state validated
Five connected concepts shaped and tested with stakeholders across the business.
MVP and roadmap aligned
A focused first release and a sequenced path, agreed across operations, compliance and technology.
Success defined
One headline measure for every layer, from handle time to cost per complaint.
Business case quantified
The key MVP saving: time back to agents on every call.
Conclusion
Working with stakeholders from operations, compliance, technology and the front line taught me that the best solutions come from many perspectives. Moving from ideas to a prioritized roadmap and a business case showed me how design and strategy work together: imagining what could exist, then deciding what to build first and why it’s worth it.
