ISP Website Redesign
I turned a complex provider website into a conversational experience that guided customers to the right service. After launch, connection requests increased by 130%.
Users came with a question.
The website gave them a catalogue.
The website gave them a catalogue.
The old website contained the necessary information, but its structure reflected the company rather than the customer’s intention.
ISP websites often try to explain everything at once: technologies, speeds, tariffs, promotions and corporate services.
Krelcom’s old website followed the same pattern. Years of content had accumulated without a clear hierarchy. The information was technically there — but finding it required understanding how the provider had organised its business.
Krelcom’s old website followed the same pattern. Years of content had accumulated without a clear hierarchy. The information was technically there — but finding it required understanding how the provider had organised its business.
I recognised the same pattern from previous projects with internet providers. Search phrases, Webvisor recordings and recurring support requests confirmed it: most visits began with a specific task, not an interest in the company’s service catalogue.
Customers did not think in those categories.
They came with much simpler questions:
They came with much simpler questions:
People did not come to study internet provider. They came because they needed internet at home.
The problem was not missing information. The website already contained the information customers needed. The problem was that its structure reflected the provider’s services rather than the customer’s situation.
Visitors had to understand telecom terminology, identify the correct section, and decide what to do next before the interface could help them.
The redesign therefore focused not on adding more information, but on changing how customers reached it.
Visitors had to understand telecom terminology, identify the correct section, and decide what to do next before the interface could help them.
The redesign therefore focused not on adding more information, but on changing how customers reached it.
What if every page could answer first?
The homepage was not the only way into the product.
Someone could arrive from search directly on a tariff, payment, promotion or support page. Wherever the visit began, the website needed to recognise the likely question and offer a short path to the answer.
That became the central product idea.
Someone could arrive from search directly on a tariff, payment, promotion or support page. Wherever the visit began, the website needed to recognise the likely question and offer a short path to the answer.
That became the central product idea.
Every important entry page should surface the actions users are most likely to need there.
The homepage prioritised connection requests. A tariff page helped users compare plans. A payment page led directly to topping up an account. Support-related pages surfaced contact options and service updates.
Instead of forcing everyone through the same navigation tree, the interface responded to the context of the visit.
Instead of forcing everyone through the same navigation tree, the interface responded to the context of the visit.
The assistant changed its suggestions depending on the page. The interaction model stayed consistent while the actions remained contextual.
The assistant was not decoration
I had already designed more conventional websites for other providers. Krelcom initially expected something similar.
I wanted to test a different hypothesis: what if the website stopped presenting services and started answering questions?
I wanted to test a different hypothesis: what if the website stopped presenting services and started answering questions?
The robot was not a mascot added to the website. It was the website’s way of asking: “What are you here to do?”
Bright colours made the provider recognisable. Rounded forms and conversational messages softened an otherwise technical service. Emojis helped distinguish actions at a glance.
Most importantly, the copy stopped sounding like provider documentation.
Most importantly, the copy stopped sounding like provider documentation.
A shortcut — not a chatbot
The concept looked conversational, but it was not a chatbot.
Krelcom had a large information architecture serving private customers, businesses, operators and property developers. A short dialogue could not replace all of it.
Krelcom had a large information architecture serving private customers, businesses, operators and property developers. A short dialogue could not replace all of it.
Instead, the assistant became a fast layer above the full website.
Common tasks were exposed as quick actions. Less frequent content remained available through the menu, navigation and footer. The complexity did not disappear — it moved behind a simpler first interaction.
Common tasks were exposed as quick actions. Less frequent content remained available through the menu, navigation and footer. The complexity did not disappear — it moved behind a simpler first interaction.
The assistant handled frequent intentions. Traditional navigation preserved access to the full service structure.
The shortest path led to the main business goal
The client’s priority was clear: more customers should apply online instead of calling or visiting an office.
The old application form contained too many fields and did not always work reliably. Yet the company did not need every detail immediately. It needed a contact and permission to continue the conversation.
I reduced the first step to a phone number. After submission, a manager contacted the customer and collected the remaining information. This moved effort away from the visitor and into a stage where the company could help.
I reduced the first step to a phone number. After submission, a manager contacted the customer and collected the remaining information. This moved effort away from the visitor and into a stage where the company could help.
This became the strongest application point on the website — both after launch and in later Webvisor observations.
Coverage became part of the application flow
Availability depends on the customer’s exact location, so the website also needed to answer the most practical question: “Can you connect my home?”
- Enter an address.
- See whether it is within the coverage area.
- Continue directly to the connection request.
Users entered an address and saw their location within the coverage area. If the service was available, they could apply immediately. If not, they received a clear answer instead of searching through coverage descriptions or calling support.
The checker worked well in the original version because it was easy to discover and connected directly to the next action.
The checker worked well in the original version because it was easy to discover and connected directly to the next action.
Tariffs without making customers decode telecom
Tariff pages had to serve different cities, buildings and connection types. I made location and housing type visible filters, then brought price and speed to the front.
The selector simplified comparison, while city and housing filters narrowed the plans available to a specific customer.
A compact tariff picker let users adjust their preferred internet speed and television package. The interaction was simple, but one product challenge remained: many customers did not know how many megabits they actually needed.
The interface could make speed easier to select. It could not make the number meaningful on its own.
The interface could make speed easier to select. It could not make the number meaningful on its own.
Designed for the device customers actually used
I designed and checked the main scenarios as interactive mobile prototypes, then continued observing them after launch.
The assistant model translated naturally to a small screen: one message, one decision and one action at a time. The mobile version preserved the application form, tariff selection, address check and full navigation without turning the page into a compressed desktop layout.
This decision remains relevant today: 73% of current visits come from smartphones.
The launch proved the direction
According to the client’s internal data, connection requests increased by 130% after launch. The company did not introduce paid advertising during the measured period.
Analytics have shown that the new interaction became more effective as the website settled into use:
The numbers supported the same conclusion: when the website made the next action obvious, more visitors completed it.
Analytics have shown that the new interaction became more effective as the website settled into use:
- the share of visits with a successful form submission increased by 27% between the first two full months;
- the bounce rate decreased by 42% over the same period.
The numbers supported the same conclusion: when the website made the next action obvious, more visitors completed it.
The website stopped asking customers to understand its structure — and started helping them act.
Then the shortcuts started turning back into navigation
The website did not stay frozen after launch. The client took over its development and continued adding services, messages and quick actions.
Each addition answered a real business request. Together, they gradually weakened the original hierarchy.
The assistant accumulated around fifteen shortcuts. Long operational messages appeared before tariff content. Some pages moved away from the original visual and interaction rules.
The coverage checker had worked in the initial version. Once it became buried beneath additional actions, users stopped finding it. They began asking the operator to check an address or submitted a general application instead.
Each addition answered a real business request. Together, they gradually weakened the original hierarchy.
The assistant accumulated around fifteen shortcuts. Long operational messages appeared before tariff content. Some pages moved away from the original visual and interaction rules.
The coverage checker had worked in the initial version. Once it became buried beneath additional actions, users stopped finding it. They began asking the operator to check an address or submitted a general application instead.
Before:
A small set of actions reflected the most frequent intentions.
After:
Too many actions competed for attention, making the important ones harder to recognise.
Current Webvisor recordings show the difference clearly. Focused service pages still guide visitors toward tariffs and applications. On the overloaded homepage, people are more likely to scroll past the quick actions, move to another section or leave without acting.
The problem is no longer missing information.
It is missing prioritisation.
It is missing prioritisation.
A living product needs rules for growth
The original concept was built on a simple principle: show the most likely answer first and keep the rest available behind it.
To preserve that principle, I would now introduce explicit governance:
I would also evolve tariff selection beyond speed numbers. The existing slider is easy to use, but customers still need help understanding which speed fits their life.
In later telecom projects, I tested a stronger approach: a short quiz based on real activities — remote work, streaming, gaming and the number of connected devices. It gives customers something they can recognise instead of asking them to interpret megabits.
The next step is translating technical speed into everyday needs.
What I learned
Krelcom showed that an unconventional interaction model could work for a large service website. It made frequent tasks visible, shortened the path to an application and helped move customers from calls and office visits toward online self-service.
It also revealed the condition behind that success: simplicity requires discipline
A product can keep adding information and still remain useful — but only if every addition respects the hierarchy that made it understandable in the first place.
It also revealed the condition behind that success: simplicity requires discipline
A product can keep adding information and still remain useful — but only if every addition respects the hierarchy that made it understandable in the first place.
Simplifying a complex product is not a one-time design decision. It is a rule the product must keep following as it grows.
@ann_fatalieva