An internal enterprise platform where call-centre operators, support agents, review moderators and store teams work around the same customers – their orders, requests and reviews.
I designed the platform across its modules, and every role signs in to its own set of sections, depending on their position. This case follows the work around a single customer: the profile, orders, support requests, reviews and signing in as the customer. I translated business requirements into user flows and interface solutions.
Senior Product Designer • 2024 – 2025
The Client Profile gives an operator the full read on a customer in one screen — identity, lifetime value, buy-out rate, bonuses and returns, with risk flagged up front. From here they scan the history across tabs, open a support ticket, and work bonuses, with the record updating live.
Starting with the system, not the screens
My first decision was not to design a single screen.
I started with a design system: 45 semantic tokens for light and dark, type, spacing and radius, 48 components and 61 icons. Each component is documented the way it’s used, with its variants and states, when to reach for it, and a real screen where it lives.
Designing for the operator’s density
Operators live in dense data, so scanning was the whole brief.
Orders is a call queue an operator works through a whole shift. It opens with a strip of live metrics — queue size, overdue calls against SLA, average response time, calls handled — so the state of the shift reads at a glance. The table below packs a lot into every row — client and contact, call time, reason, delivery type, product and price — so heavy data stays scannable.
Every order opens into an action hub — comment, call the client, send an SMS, issue bonus points, decline an item or the whole order — so the operator acts without leaving the queue. Money actions get extra care: issuing a bonus takes a deliberate confirmation step, because in a tool that moves money nothing should happen by accident.
Workspace – a queue of orders and the actions on them
Tickets as cases, not messages
A support request isn’t a chat thread — it’s a case someone owns until it’s resolved. Each ticket shows who opened it and who owns it, when it came in and its review deadline, and the customer’s local time before anyone picks up the phone.
I split communication in two. Comments stay inside the team, including the note passed on from the first line. The reply goes to the customer, by email or published on the site. The resolution lives in the ticket too: call or text the customer, issue compensation, or close the case, or mark it as not needing a reply. The customer’s profile and their other requests are one click away.
Designing for trust
In a tool that touches customers’ money and accounts, every powerful action needs a visible boundary. An operator finds the customer by phone, email or ID and signs in to see exactly what they see. A persistent banner names the customer and offers a one-click exit — there’s no way to forget whose account you’re in.
Theming as a decision, not a coat of paint
Dark mode wasn’t a pass at the end — I built it in from the start.
Color tokens map to component groups, so one change re-themes the whole product in both modes, and operators can switch whenever it eases their eyes on a long shift.
What I take forward
Starting with the system paid for itself many times over: every new module — tickets, moderation, signing in as a customer — was assembled from the same parts and read the same way.
The bigger lesson was to design a platform around the customer rather than around screens: one record everything leads back to, and every powerful action leaving a trace. If I did it again, I’d make the same first move — build the system, then the screens.