From paper notes to auto-logged calls
The interaction panel is the core mechanic of CSRD, a desktop for telecom call-centre operators. It took five versions to turn a form people avoided into a panel that does most of the logging for them.
Existing problems
Poor interaction logging
Categorisation was so complicated (up to 5 levels) that operators selected ‘Other’, left the description blank, or wrote notes on paper and filled them in at the end of the call or after the shift.
Manual search for everything
To identify the customer, one operator had to check 7 systems, going from finding the caller through to linking the ticket or service.
An app per channel
Chat, email, SMS and calls lived apart and were tied to the customer by hand.
Caller ≠ customer
A caller may only represent the account owner, which changes what can be shared or done — and the UI didn't show it.
One account at a time
Updating a previous interaction meant a new browser tab and lost context.
Impact
User profile
Initial state
- Not automated at all, with three mysterious buttons — Ticket, Dispute, Retention — though a dispute operator never does retention.
- No object linking, so details went to notes — or paper.
- Tickets created by hand, adding to after-call work.
- Flat subject and category: no deep categorisation, no multiple reasons.
Constraints and context
CSRD is a customizable telecom platform
Business processes at telecom differ a lot, not only for different providers but even for their representatives in dBusiness processes in telecom vary widely, not only between providers but also among their representatives in different countries. So we cannot use a single product without any changes for Telefonica Uruguay and Telefonica Ecuador. That’s why we have a core product and dozens of its variations (integrations) tailored for each customer.
It’s a complex B2B product that requires training
Even with a good UX, the subject domain includes specific terminology, in-company guidelines, and processes to learn.
Long product lifecycle
The company signs a contract for 10 — 15 years and primarily upgrades the product when an upgrade becomes cheaper than support or when the support contract expires.
Lack of user feedback or it’s spread over time
Each company has its own policies on sensitive data. The product lifecycle is long, so we work with data collected at the beginning of the development process and can obtain comparison data only if the company has used the previous version of the product.
Solution
So, based on this features we get the data from 3 main sources: Customers requirements and requests, sales team requests, usability studies results.
To understand is our decision good enough we need to be sure that
- It meets the requirements;
- It affects one or a few following metrics: FCR, AHT, ACW, and operator training time.
Turn the form into a panel
- A narrow panel, detached from the left navigation, that travels with the operator through the whole account.
- Customer info reachable at any step of the interaction.
- Popular reasons on the first screen; multiple reasons, each linkable to a new or existing ticket.
Spoiler: two of these ideas survived to the final version.
The eye-candy version
Sales asked for retention metrics and customer interests so operators could make small talk. We designed a colourful header.
Studies showed 1st and 2nd line don't do retention, interest icons could mean anything, and nobody uploads an avatar when signing a mobile contract. Better to make the call fast enough that no small talk is needed.
Caller vs customer was now visible — but operators had to memorise which one sat on top. Even the design team needed a moment.
Linking via search worked only for billing accounts and products; tickets were still manual.
One operator, several conversations
Parallel interactions: while one caller looks for their last bill, the operator finishes an email with router instructions to another customer — email doesn't need an instant reply — and keeps a few chats going.
Profile photos became initials. There was no reason, and no source, for pictures.
The panel does the logging
Finds the customer. The system searches by phone number and suggests the customer — or, if the caller is a contact person, the customers they represent. One click to accept or decline.
Reasons split from description. Reasons exist to collect service data, so weak spots show up without reading every note.
One field for every level. All nested categories merged into a single search — no need to learn a telco's hierarchy.
Linking is back, with suggestions. Open product A during the call, and it's suggested as related; create or open a ticket, and it's linked to this interaction.
Conclusion
Operators stay with the caller instead of the paperwork.
Where I'd take it next
Categorise via IVR
The caller picks a reason by pressing a number before the operator picks up.
Authenticate automatically
By ID number or secret word, through IVR or voice recognition.
Create tickets at call end
Pre-filled from the reasons and details already logged.
Drop the description
Few fill it in; keep it only where 2nd line must describe reproduction steps.