Redesigning an ISP Website When 75% of Visitors Were Already Customers - Iqram Ahmed - UX/UI Expert, Designer, Developer & Team Leader
← All Case Studies
Web · Self-Service Platform 2023

Redesigning an ISP Website When 75% of Visitors Were Already Customers

The website had half a million users. Three quarters of them were existing customers who couldn't do basic things without calling support.

Type Web · Self-Service Platform
Year 2023
Role Design Head · UX/UI Lead · Frontend Oversight
Platform Web · Self-care dashboard
Read 2 min
Project visual

Carnival Internet is one of Bangladesh's largest internet providers with over 500,000 customers. Their website was generating the wrong kind of traffic — not leads, but support calls. Customers couldn't pay bills, compare packages, or check their account status without picking up the phone. Analytics showed that 75% of site visits were existing customers trying to manage their accounts, but the site offered them almost no way to do that independently. The navigation had grown around internal logic rather than user goals. Package information was impossible to compare. The self-care area required hunting through menus to find basic functions. Customer service was absorbing questions the website should have been answering.

Four years of analytics data made the diagnosis clear before any design work started. Visitors split into two distinct groups with almost no overlap — existing customers managing accounts, and potential customers checking coverage and packages. The previous site had been built as if these were the same person with the same needs. They weren't. Once that distinction was clear, the entire information architecture reorganised itself around it. The redesign wasn't about visual improvement — it was about building two coherent journeys inside one site, with navigation and entry points that routed each user type toward what they actually came to do.

We restructured the entire site around four user goals rather than internal page categories: check coverage, browse packages, sign up, manage account. This sounds obvious in retrospect but required dismantling navigation that had been built around the company's internal structure. Every page that existed to serve an organisational need rather than a user goal was either removed or relocated.

The self-care dashboard was redesigned to surface the three things most customers came to do — pay a bill, check usage, get support — without any navigation required. The previous version buried these actions in menus. Making them immediate reduced the volume of support contacts for tasks that should never have required human intervention.

We developed two distinct visual treatments for home and business users while maintaining brand consistency. Mixing them had created cognitive load — customers weren't sure if a package was relevant to them. Separating the experiences clearly reduced drop-off during package selection and increased the completion rate for the sign-up flow.

Frontend development stayed under design oversight throughout the build rather than being handed off after design completion. For a site at this scale — continuously evolving, with seasonal campaigns and new features being added regularly — the component system needed to be built with future additions in mind. That only works if the person who designed the system is involved in how it gets built.

35%

reduction in support tickets as users completed tasks independently after launch

Support ticket volume dropped 35% as customers began completing account management tasks without contacting the support team. Package upgrade rates increased through the clearer dashboard design — customers could see their current plan and available upgrades in the same view. Conversion rates from the purchase flow improved as the path from package selection to sign-up became direct. SEO performance improved as a byproduct of the structural changes — better content organisation and faster load times contributed to increased organic traffic. The site is live and continuing to evolve, with the component system making ongoing updates significantly faster than the previous build.

The analytics data was four years old when we started. It told us what users had done with the old site, not necessarily what they would do given better options. I'd push for a structured discovery phase with current user research alongside the historical data — the analytics told us where people were failing, but talking to users earlier would have told us why, and that would have sharpened some of the early architecture decisions.

Get in touch

If you are working on something
that needs this kind of thinking,
I would like to hear about it.