Export management for Ovo
Agent desktops
PRODUCT OVERVIEW
We are used to the concept of paying for energy that we use as a household but the concept of being paid for energy you generate yourself is not widely known of. Well this is a growing industry with the need for renewables at the front of everyones mind. Well if you have solar, wind, hydro or anaerobic digestion systems you can be paid for the energy being generated and exported back to the grid.
With the purchase of SSE, migrating a further 100k users and this rapidly growing industry the need for a more sophisticated product to bring and manage these customers as well as all of the data that comes with energy via customer details, installation set ups and Ofgem compliance was needed. The areas to focus were account management, calculation logic and management, a process called levelisation as well as 100s of edge cases.
MY ROLE
Working through features, testing & working hand in hand with users, stakeholders, compliance, product, BA’s and engineers to ensure quality.
DURATION
Majority solo Senior Product designer, 1 other senior product designer (6months to support with migration) 3 Product Manager, 1 Lead Product Manager, 8+ engineers, Delivery Managers, 4 QA’s.
DURATION
2+ years - April 2022 – June 2024
GOAL
Pushing features to cope with the 100,000 users we migrated and £170m processed to our customers yearly
HOW WE GOT THERE
Calculation, payments & levelisation
STAKEHOLDER PROCESS
User Experience Plan + Outcomes
Tasked with creating a plan to tackle some user reported issues which led to millions of duplicative payments
Presenting the initial plan back to the business for how we would reduce errors in the short term as well as thinking about the long term vision.
🐞 Identify bug fixes workshopping with team and spiking effort with engineers
✏️ Map out the customer journeys with users the business & engineering
🧐 Playback short term and long term observations to the business
FINDINGS
Agents had no confidence when calculating and processing payments with ratings of 2/10. They mentioned they were “anxious” and “nervous” to put a foot wrong.
WHAT WE DID
Logic rebuild
ACCURACY, AUDITABLE & TRACIBILITY
Introducing Payment Ledger
Our users, finance and compliance needed a way to see in the interface all payment records for every account that we managed. We discovered that there were 8-10 payment types that we would have to track money received and paid out to our customer base. In addition users wanted the ability to correct balances by creating new transactions such as refunds and recalculations and many more.
Users wanted to be able to manage and understand customer payment history so that they could offer a quick reliable service. Instead of taking away and deep diving through reporting, finance wanted to be able to view any record at any time for reporting. Compliance wanted to ensure accuracy for Ofgem so that we received the correct money to send out to our customers and adhere to all rules and regulations.
We created one view of all transactions for customers that would sit under the account view. Within this view you could see all information about that transaction including dates, amounts, who issued and supportive information so that agents can deal with customers primarily as well as understand exactly what happened when.
PAYMENT LEDGER
Transaction history
A view that allows users to see all transactions that have been made on the account so that agents can self serve better, supply better customer queries and provide up to date account health.
PAYMENT LEDGER
Transaction breakdown
A view that tracks the workings out to how & when the amounts have been generated.
This caters for a variety of customer setups & types and allows activity to be tracked.
PAYMENT LEDGER
Refund transaction or balance
A key requirement to allow agents to serve customers through refunding a specific calculation or the balance.
This even goes as granular as paying set periods within a calculation and has thorough validation checks.
PAYMENT LEDGER
Recalculation
Agents used to struggle fixing the account balances. This functionality allows the ability to recalculate and fix the whole account from a set date.
This will cancel and credit the account with all paid calculations to the latest available read in the system and do a recalculation. Issues such as incorrect readings, tarif changes & errors can generate the need for this.
Previous project
Contact Me
Say Hello
joshandbert94@gmail.com07889484489
Export management for Ovo
Agent desktops
PRODUCT OVERVIEW
We are used to the concept of paying for energy that we use as a household but the concept of being paid for energy you generate yourself is not widely known of. Well this is a growing industry with the need for renewables at the front of everyones mind. Well if you have solar, wind, hydro or anaerobic digestion systems you can be paid for the energy being generated and exported back to the grid.
With the purchase of SSE, migrating a further 100k users and this rapidly growing industry the need for a more sophisticated product to bring and manage these customers as well as all of the data that comes with energy via customer details, installation set ups and Ofgem compliance was needed. The areas to focus were account management, calculation logic and management, a process called levelisation as well as 100s of edge cases.
MY ROLE
Working through features, testing & working hand in hand with users, stakeholders, compliance, product, BA’s and engineers to ensure quality.
DURATION
Majority solo Senior Product designer, 1 other senior product designer (6months to support with migration) 3 Product Manager, 1 Lead Product Manager, 8+ engineers, Delivery Managers, 4 QA’s.
DURATION
2+ years - April 2022 – June 2024
GOAL
Pushing features to cope with the 100,000 users we migrated and £170m processed to our customers yearly
HOW WE GOT THERE
Calculation, payments & levelisation
STAKEHOLDER PROCESS
User Experience Plan + Outcomes
Tasked with creating a plan to tackle some user reported issues which led to millions of duplicative payments
Presenting the initial plan back to the business for how we would reduce errors in the short term as well as thinking about the long term vision.
🐞 Identify bug fixes workshopping with team and spiking effort with engineers
✏️ Map out the customer journeys with users the business & engineering
🧐 Playback short term and long term observations to the business
FINDINGS
Agents had no confidence when calculating and processing payments with ratings of 2/10. They mentioned they were “anxious” and “nervous” to put a foot wrong.
WHAT WE DID
Logic rebuild
ACCURACY, AUDITABLE & TRACIBILITY
Introducing Payment Ledger
Our users, finance and compliance needed a way to see in the interface all payment records for every account that we managed. We discovered that there were 8-10 payment types that we would have to track money received and paid out to our customer base. In addition users wanted the ability to correct balances by creating new transactions such as refunds and recalculations and many more.
Users wanted to be able to manage and understand customer payment history so that they could offer a quick reliable service. Instead of taking away and deep diving through reporting, finance wanted to be able to view any record at any time for reporting. Compliance wanted to ensure accuracy for Ofgem so that we received the correct money to send out to our customers and adhere to all rules and regulations.
We created one view of all transactions for customers that would sit under the account view. Within this view you could see all information about that transaction including dates, amounts, who issued and supportive information so that agents can deal with customers primarily as well as understand exactly what happened when.
PAYMENT LEDGER
Transaction history
A view that allows users to see all transactions that have been made on the account so that agents can self serve better, supply better customer queries and provide up to date account health.
PAYMENT LEDGER
Transaction breakdown
A view that tracks the workings out to how & when the amounts have been generated.
This caters for a variety of customer setups & types and allows activity to be tracked.
PAYMENT LEDGER
Refund transaction or balance
A key requirement to allow agents to serve customers through refunding a specific calculation or the balance.
This even goes as granular as paying set periods within a calculation and has thorough validation checks.
PAYMENT LEDGER
Recalculation
Agents used to struggle fixing the account balances. This functionality allows the ability to recalculate and fix the whole account from a set date.
This will cancel and credit the account with all paid calculations to the latest available read in the system and do a recalculation. Issues such as incorrect readings, tarif changes & errors can generate the need for this.
Previous project
Let’s work together
