Rupan Balaji
NO. CMS–01
TYPE: UX Case Study
STATUS: DESIGN COMPLETE
Everyone had a different tool for the same problem.
A ground-up redesign of an internal complaint & ticket management system — replacing a pile of overlapping tools with one shared way to raise, route, approve, and close an issue, for every team that touches one.
8 user groups
8 feedback themes
2 rounds of research
5 permission tiers
3 ticket types
SCROLL TO READ THE STORY ↓
OVERVIEW
What this system needed to do
The Complaint Management System, or CMS, is the tool a company’s teams use to raise, route, and close out problems — from a broken internal report to a request for a feature that doesn’t exist yet. Before this redesign, that work was split across half a dozen tools never built for it.
02
Incident Ticket
Something is broken inside a business application and needs to be fixed.
03
Change Request
A request for something new, which needs a manager’s or the business’s sign-off first.
01
Service Request
A straightforward ask — data, access, or information someone needs to do their job.
WHO TOUCHES A TICKET
Tech Leads
Business Users & Managers
QAs
Program Managers
Developers
Support Team
IT Employees
Business Analysts
THE PROBLEM
Nobody owned the whole process
Because there was no single system, there was no single source of truth. Finding out where a ticket stood usually meant asking around instead of just looking. Screenshots couldn’t be attached to a ticket. Notifications reached people who had nothing to do with the issue. A ticket could say “closed” without any record of when, or how.
Tools people were stitching together: Jira, Microsoft Teams & Planner, Excel trackers, Freshworks, plain email, and the IT Services portal — a different combination depending on which team you asked, none of them built for this exact workflow.
STAGE 01 — STRUCTURE
Deciding who could do what
Before any screen got designed, a harder question needed an answer: with eight groups touching the same ticket, who should be able to do what, and when? Giving everyone equal access invites chaos. Locking everything down creates bottlenecks. The answer was five permission tiers that stack depending on a person’s role.
PROCESSOR
Re-types a ticket if needed, assigns it to the right resolver, and updates it as work happens.
VALIDATOR
Double-checks a resolver’s fix before a ticket is allowed to close.
APPROVER
Approves or rejects a request — mainly change requests that need sign-off before work starts.
RESOLVER
Does the actual fix — changes status, adds attachments, notes, and replies as work moves along.
DATA ANALYZER
Sees ticket metrics, dashboards, and reports — without needing to act on individual tickets.
COMMON
What every role gets by default — create a ticket, edit it, view it, leave notes, ask for approval.
Business Users & Managers
Approver
Viewer
Data Analyzer
Creator
Business Analysts
Viewer
Creator
Program Managers
Viewer
Processor
Approver
Data Analyzer
Creator
IT Employees
Approver
Viewer
Data Analyzer
Creator
QAs
Validator
Viewer
Creator
Support Team
A mix of everything above — the safety net role
Developers
Resolver
Viewer
Creator
Tech Leads
Viewer
Processor
Creator
STAGE 02 — LISTENING
Finding out what was actually broken
Interviews ran in two rounds — first with the people who create and process tickets day to day, then with the program managers overseeing them. Every piece of feedback got sorted into named themes rather than treated as a one-off complaint. That’s where the real patterns showed up.
04
Support & Knowledge Management
“Someone solved this last month. Where’s the record?”
03
Ease of Use & Accessibility
“Why does this take five clicks?”
02
Workflow & Process Clarity
“What actually happens after I hit submit?”
06
Integration & Contextual Support
“Why am I explaining this over email again?”
05
Performance & Monitoring
“How is my team actually doing?”
08
Workflow & Approval Management
“This has been sitting with a manager for a week.”
07
Resolver Collaboration & Assignment
“Who’s actually working this, and can I help?”
01
Ticket Tracking & Visibility
“Where is this ticket, and who actually has it?”
“
There’s no reliable way to search by ticket number.
“
I get asked for feedback on tickets that were never mine.
“
Every escalation means explaining the backstory again.
“
A ticket says “closed” — nobody recorded when, or how.
“
I can’t attach a screenshot when I’m writing up an issue.
STAGE 03 — EMPATHY
Designing around a real person, not a checklist
A composite drawn from the creator and processor interviews — built so every downstream decision had a face attached to it, instead of an abstract “user.”
PERSONA — CREATOR GROUP
The Business Analyst
Bridges business needs and technology solutions — turning colleagues’ requests into clear, trackable tickets, and relying on reports and dashboards to keep an eye on how things are actually going.
ALSO WANTS
Exportable, shareable reports
Modern technology without odd limitations
NEEDS FROM THE PRODUCT
A simple, intuitive interface
Real-time status updates and alerts
A full audit trail — who changed what, when
GOALS
A faster, simpler way to raise and monitor tickets
Tickets that are easy to search and trace
Less dependency on IT for routine permission changes
Timely updates, in-app and by email
PAIN POINTS
Struggles to track down the right ticket details
Key information isn’t organized in a logical order
Helping others with routine tasks eats into her own work
Too many notifications for tickets that aren’t hers
STAGE 04 — THE JOURNEY
Mapping what actually happens to a ticket
Five stages, common to every ticket type — though not every ticket takes the same path through them.
4
Resolution
The resolver — usually a developer — does the actual fix.
3
Approval
Change requests pause here until a manager or the business signs off.
only when required
2
Processing
Based on how serious it is, the system routes it to the right team for a first look.
5
Closure
The creator, or the system, confirms the job’s done and closes it out.
1
Creation
Someone hits a wall and logs it — what happened, which application, which part of the business.
STAGE 05 — STRUCTURE
Turning a wall of feedback into a feature list
Every idea from the research got sorted into named piles first. The piles that held up became the backbone of the product’s structure.
THE SHAPE THAT EMERGED
Progress Stages
Reports & Analytics
Ticket Management
Access & Permissions
Search & Findability
Help & Support
Notifications
Usability & Accessibility
Integrations
Dashboard
DRAFT — GROUPED BY INTENT
UI Design
An intuitive layout that surfaces the most important information first.
System Scalability
A backend built to grow, and reusable front-end components.
Technical Features
Comments, replies, email previews, linked tickets, a real text editor.
Design Language
Consistent branding and plain, jargon-free UX copy throughout.
FINAL — WHAT THE PRODUCT DOES
Ticket Management
Create, edit, view — with linked parent & child tickets
Global Search
Find a ticket by number, every time
Notifications
In-app and by email, sent to the right people
Reports & Ticket Metrics
Exportable, shareable, always current
Help & Support
Guidance built into the flow, not bolted on
Login & Dashboard
One home base for every role
Stage 06 — Proof
Testing the design against real tasks
Three everyday jobs, walked through step by step, to check the design held up outside of a diagram.
Scenario 02
Checking on a ticket you raised
Open overview
Find your ticket
Review details
Close
Log in
Scenario 03
Reporting on tickets
Open ticket reports
Apply filters
Export
Done
Log in
Scenario 01
Reporting a problem
Check dashboard
Create ticket
Add details
Submit
Track it
Close it
Log in
Outcome
What made it into the design
Honest status at the end of the process — most of the core experience was designed and validated. One piece was still in motion.
Create / edit ticket
Ticket Management
Done
Ticket list
Ticket Management
Done
Dashboard
Done
Notifications
Done
View ticket details
Ticket Management
Done
Help & Support
In progress
Global search
Done
Login
Done
Reflection
What this project reinforced
03
One system beats six tools
Most of the friction people described wasn’t about any single tool being bad. It was about needing several of them to do one job.
02
Listening twice mattered
The second round, with program managers, surfaced a completely different set of frustrations — mostly around approvals and oversight — than the first round did.
01
Permissions are a design problem
Deciding who could act, and when, shaped almost every other decision in the interface — long before a single screen got drawn.