User goal
Complete a specific task with confidence, without having to learn the portal’s internal structure.
Telecom · GOL · UX Research
From scattered feedback to a plan for restoring self-service
Research and prioritization to understand why B2B customers abandoned frequent tasks in GOL and turned digital friction into support contact.
01 · The project
The information was there. The path to it was not clear.
GOL is Telecom’s B2B portal for customers with multiple products and contracts. Although it brought together critical tasks—bills, lines, services and claims—an NPS of −14 and open feedback pointed to difficulties completing them without assistance.
What friction interrupted self-service, and what changes could increase clarity and confidence?
−14NPS used as a starting signal, not as an outcome attributable to the project
9customers interviewed in sessions lasting up to 45 minutes
4Customer Service team members in a group workshop
Business goal
Identify opportunities to improve findability, clarity and continuity of self-service.
02 · My contribution
Connecting signals, people and decisions.
As UX Researcher, I designed and led a six-week study with UX, Business and Customer Service. I analyzed existing signals, facilitated a workshop with four support team members, interviewed nine customers and synthesized the evidence into prioritized opportunities.
Research
NPS analysis, open feedback, moderated interviews and journey audit.
Facilitation and synthesis
Support workshop, evidence triangulation and prioritization with the team.
03 · How we approached it
From quantitative signals to the causes behind the problem.
The research combined existing data, support team knowledge and qualitative observation. Triangulation helped distinguish isolated symptoms from consistent patterns.
01
NPS + audit
We reviewed results, open comments and the current journey to build hypotheses about navigation, clarity and performance.
02
Internal perspective
A Customer Service workshop mapped recurring obstacles, likely causes and opportunities observed by support.
03
Interviews
Nine customers with multiple products or contracts completed real tasks and explained their expectations, doubts and strategies.
04
Synthesis
We connected what people said, what the portal showed and what the business received as support queries.
04 · What we found
Four patterns helped explain why self-service broke down.
1. Labels did not anticipate the content
People had to interpret the portal’s logic before finding a task. The problem was not missing information, but how it was organized and named.
2. The home page did not reflect real priorities
Bills, active contracts, lines and claims were recurring tasks, but they were not as visible as users expected.
3. Uncertainty was perceived as risk
When statuses or paths were unclear, people avoided experimenting. They preferred contacting support rather than risk “breaking” something.
4. Digital friction became support contact
When a task could not be completed quickly, the self-service journey stopped and Customer Service absorbed the query.
05 · Recommendations and next steps
The research turned scattered feedback into a prioritized plan.
The main outcome was a shared understanding of the problem: four patterns supported by three perspectives, prioritized opportunities and a defined next experiment. The scope was diagnostic, so no later improvements are attributed without measurement.
Restructure the architecture
Organize categories around mental models and adjust labels to anticipate what users can do.
Prioritize critical tasks
Provide visible access to bills, contracts, lines and claims from the home page and contextual entry points.
Increase clarity
Improve hierarchy, statuses and microcopy to reduce uncertainty during a task.
Validate before scaling
Test the new architecture and navigation with real tasks before moving changes into production.
06 · What I learned
Researching an experience also means looking beyond the interface.
This project changed how I look at friction. I learned that the interface explained only part of the problem: by connecting customer voices, product signals and the support experience, we could understand why uncertainty became contact and guide concrete decisions.
Recommended next step: prototype the new architecture, measure task success and compare the need for support before and after.