Internal tool
Customer Services Portal
Rethinking order creation in a complex B2B telecom environment.
- Thales
- Product Designer
- 18 months
An order management tool designed with the support teams, adopted without anyone being made to.
- The product: four tools replaced by one, nearly all orders moved over within 6 months, Gold Award in the group's operational excellence programme.
- The research: 26 Customer Service heads interviewed, two in-person workshops, one insight nobody had seen in eight years.
- My role: Product Designer, paired with a UX Researcher, in a team of ten. 18 months.
Nimbus · fictional design system
The AI pre-fills, the CS validates
The pattern that sets the product apart: every field the system fills appears in red, and nothing is validated without being read. Neutral reconstructions: the context, the clients and the design system are invented. No real interface or business rule appears here.
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.
The project
Creating a SIM card order involved four tools: a spreadsheet for tracking, a word processor for the documents, an email client for the customer, an ERP for the system. None were connected. Manual re-entry at every step, no consolidated view.
The knock-on effect showed up elsewhere: salespeople called the CS teams to get a status or fix an error. The CS teams spent part of their day answering questions whose answers already existed, somewhere.
The subject had been identified for eight years. What was missing wasn't the will, but an understanding of the real work fine-grained enough not to deliver yet another tool.
My role
Product Designer, paired with a UX Researcher, in a team of ten (PM, PO, PLM, 5 developers).
She led the research protocol and the analysis. I co-ran the interviews and workshops, translated the insights into design positions, produced all the screens and the handover, and worked with engineering day to day.
The research
26 Customer Service heads worldwide. Two in-person workshops: reconstructing how an order actually gets created, then having them describe the tool they'd want.
The difficulty wasn't getting them to talk, it was getting them to put words to what they did without thinking. Habit makes a gesture so obvious it becomes indescribable. That's what the research setup went looking for.
Three requests came back consistently: fill orders in automatically, stop having to write to clients at every step, keep an overview of orders in progress. A fourth was expected by nobody: the CS teams wanted a channel to pass files to each other without going through email. A need that appeared in no procedure, because it didn't belong to one.
They weren't asking for features, they were describing frustrations in the shape of solutions. My work was to move back from the request to the problem, then design the answer — including when it didn't look like the request.
26
Customer Service heads interviewed worldwide, and two in-person workshops
the subject had been identified for eight years
The key decision
The AI proposes, the CS decides.
The request was automatic filling. The real problem: re-keying purchase orders received as PDFs or on paper, slow and a source of errors that travelled back up to the sales teams.
In 2024, putting a document-reading model into an internal tool was expensive and contested. We defended it as the answer to the single biggest time sink identified in research, not as a gimmick.
The position taken was to refuse opaque automation. The AI pre-fills, and every field it filled appears in red: the system explicitly flags what it assumed. The CS keeps validation end to end. On a telecom purchase order, an undetected error costs more than the time saved.
What this call cost: the CS reads everything. What it gained: she has nothing left to re-key, and the AI additionally checks the client's purchase order for completeness — a use nobody had asked for.
Two more decisions
Three versions for a single journey.
Creating an order isn't a form: it's a tree of cases, each branch existing because a real client demanded it one day. The first two versions failed in testing — users couldn't find their case, or lost the thread. We were looking for the problem in the interface; it was upstream. We had modelled the process from the CS point of view alone, without the constraints carried by the other stakeholders. The third version started from a workshop bringing CS and stakeholders together. That's the one that held.
Making information consultable rather than requested.
The portal connects to the ERP and to the production chain systems: the status of a physical order becomes consultable independently, and each milestone reached triggers a notification to the client. The CS teams no longer relay information the system already knows.
The internal channel spotted in research shipped in beta after the core product, a deliberate trade-off: it wasn't a condition of the migration.
Nimbus · fictional design system
The system proposes, the person keeps control
Three patterns, one principle. Neutral reconstructions: the context, the clients and the design system are invented. No real interface or business rule appears here.
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 moved over to the portal within 6 months, with no obligation to use it: the old system stayed available
and the old system stayed open the whole time
4 → 1
tools replaced by a single point of entry
~50 %
of the CS teams' daily workload now handled in the portal
Recognition
Gold Award
the group's operational excellence programme, among several dozen internal entries
2
product lines are looking at adopting the solution for their own teams
they're looking at it, they haven't moved over
What I take from it
Designing a domain interface for a field you don't know can't be improvised. We didn't get there by putting ourselves in the Customer Service teams' shoes, but by building a setup to go and find what they knew: interviews, workshops, several rounds of co-design before the order journey held. The designer isn't the one who guesses the need — the designer is the instrument that lets users put it into words and make it concrete.