Rock Gomes

Customer Service Back-office

Inbank · 2024 · internal tool

Inbank was growing fast and launching new Hire Purchase products. The back-office that its support team used every day did not fit the new products. As Inbank's first in-house designer, I redesigned it from scratch: one clear, modular tool that helps agents work faster and has room for the next product.

role
Senior Product Designer, Inbank's first in-house designer. Owned it end to end: audit, research, UX, UI, components, reviews of the build.
context
Inbank's 2024 restructuring and new Hire Purchase products. Used all day by support agents and their team leads.
made
A map of the old tool, interviews, a moodboard, a modular component set, the core back-office screens.
tools
Figma, Mixpanel

problem

Screens were added one at a time, with no shared patterns. The tool was hard to learn and easy to misuse, and the new products did not fit.

decision

Rebuild it from a small set of parts: data cards, tables, status pills, side panels and one search. So a new product reuses the same screens with its own data.

result

Key screens shipped, including flows for the new product lines. Layouts are predictable and new agents learn the tool faster. No numbers I can share.

The customer page after the redesign: data in labelled cards, Contracts and Offers tables, three menus at the top, and the global search open.
The customer page, before and after. The old page is blurred to hide customer data. Six coloured buttons became three menus.

Three decisions I would defend

what makes the tool faster to use

decision 1 of 3

Records open beside the customer

An agent on a call often needs a contract or an application while the customer’s details stay in view. So a record opens in a side panel over the customer page. When the agent closes it, they are back where they were.

The customer page with a credit application open in a side panel on the right: product, identification and contact details.
A credit application open in the side panel, with the customer page still behind it.

decision 2 of 3

Every status sits next to its fix

Problems show as status pills at the top of the record: Unsigned, Unidentified, Required. The action that fixes each one sits on the same line, like Identify or Check PEP, so the agent always sees the next step.

A contract page: Unsigned, Unidentified and Required pills next to the title, and an Identify link next to the customer status.
A contract: three statuses next to the title, and Identify next to the customer status.

decision 3 of 3

One search for every number

Customers call with whatever number they have: an ID code, a contract, an account, a username. One search box takes all of them, and each result shows what it matched.

The global search open: two customers named Sirje Tamm, each with an ID code, account numbers and a username.
The global search: one query finds the customer by ID code, account numbers and username.

How I got there

the process, short

audit

Map every screen before drawing one

I listed every screen of the old tool and tagged each part: a table, a state, an action, a filter or a pop-up. The same few parts appeared on every screen. These parts became the component list.

A map of the old back-office: Billing, Contracts, Customers, Home and Offer screens, each part tagged as a table, state, action or filter.
Part of the map: each screen with its tables, states, actions and filters.

research

Ask the people who use it, then check the data

I interviewed the people who use the tool or work on it. Mixpanel showed which screens and actions they used most, so I redesigned those first.

  • support agents
  • team leads
  • product managers
  • developers

visual direction

A moodboard before the screens

Before any screen, I made a moodboard that followed Inbank’s new visual identity. I used it to set the tone, the hierarchy and the level of consistency early.

A moodboard of about twenty dashboards, tables, search panels and profile pages.
The moodboard: data-heavy tools with a calm, clear hierarchy.

delivery

Work with the developers during the build

I had weekly syncs with the developers and reviewed each build. When a technical limit came up, I changed the design. Several key screens shipped, including flows for the new product lines.

Shipped back-office screens on a purple background: a contract on desktop and tablet, a customer page with a side panel, the search, and four cards.
Shipped screens: a contract, a customer with a credit application open, the search, and the parts they share.

The parts behind it

one set of parts for every product

components

A set of shared parts

The parts are flexible tables, customer data blocks, status pills, action panels, and search and filter patterns. Each part works with different products and data, so a new product line mostly reuses them.

Back-office parts: Identification, Contact and Additional info cards, a Reminders table, an Attachments table and a Payment schedule.

What changed

the outcome, and what I learned

outcome

  • Faster daily work through predictable layouts and patterns
  • Easier onboarding for new support agents
  • A shared component set that speeds up new features
  • Better visibility for managers and operations
  • No numbers I can share yet

what I learned

  • Internal tools deserve the same design care as the product customers see.
  • Next: usage data to find problems, usability tests with agents, more parts for new use cases, and automation for repetitive tasks.

next case study