A modern portal can also significantly improve the quality of customer interactions, take the pressure off the contact centre and reduce the costs of handling repetitive enquiries. This is why choosing the right solution is crucial, particularly when it involves replacing an existing application with a modern solution. The transition to a new portal is a complex and multi-faceted process. It involves not only configuring the new application, but also data migration, transferring user accounts, preparing communications, testing, organising a system downtime, and providing customer support following the system’s launch. It involves not only the software provider, but also the company deciding to implement the modern portal and the customers – the application’s users.

From the user’s perspective, the portal can greatly facilitate communication with the company – particularly in sectors providing electricity, natural gas or district heating, as well as energy-related services. Problems with logging in, unclear instructions or prolonged downtime of the portal can quickly affect the perception of the company as a whole. Therefore, its implementation should be treated not only as an IT project, but also as a significant organisational and image-related change.

Why is a user-friendly customer portal important?

These days, customers expect to be able to sort out most basic matters themselves, without having to make a phone call, send a message or visit a service centre. A modern self-service portal should provide quick access to information, documents, statements and data relating to existing contracts. This is also a benefit for the company – it helps to reduce customer service costs and save resources that would otherwise be spent on lengthy calls with a consultant or chat sessions during which a member of staff has to explain to the customer what to do on the portal.

A well-designed customer portal can, amongst other things:

  • provide round-the-clock access to information and documents,
  • reduce the number of straightforward enquiries directed to the Contact Centre,
  • reduce customer service costs,
  • streamline the submission of requests and documents,
  • support data updates and consent management,
  • improve the quality of communication with customers,
  • build the image of a modern and customer-friendly organisation.

A self-service portal should not merely be the digital equivalent of a traditional customer service office. Its purpose is to simplify processes for both customers and company staff, to build customer satisfaction with the quality of service and, in turn, to foster customer loyalty to the company.

Why is this important? A well-designed customer portal can reduce the number of calls regarding invoices, payments, account balances, meter readings, contract details or the status of service requests. This allows contact centre staff to focus on more complex issues requiring a personalised approach. This is one of the key benefits of modern self-service portals for the utilities sector.

Selecting a new customer portal for a modern utility company

There are many applications available on the market that enable you to set up an online customer service centre. They may offer a user-friendly interface, extensive administrative functions, online payments, access to documents, communication with users, or the ability to integrate with other systems used within the company. The choice is not easy, but it is not the biggest challenge – the greatest difficulty usually lies in implementing such a solution.

The difference between a successful and a problematic implementation is rarely down solely to the number of features. The success of a project is determined primarily by:

  • the alignment of the solution with the organisation’s processes,
  • realistic scheduling,
  • the quality of data preparation and migration,
  • the expertise of the implementation team,
  • cooperation between the client and the implementation team,
  • thorough testing prior to go-live,
  • effective communication with the application’s users – the clients,
  • preparing staff to handle enquiries,
  • a contingency plan in case of problems,
  • support from the technical team after the go-live.

Therefore, the implementation of the portal should be viewed as a comprehensive process of change, rather than merely the installation of a ready-made product. The approach to this is a key process that must be well planned.

Step 1. Defining the scope and designing the user experience

The project should begin by determining which processes and functionalities will be transferred to the new portal. Not all elements of the existing Online Customer Service Centreneed to be replicated exactly. Changing the system provides a good opportunity to assess which functions are actually being used, which require simplification, and which can be replaced by a more intuitive process.

At this stage, the following should be determined, amongst other things:

  • which matters customers will be able to deal with themselves,
  • what data and documents will be available on the portal,
  • how registration and login will work,
  • what information will be provided to users,
  • what functions system administrators will have,
  • which systems the portal will integrate with.

Before starting the actual development work, it is worth preparing interface mock-ups, for example in Figma. These allow the team to jointly verify the layout of individual screens, the sequence of actions and the way information is presented. This enables the application’s user – the client – to evaluate the portal even before implementation begins, and any changes can be made more quickly and at a lower cost.

Step 2. Preparing and organising the data

Data migration is often seen as the technical transfer of records from one system to another. In practice, it is one of the most challenging stages of the entire project.

The existing Online Customer Service Centre may contain:

  • accounts that have been inactive for many years,
  • accounts created multiple times for the same person,
  • out-of-date email addresses,
  • incomplete contact details,
  • accounts not correctly linked to contracts,
  • out-of-date consents,
  • data stored in various formats.

Automatically transferring all records would simply carry these same issues over to the new environment. Therefore, before migration, a list of accounts must be prepared and verified.

The implementation team may identify inactive or potentially duplicate accounts, but the decision to delete them should be confirmed by the data owner. Redundant accounts can then be deleted before the new system goes live. This approach allows work to begin on a well-organised basis, reduces the number of login issues and minimises the amount of data stored unnecessarily.

Good migration practices include carrying out a data inventory in advance, defining data cleansing rules, multi-stage validation, and a post-migration review once the data has been transferred to the target system.

Step 3. Using the change to update customer data

The launch of the new portal may also provide an opportunity for users to verify their details themselves.

When logging in for the first time, customers may be asked to:

  • confirm their email address,
  • check their personal details,
  • accept the current terms and conditions,
  • confirm or update the consents they have given,
  • set a new password.

However, users should not be required to re-enter all the information that the organisation already holds. The process should be as simple as possible and clearly explained.

If the login method changes – for example, if the existing login is replaced by an email address – the customer should be informed of this well in advance. You should also provide detailed instructions on how to log in for the first time and set a new password, and help the customer navigate the entire process.

Step 4. Communication: preparing app users for the change

Even an intuitive portal can cause uncertainty if users are caught off guard by a change.

Communication should not begin only on the day the system goes live. Users should be informed in advance:

  • that work is underway on a new version of the portal,
  • when it will go live,
  • whether there will be any downtime,
  • what changes will be made to the login process,
  • whether they will need to set a new password,
  • where they can find instructions,
  • who to contact in the event of a problem.

Messages should be brief, clear and free of technical jargon. Rather than focusing on migration, configuration or implementation, it is worth explaining exactly what will change from the user’s perspective.

An example message might state that the new portal will be easier to use, provide more convenient access to documents, and that users will need to set a new password when logging in for the first time. A video tutorial could be included to help users understand the new features.

Step 5. Pre-launch testing

Before going live, the system should be made available for comprehensive functional testing.

Testing must not be limited to checking whether individual buttons work. It should cover complete scenarios carried out by real users, e.g.:

  • creating an account,
  • activating an account,
  • first login,
  • resetting a password,
  • accessing documents,
  • submitting a form,
  • updating details,
  • managing multiple contracts by a single user,
  • viewing the system on mobile devices,
  • handling incorrect or unusual data.

It is not only members of the project team who should take part in the tests. It is also worth involving Contact Centre staff and those who deal with customers on a day-to-day basis. They usually quickly spot unclear messages, missing information and scenarios that have not been covered in the standard test case.

The transition to production should only take place after both parties have formally confirmed readiness.

Step 6. Planning the portal migration

When changing portals, it is usually necessary to set a period during which the existing portal will be unavailable or its functions will be restricted.

During the migration window, the following tasks, amongst others, may be carried out:

  • blocking the creation of new accounts in the old Online Customer Service Centre,
  • preparing the final data set,
  • migrating active accounts,
  • removing any remaining duplicates,
  • deploying the production configuration,
  • verifying integration,
  • conducting functional tests,
  • redirecting user traffic to the new application.

The aim is to keep the downtime to a minimum, but its duration should not be the sole criterion. It is more important to carry out the work safely and to ensure that the results can be verified.

During the downtime, a notice should be posted on the portal – informing users of the expected time of service restoration and providing contact details for customers requiring urgent assistance. Depending on the architecture, appropriate redirects may also be implemented.

Step 7. Migration of user accounts

Once changes to the existing system have been locked, the team can begin the actual migration of active accounts.

As new accounts may have been created between the initial database purge and the start date, an additional check is required. The client should identify any inactive or duplicate accounts created during this period, and the implementation team should remove them before the final go-live.

Following the migration, it is necessary to check not only the number of records transferred, but also their quality and relationships. The following require particular scrutiny:

  • links between accounts, users and contracts,
  • email addresses used for logging in,
  • assigned roles and permissions,
  • document history,
  • consent statuses,
  • the ability to regain access,
  • cases where a single user manages several locations or entities.

The migration should not be considered complete simply because the data has been technically saved in the new database.

Step 8. Production launch and rapid testing

Once the features have been implemented and configured for the production environment, randomised tests of the most critical processes should be carried out.

These should cover at least:

  • accessing the portal website,
  • logging in as a migrated user,
  • setting a new password,
  • accessing documents and data,
  • form functionality,
  • sending emails,
  • verification of integration with external systems,
  • the portal’s functionality on mobile devices.

Only once the tests have been successfully completed should the notice regarding the technical interruption be removed and the system made available to all users.

The team should also have a contingency plan in place. This must specify what to do if a critical error is detected, who makes the decision to suspend the launch, and whether it is possible to revert to the previous solution.

Step 9. Preparing the organisation for the first few days

Going live does not mark the end of the implementation. The first few days of the new portal’s operation are usually a period of increased queries.

Even if the system is working correctly, users may need help setting up their passwords, finding documents or understanding the new login procedure.

Therefore, before going live, you should prepare:

  • user guides,
  • a list of frequently asked questions and their answers,
  • pre-prepared responses for the Contact Centre,
  • a procedure for reporting errors,
  • a process for escalating issues to the technical team,
  • additional staff for the first few days of operation,
  • monitoring of support tickets and user behaviour.

Customer service staff should familiarise themselves with the new portal in advance and go through its key features. They must not be left to learn the system only when the first customer calls. The technical team should also be ‘on standby’ during the first few days of the new portal’s operation – they may need to resolve urgent issues or fix technical faults that only become apparent in the production environment.

Step 10. Post-launch support

Following the go-live, it is important to monitor not only the system’s technical availability but also how it is being used.

It is worth monitoring, amongst other things:

  • the number of successful and failed logins,
  • the number of password resets,
  • the most common errors,
  • the number of activated accounts,
  • the workload on the Contact Centre,
  • the popularity of individual features,
  • the number of cases handled via self-service,
  • feedback provided by users and staff.

Based on this information, messages, instructions and interface elements can be quickly improved. The implementation of the portal should not be treated as a one-off project. It marks the beginning of the further development of digital customer service.

The four pillars of a successful transformation of an existing Online Customer Service Centre into a modern customer portal

Based on experience gained from working with numerous utility sector clients, the Connectpoint team has identified four elements required for the effective transformation of an Online Customer Service Centre into a customer portal. These are:

1. A well-suited product

The portal must meet the needs of users, the organisation’s processes and the systems in use. It should be easy to use, secure, efficient, feature a modern interface and be accessible on mobile devices.

2. Proper project planning

The schedule must cover not only development, but also data preparation, testing, communication, migration, go-live and the stabilisation period.

3. Collaboration between the client and a competent implementation team

The supplier is responsible for the technology and organisation of the process, but the system owner knows their users – the clients, the data and the internal procedures. Only active collaboration between both parties enables the right decisions to be made.

4. Post-launch support

The first few days of the portal’s operation require a rapid response, good communication and a readiness to make adjustments. The implementation team should remain available even after the migration has officially been completed.

The customer portal as a process, not just a product

Modern features, an intuitive interface and extensive administrative capabilities form the basis of a good portal. However, they are not enough to guarantee a successful launch.

The system contains customer data, documents and information relating to their billing. The portal is used by end users, so any downtime or ambiguity is immediately visible outside the organisation.

This is precisely why it is worth choosing a partner who not only provides the right technology, but also has practical experience of working with similar clients and is able to guide the organisation through the entire process: from needs analysis and the preparation of mock-ups, through data organisation and communication with users, right through to migration, go-live and post-launch support.

When changing an Online Customer Service Centre, the real value lies not just in the new portal, but in safely guiding the entire organisation through the change process. At ConnectPoint, we combine the development of modern customer service solutions with experience in implementing systems for the utilities sector – backed by dozens of project hours and, above all, the smiles on users’ faces. We help plan the scope of the project, organise data, prepare communication with users, carry out testing and minimise the risks associated with the go-live. If you’re considering upgrading or replacing your current Online Customer Service Centre, let’s discuss how to carry out this process efficiently and with as little disruption to users as possible.