PICLO
PM │SD │ B2B │ ENERGY
National Grid Market Integration
The Problem
Piclo customers already had access to a number of flexibility markets within the UK. However, certain markets, such as those run by National Grid Energy Distribution (NGED) were only run on their proprietary auctioning platforms.
Instead of asking NGED to run their auctions through Piclo we endeavoured to implement a full market-to-market integration. This would allow NGED to continue running their markets within their own platforms, and the integration would automatically synchronise market data so that Piclo customers could participate.
This had never been done before at Piclo, and would become a template for all future market to market integrations. I led the service design from the ground up, working closely with engineering and customer success colleagues to ensure end-to-end feasibility.
There was also a key deadline to be made. NGED runs long term auctions in November each year, so the team only had around six months to get the service up and running.
Understanding the Users
I ran weekly requirements gathering sessions with NGED commercial and technical leads. Initially I wanted to build rapport with the team and understand the criteria by which they would deem the project a success.
As to be expected they wanted their workload to be minimally impacted, and so we ensured that data transfer formats and timings aligned with current workflows where possible.
These sessions evolved over time, and had mixed purposes, from reviewing journey flows, UI designs, prioritisation decisions and running test parties.
I also looked to engage with a number of Piclo customers that could help us design the other side of the integration. I reached out to five flexibility sellers who had assets in the NGED operational area, and worked closely with them to ensure the market design and timings also worked for them.
These initial discovery sessions gave me a great foundational understanding of the overarching problem space. There was already a number of disparate journey maps and task flows from across the business, touching on different parts of the end-to-end journey. I felt it would now be extremely powerful to create a service blueprint skeleton, which could become a north star for myself and the team as we moved forward to decide where to start.
Defining a Blueprint
The team at this point had been overwhelmed with the scope of the integration, as it was covering the full end-to-end Piclo journey, and so there were a myriad of places to start.
I pulled all of the disparate threads together a built a barebones service blueprint for the team to coalesce around. This joined the dots between registration, bidding, dispatch and settlement journeys, allowing us to see it all in one place.
From here we could isolate some of the key tasks and flows of the service, mark them as time sensitive or scaling concerns. This blueprint became a core artefact throughout the project lifecycle.
As this integration wasn't just touching digital touchpoints I ensured we had space to account for customer success and NGED related activities. It was also useful to see how much of the service may have to be undertaken manually, as that became a useful metric by which the overall maturity of the service could be benchmarked.
Mapping Scalability Concerns
Now that we understood the broad tasks, journeys and jobs we had to enable we could now properly start to evaluate scaling thresholds. I ran a workshop to, at a high level, draw out where our service may start to hit scaling issues.
This allowed us to cross reference what we though could be done manually for a 0-1 release, versus what could feasibly be done manually without causing operational, and reputational, damage to both the integration and to the business.
After fully mapping our assumptions about how users will be using the service we were able to build a scalability matrix that we were confident in. As you can see above there were only a few parts of the end-to-end journey that could realistically be undertaken manually for a 0-1 release. I could quickly start pulling in customer success colleagues to get them up to speed with those processes, and to write up standard operating procedures so that they could follow robust documentation.
After layering on top of this diagram the expected timeline for the upcoming long term trades we could start to properly sequence upcoming work to hit key milestones. For example, dispatching is vital to be undertaken in an automated fashion. Assets would need to be dispatched within seconds, and could happen at any time, so undertaking it manually would not be feasible, even in a 0-1 scenario.
Settlement on the other hand only happened once a month, so it was far less time critical. Worst case scenario we could run settlement in a 0-1 scenario completely manually, with the intention of automating it as soon as possible.
Designing around Constraints
Although myself and the team designed the service to be as robust as possible there were certain parts of the integration that couldn't be as seamless as we'd like.
As our customers were expecting event dispatch correspondence to come from a Piclo source we identified a potential problem. Although we were sure we could ingest the dispatch trigger message from NGED's platform, we then would need to, within a few seconds, send a corresponding email from the Piclo platform to the relevant customer.
The issue here was that there could be a potential time lag caused by mismatches in contractual obligation data. Although NGED believed this would never occur we wanted to ensure a dispatch instruction was never missed due to integration data mismatches.
We determined it would make sense to override Piclo's regular dispatching services and always ensure we could act as a middle man to an incoming dispatch trigger from NGED. We would then undertake any laborious, and potentially flow breaking, data mapping exercises after we knew the flex provider had received their instruction.
I designed new dispatch emails for this exact purpose, including all of the data we could reliably include within the time constraints. We then had up to a month to fix any data matching issues before settlement had to be undertaken.
Test Run and Feedback
I ran multiple test parties both internally and with the client to ensure everyone was comfortable with the service. Using historic data sets from NGED's data portal. myself and the team could run mock auctions within Piclo to see what they would look and feel like.
I worked closely with NGED to ensure they were happy with how their auctions looked and ran within the Piclo platform. I also ran usability testing sessions with prospective sellers to ensure they understood every facet of the auction. Off the back of this feedback a few of the naming conventions and data ordering was changed to ensure our users were as comfortable with the new market auctions as possible.
Due to the nature of the integration there were certain rules and regulations that could not be enforced by Piclo in an automated fashion. Therefore I wrote robust FAQ and "how to" articles to ensure our customers had all the information they needed before participating.
We also trained an AI chatbot on these documents so that users could ask questions in real time on the Piclo platform.
Release and Key Results
After a successful 0-1 release with a fully engaged flexibility seller, we rolled the service out more widely, inviting sellers to add assets in to the platform that resided in the NGED operational area.
It was extremely rewarding seeing the service hold up as scaling increased from 1-10 and beyond. Customer success, engineering and product colleagues worked together well using my standard operating procedures.
We were able to facilitate NGED's long term trades, and over 30,000 bids came through Piclo, which accounted for over 30% of the overall participation within NGED's market. This amounted to 19GWh of flexibility now available for NGED to call upon.
The success of the new service meant NGED was comfortable also allowing Piclo to run their short term competitions, which were run daily. The partnership between NGED and Piclo was extended to 2027 due to the success of the project.
Outlining a Product Vision
My work designing this service gave senior management the confidence to put me in charge of pulling together a product vision for the company. This involved gathering vision, and strategy, detail from across the organisation to create a set of artefacts that we could rally around as a business.
I built and maintained journey maps of varying levels of abstraction to show which jobs we needed to be catering to, which also helped us keep a repository of key assumptions and bets that could be made in that space.
I also ran value proposition and object modelling workshops to push our thinking in to the future and reimagining our product(s) from the ground up. Using AI I could quickly spin up visionary design prototypes that allowed us to all speak the same language when discussing how the product had to evolve within the next 1-5 years.
