Taking the service to the meter

A useful task in the customer's pocket

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 a practical opportunity: take the service to the meter. British Gas asked Rufus Leonard to design and develop what became the UK energy sector's first dedicated iPhone meter-reading app. Its first release let customers register gas and electricity accounts, enter a reading and receive confirmation that it had been submitted.

The app processed more than 18,000 meter readings in June 2010 alone. People were not simply downloading it; they were using the service to connect what they did at the meter with what British Gas needed for accurate billing. This was a collective British Gas and Rufus Leonard outcome.

Designing for touch, not desktop

The work began with an expectation that the phone interface would follow the website. That would have transferred a desktop form to a smaller screen without taking advantage of the device or the customer's situation.

I contributed concept designs to Rufus Leonard's original pitch, then worked closely with the senior UI designer to translate the web journey into touch-based interaction patterns. Together we defined how customers moved from registration through submission and recovery.

Apple's exacting but still-emerging Human Interface Guidelines shaped the design and meeting them was a prerequisite for acceptance into the App Store. We used native controls and interaction patterns so customers did not have to learn a new interface while completing an unfamiliar energy transaction.

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. An illustrated Help section explained how to read different gas and electricity meters, including which visible digits to ignore. These details demonstrate the design principle: use the device and the customer's context to make the task easier, rather than reproduce the website.

This reframed the task. The question was no longer simply "How do we fit the website onto an iPhone?"

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?

Connecting the service loop

Although the visible outputs included screens and journeys, this was systems design. The customer's physical meter, the app, the existing website and the billing system all had to work together. The loop began when the customer identified the correct digits and closed only when British Gas accepted the reading and the customer received confirmation.

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

Failure was part of that service, not an exception to it. If connectivity or the British Gas response failed, the app preserved the reading so the customer could try again without returning to the meter. Clear success and failure messages prevented customers from assuming an unreceived reading had reached the billing system.

A bridge to faster rollout

British Gas wanted to launch without adding work for its core information-systems team. Rather than wait for direct access to backend services, the app submitted readings through the existing public website and interpreted the returned confirmations and errors.

This was an operational compromise with a known risk: a substantial website change could break the app even if the underlying service still worked. We contained the 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 strategy got a deliberately narrow but complete service into customers' hands without treating the workaround as a permanent foundation. Customers could identify the reading, submit it beside the meter, recover from failure and know whether British Gas had received it. Direct integration remained the route to more sensitive services and wider account management.

The service moved with the customer

The app was promoted in newspaper and television advertising as part of British Gas’ EnergySmart, a £5 million marketing campaign to help customers understand their energy use and avoid estimated bills. It reached number one in Apple’s iPhone Business chart and remained in the top ten for several months.

The significance was greater than adding another way to contact British Gas. A task previously divided between the meter, a written note and a website or call centre could now be completed beside the meter. Help, account context, submission and confirmation travelled with the customer, making the service part of the task as it happened.

Later versions, developed by different teams, extended that portable service beyond meter reading into balances, bills, payments and consumption history. I did not work on those releases, but they continued the service direction anticipated in the original roadmap.

By 2013, Centrica reported more than one million downloads of the evolved British Gas app. This later scale belonged to the wider teams and releases that followed. This demonstrated the continuity of the transformation: what began as one focused task had become a service customers could carry with them to manage more of their energy relationship.