One in five cases closed at first touch.

Kaluza is an energy platform used by OVO and other suppliers. When a customer submits a meter reading that looks wrong the platform can't bill against it. It raises an exception for a back office agent to investigate, and over twelve months these added up to 319k, 7.3% of all billing exceptions.

Nearly every one started the same way. The agent emails the customer asking for a photo of the meter, then everyone waits. Seven days allowed for an email reply, fourteen for a letter, often no reply at all, and the account sat incorrectly billed the whole time.

Around 14 days, three agent touches and two emails per exception. With the photo arriving alongside the read, under a day and one touch.

When a customer submits a read they're usually still standing at the meter with their phone in hand. So we asked for the photo right there, inside the journey that already existed, rather than days later by email.

The problem surfaced through the research practice I built, weekly agent sessions running since 2021, mapped onto an opportunity solution tree that hangs off the company's goals. One billing ops agent called the fix before we'd designed anything. We explored and dropped a QR code handoff to the phone camera, parked for complexity, and making the photo mandatory, dropped for a better reason. Sometimes an out of line read is legitimate, and we weren't going to block a genuine reading because the system found it surprising. What stayed was lean. One prompt in the existing flow, shown only when a read fails validation, so 97% of customers never see it.

Kaluza is a platform, so shipping took more than screens. We built a small new photo service behind our API rather than wait on other teams, proved the customer side in the component explorer, put the agent side behind a feature flag, and used the working end to end demo to get OVO to prioritise the release. On the agent side the photo sits on the exception itself. Open the case, open the image, enter the read, send the confirmation.

The work also kept confirming a bigger problem already on the tree, that agents get almost no feedback on what the system is doing, around 375 hours a week of waiting and refreshing across OVO UK. I made the case for a dedicated week on it, which became its own case study, A week on feedback.

I defined the metrics before anything was built. Saving 2 to 3 minutes per exception works out at 7.4 full time agents a year, and every interaction ships tracked in Mixpanel against the event naming convention I'd defined for the team. Ninety days in, the attach rate held around 35%, and about a fifth of photos still couldn't be used, which is exactly where the next iteration points.

In the first week 373 customers attached a photo, 28% of everyone shown the prompt, settling around 35% over the following weeks, with no announcement or promotion at all. Agents found it on their own and started resolving exceptions at first touch. We looked into reading the digits straight from the photo, which would remove the manual entry step altogether, and parked it honestly, a lot of effort for the payoff right now. But none of it is possible without the photos existing in the first place.

• We didn't build a new tool. We asked an existing question at the moment the customer could actually answer it, and that was the whole fix.
• Agreeing the numbers before the build made design decisions easier to settle. We could point at what we were trying to change rather than debate preferences.
• Sometimes the system is wrong and the customer is right. Not blocking a genuine read mattered more than a tidier photo rate.