Energia cut rewards support tickets by 80%

The situation

The warning sign was not just an old interface. When a customer could not access Energia Rewards, the operating team often learned about it through a support complaint. The WordPress platform had reached its practical limit: it went down too often, the admin experience made routine work frustrating, and the team could not reliably see whether daily customer files had arrived.

A visual refresh would have left those failure points in place. And a migration done badly has its own failure mode: the customer does not experience it as a software change. They experience it as a business forgetting a promise, the new system showing zero where their history should be.

RaftLabs rebuilt the original product in 10-12 weeks and has continued working on it since. The migration covered roughly 500,000 registered users plus linked reward, redemption, competition, and activity records, treated as records to reconcile rather than decorative elements to recreate. After launch, support tickets dropped by 80%, downtime became rare, and server and maintenance costs fell significantly. In 2023, Energia Rewards received the Irish Loyalty Awards' Customer Experience of the Year award, an award for the complete program rather than the rebuild in isolation.

The decisions that made the rebuild work

• The real brief was bigger than a redesign

  The original request included a modern interface and a better admin experience. Discovery showed that the visible design was only one symptom. The deeper problem was operational: WordPress had reached its limit for a rewards program of this size, outages were too common, campaign management was constrained, and failed customer feeds were difficult to diagnose.

  That changed the job from a reskin into a platform replacement. The delivery team included two developers covering frontend and backend, a senior engineer, a project manager, and QA. The initial rebuild shipped in 10-12 weeks under a fixed scope, followed by an ongoing engagement.

• Migrate half a million users without losing their history

  The migration covered roughly 500,000 registered users and the records that made those accounts useful: rewards, redemptions, competitions, and activity history. The old WordPress/MySQL schema and the new PostgreSQL/Hasura model were materially different, so a one-shot data copy would have been difficult to verify or recover.

  RaftLabs used idempotent scripts organized by domain. A failed batch could be rerun without creating duplicate records. Eleven additional remediation scripts handled duplicate emails, letter-case mismatches, unmatched energy accounts, and registrations that had stopped partway through. Rich-text content also had to be converted from HTML into the new editor's structured JSON format.

  For a comparable database migration, row counts are only the first check. Identity, account segment, reward history, redemption state, and unresolved exceptions all need their own reconciliation rule.

• Give existing users one clear sign-in path

  The legacy platform stored WordPress password hashes; the new system used Amazon Cognito. RaftLabs implemented a first-sign-in migration flow that attempted to validate an existing credential before creating the Cognito profile. If validation failed, the customer followed the password-reset path.

  AWS documents the underlying pattern in its Cognito user migration guide. The important product decision was not to promise that every legacy credential would work. It was to keep one understandable login journey, preserve the successful credentials, and provide a clear recovery route for the exceptions.

• Detect missing customer files before customers felt the failure

  Energia supplied four recurring files: domestic joiners, domestic leavers, commercial joiners, and commercial leavers. The rebuilt platform collected and processed them on a schedule, restored history for eligible returning customers, and recorded whether each expected file had arrived.

  The monitoring layer made the difference. When a feed was missing, the admin team received an alert instead of discovering the problem through an account-access complaint. After launch, support tickets fell by 80%. This figure comes from the client and project team's support records; the underlying ticket volumes remain confidential.

• Prove the platform could absorb campaign traffic

  A campaign email to roughly 120,000 users could concentrate thousands of visits into a short window. Load testing therefore covered both pre-login and authenticated journeys, with particular attention to Hasura and database bottlenecks.

  The test environment reached 10,000 requests per second and met a target of 29,000 requests in five minutes. During the promotional period, the production platform handled roughly 2,000 logins and 200 registrations while CPU usage stayed below 5%. Since launch, downtime has been rare and server and maintenance costs have fallen significantly.

1. Registration connected a person to the right utility account

   Customers register with an Energia account number and verify by email. The flow distinguishes domestic and commercial accounts so each person sees the rewards and competitions available to their account type. Returning customers can recover their recorded history when they become eligible again.

   

2. Joiner and leaver files updated access on a schedule

   A scheduler collects the four SFTP files and processes changes for both account types. New customers gain access, leavers are deactivated, and re-enrolled customers regain their prior history. The admin team can see the status of each transfer without opening the server or waiting for a complaint.

   

3. Rewards and competitions shared one administration surface

   The customer dashboard presents partner rewards, redemption instructions, and competitions. Admins can configure instant-win and question-based competitions, group activity into campaigns, issue different coupons, and review participation. Energia's public page confirms that the program offers discounts and rewards from major and independent retailers.

   

4. Dashboards and alerts supported the people running the program

   Metabase dashboards show registrations, logins, redemptions, and competition entries. Operators can filter by date, account type, reward, competition, or campaign, then export the result. Alongside the file-status view, this answers two different questions: how customers are using the program, and whether the data operation behind it is healthy.

   

1. Customer data

   Energia account systems

   Domestic and commercial joiner and leaver files supplied the recurring eligibility changes that determined who should gain, lose, or regain access.

3. Processing and identity

   Scheduled sync and Cognito

   Scheduled processing validated the customer files and applied account changes. Cognito handled the first-sign-in credential migration and password-reset fallback.

5. Loyalty data core

   PostgreSQL and Hasura

   The platform stored customer profiles, rewards, redemptions, competitions, campaigns, and activity records in a structured model exposed through Hasura.

7. Experience and operations

   Customer app, admin, and reporting

   The customer and admin applications used the shared data core, while Metabase dashboards and file-status alerts exposed participation and operating health.

How it runs

Next.js

Next.js powers the customer-facing rewards application. It gave the team a faster, mobile-friendly interface and a maintainable application structure without carrying WordPress into the new platform.

Hasura and PostgreSQL

PostgreSQL stores the structured customer, reward, redemption, competition, and activity data. Hasura exposes that model to the customer and admin applications while supporting live operational views.

AWS Cognito

Cognito became the identity service. A first-sign-in migration attempted to validate the existing WordPress credential, with a password-reset route for credentials that could not be migrated.

AWS Amplify Gen 2

Amplify managed the standard AWS services, while custom CDK constructs gave the team control over Hasura, storage, networking, and environment parity. The result was lower infrastructure and maintenance overhead without giving up control of the production architecture.

Metabase

Metabase gives non-technical operators filtered views of registrations, logins, redemptions, competition entries, and campaigns without requiring a separate custom reporting product.