Taking the service to the meter

The challenge

In 2009, British Gas customers without smart meters still needed to submit readings if they wanted bills based on actual use rather than estimates. They could already do this online, but the service was separated from the place where the work happened. Customers had to find and interpret the meter, record the right digits, then transfer them into another channel.

The arrival of the iPhone created an opportunity to bring the service to the meter. British Gas asked Rufus Leonard to design and develop a dedicated meter-reading app. As Senior Information Architect, I shaped the interaction model from the original pitch through engineering delivery, working with the senior UI designer and iPhone engineers.

What I uncovered

The work began with an expectation that the phone interface would follow the website. Working through the journey with the senior UI designer and engineers showed why the customer's situation needed to shape the experience: entering a reading was only one part of completing the task.

Customers first had to identify their gas or electricity meter and know which digits mattered. Different meters required different reading formats. A small touch screen also required different controls and interactions from a desktop form, within Apple's still-emerging Human Interface Guidelines.

Tracing submission through the existing web journey exposed another dependency: entering a reading did not mean British Gas had received it. Connectivity or a service response could fail, leaving the customer uncertain whether to retry. The physical meter, phone, website and customer systems had to be understood as one connected service.

Delivery had its own constraint. British Gas wanted to launch without adding work for its core information-systems team. The first release therefore needed a viable route through existing services, with clear boundaries on what that route could safely support.

The reframing

The brief had started with translating a web journey onto an iPhone. The more useful framing was to support the whole task where it happened, from identifying the correct digits to knowing that British Gas had accepted the reading.

How could we let a customer move confidently from the physical meter to an accepted billing input, without losing context or being left uncertain about the result?

That made task completion, confirmation and recovery the organising principles of the design. Success depended on the interaction at the meter and the response from British Gas working together.

One of Karen’s many strengths is engaging with stakeholders and the ability to question and reshape requirements accordingly.

What I changed

Designing for the customer at the meter

I contributed concept designs to Rufus Leonard's original pitch, then worked closely with the senior UI designer to define touch-based journeys from account registration through submission and recovery. We used native controls and interaction patterns so customers could concentrate on the energy task.

The meter-reading control showed the right number of dials for the customer's meter and reopened at the previous reading, reducing the effort needed next time. Illustrated help explained how to read different gas and electricity meters, including which visible digits to ignore.

Connecting submission, confirmation and recovery

I co-authored the functional specification linking the customer journey to data, system responses and failure states, then worked with Rufus Leonard's engineers to carry that behaviour into delivery. Design and engineering had one reference for how the service should behave.

If connectivity or the British Gas response failed, the app preserved the reading so the customer could retry without returning to the meter. Clear success and failure messages distinguished an accepted reading from one that had not reached the service.

Choosing a viable first release

To launch through existing services, the app submitted readings through the public website and interpreted its confirmations and errors. This was an operational compromise: a substantial website change could break the app even if the underlying service still worked.

We contained that risk by keeping the first release focused, designing for communication failure and placing direct integration on the roadmap. Payments were deferred because their security and data requirements could not inherit the same workaround. The result was a narrow but complete meter-reading service, with a route towards broader account management.

Outcomes

The app processed more than 18,000 meter readings in June 2010 alone. Customers were using it to connect what they did at the meter with what British Gas needed for accurate billing. These were collective British Gas and Rufus Leonard outcomes.

Promoted through British Gas' EnergySmart campaign, the app reached number one in Apple's iPhone Business chart and remained in the top ten for several months. The service brought help, account context, submission and confirmation together beside the meter.

Later versions, developed by different teams, extended the service into balances, bills, payments and consumption history. By 2013, Centrica reported more than one million downloads of the evolved app. I did not work on those releases, but they continued the service direction anticipated in the original roadmap.

The evidence demonstrates use of the original meter-reading service and later expansion of the app. It does not quantify how much the original interaction design improved billing accuracy or reduced customer effort, and the later scale belongs to the wider teams and releases that followed.