ILLIANA SAVY
Back to the cases

Internal tool

Customer Services Portal

Four tools replaced by one portal that teams adopted without being required to.

  • Thales
  • Product Designer
  • 18 months

An order management tool designed with the support teams, adopted without anyone being required to use it.

  • The product: four tools replaced by one, 95% of orders placed through the portal within 6 months, Gold Award from the group's operational excellence programme.
  • The research: 26 Customer Service heads interviewed worldwide, two in-person workshops, and a need no one had spotted in eight years.
  • My role: Product Designer, paired with a UX Researcher, in a team of ten.
User researchComplex B2BAI

Nimbus · fictional design system

The AI pre-fills, the agent validates

Every field filled in by the system is flagged, and nothing is validated without review. Reconstruction on « Nimbus », a fictional design system: no Thales interface or business rule.

Reading the document fills in only some of the fields, and flags which ones. What it proposed still needs checking, what it didn't find still needs entering: the person always knows where each value came from.

Client purchase order
PDForder-meridian-march.pdf

Four tools, none connected

Creating a SIM card order took four tools: a spreadsheet for tracking, a word processor for documents, email for the client, an ERP for the system. None of them were connected. Every step meant re-keying data, and no one had an overview.

So sales teams called Customer Services to get a status or fix an error. Part of the agents' day went into finding answers that already existed somewhere.

The problem had been known for eight years. What was missing was an understanding of the real work fine enough to avoid shipping yet another tool.

My role

Product Designer, paired with a UX Researcher, in a team of ten: PM, PO, PLM, five developers.

She led the research protocol and the analysis. I co-facilitated the interviews and workshops, turned insights into design decisions, produced all the screens and the handoff, and worked with the developers day to day.

26 interviews, four requests, one unexpected

26 Customer Service heads interviewed worldwide, then two in-person workshops. The first reconstructed how an order is really created; the second had them describe the tool they wanted.

The hardest part was getting them to put automatic habits into words. We asked a simple question: « If you had a magic wand, what would you add to the tool of your dreams? » The dominant answer: a tool that does the heavy tasks for them, starting with manual data entry.

Three requests came up every time: fill in orders automatically, stop writing to clients at every step, keep an overview of orders in progress. A fourth was expected by no one: a channel for passing cases between agents without going through email. This need appeared in no procedure.

They described pain points in the form of solutions. My job: trace each request back to the problem, then design the answer, even when it didn't look like the request.

26

Customer Service heads interviewed worldwide, and two in-person workshops

the problem had been known for eight years

The key decision: the AI suggests, the agent decides

The request was automatic filling. The real problem: re-keying purchase orders received as PDFs or on paper, slow work and a source of errors that reached all the way to sales.

In 2024, building a document-reading model into an internal tool was costly and contested. The stakeholders backed it as the answer to the biggest time sink identified in research.

With the Customer Services agents and my UX Researcher colleague, we refused opaque automation. The AI pre-fills, and every field it filled is flagged: the system shows what it assumed. The agent keeps validation end to end, because on a telecom purchase order an undetected error costs more than the time saved.

The cost: the agent reviews everything. The gain: nothing left to re-type, and the AI also checks that the client's purchase order is complete, a use no one had asked for.

Two other decisions

Three versions for one journey.

Creating an order means walking a tree of cases, where each branch exists because a real client once required it. The first two versions failed in testing: users couldn't find their case, or lost the thread.

The problem sat upstream of the interface. We had modelled the process from the agents' point of view alone, without the constraints of other stakeholders. The third version came out of a workshop bringing agents and stakeholders together. I designed it, checking with technical teams and AI specialists what was feasible, and what the database made usable. That version held.

Making information self-serve.

The portal connects to the ERP and production systems. Order status can be checked independently, and each milestone reached triggers a notification to the client. Agents no longer relay information the system already knows.

The agent-to-agent channel found in research shipped in beta after the core product: it wasn't a condition for the switch.

Nimbus · fictional design system

The system suggests, people stay in control

Three patterns, one principle. Reconstructions on « Nimbus »: no Thales interface or business rule.

The starting point isn't an empty form but an order already placed, in progress or archived, from which all or some lines are picked up.

Most orders repeat a past one. The journey starts from history rather than from a blank form, including for orders closed several years ago.

Results

Adoption

5% → 95%

of orders placed through the portal within 6 months, with no mandated use

the legacy system stayed open throughout

4 → 1

tools replaced by a single entry point

Recognition

Gold Award

group operational excellence programme, among several dozen internal entries

2

product lines are studying the solution for their own teams

they are studying it, they haven't switched

What I took away

The first two versions of the journey failed for the same reason: we had listened to the agents without the people who constrain their work. An order crosses several teams, and designing it from a single seat only solves part of the problem.

The lesson: bring the people who constrain the process into the very first workshops, alongside the people who use the screen.