A Scalable Route to Energy Certificates for Smaller Buyers

The Opportunity

Schneider Electric served large enterprise buyers of Energy Attribute Certificates (EACs) well. But its model of fewer, higher-value transactions wasn’t suited to smaller companies facing pressure to address their Scope 1 and 2 emissions.

A business case showed growing demand. The challenge was to serve these buyers at scale, beyond the limits of manual processes.

I led product design from discovery through beta, working with energy analysts, buyers, operational stakeholders, suppliers, product and engineering. As the team grew, I shaped product direction and the core experience while guiding the designer’s work.

Finding the Real Constraint

Over six weeks, we held around 12 interviews, workshops and stakeholder discussions to understand buyer needs, market practices and internal operations.

We considered two directions:

1. Adapt Zeigo’s tendering feature to digitise operational sourcing.
2. Create a group-purchasing experience for smaller buyers.

Sourcing wasn’t the main bottleneck. The existing operation handled fewer, higher-value transactions and would struggle to process many smaller purchases. Reaching agreement and securing finance could also slow transactions. Reporting requirements varied by market, so each purchase opportunity needed custom configuration.

Digitising tendering could improve sourcing, but not these wider constraints. Group purchasing offered greater potential: some markets wouldn’t consider a buyer’s volume alone, while combined demand could make purchases viable and unlock bulk pricing. We recommended it to improve market access and price competitiveness while serving more buyers.

Completed orders were the main signal of marketplace activity; large single-buyer orders were a warning that volume alone might not mean buyers were aggregating.

What Buyers Valued

We expected price transparency to matter most. Buyers cared more about knowing their order was progressing and would complete.

Convenience mattered too. Credit card payment let buyers place an order quickly, without arranging a separate purchase order and payment process for a need that might arise only every year or two.

Structuring the Product Around Organisations

As design and technical work progressed, I saw that early assumptions didn’t reflect how organisations buy. Individual and company buyers weren’t separate account types: people placed orders on behalf of organisations.

I introduced a data relationship model to make the product’s structure visible. It linked organisations to users and orders, and orders to purchase opportunities. Organisations could place multiple orders, while each opportunity set a volume limit for its purchase window. These relationships clarified how to track an organisation’s combined volume against that limit.

The model also clarified who could access or act on information, including buyers and internal agents. Knowing where information lived helped us show each person what they needed to make decisions.

Bringing Technology Into Discovery

Before detailed screens were ready, I used simple Figma diagrams to walk through scenarios with product and technology colleagues. We could show what data changed and where, discuss requirements in context, and resolve technical questions earlier than with our previous screen-led approach.

Journey maps showed the sequence of actions; the relationship model showed how their underlying information connected. Together, they gave the team a shared way to discuss requirements and design implications.

Leading Design Through Delivery

I partnered with the product manager on priorities, high-level requirements and the roadmap, aligning them with stakeholders and senior management. The PM coordinated delivery across the sprint team.

I contributed to key purchase paths, validation scenarios and wireframes. The designer developed the detailed experience, aligned it with the portfolio design system and worked with the sprint team on design details and quality. I mentored and reviewed their work, using critique to keep it aligned with the product vision and remove unnecessary complexity.

What the Beta Showed

The beta completed one order from invitation through payment, trade, retirement and evidence. The buyer valued being able to order quickly using a preferred payment method.

This showed the end-to-end transaction could work, but not whether multiple organisations would join an opportunity and complete together. The beta ended before we could validate that group-purchasing hypothesis.

In beta, established commercial arrangements proved difficult to reconcile with open marketplace pricing. The team explored restricting opportunities to invited organisations, but this raised questions about preserving the transparency the product aimed to provide. The work ended before we could validate aggregation or a sustainable operating approach.

What I’d Bring into Discovery Earlier

We focused on a product structure that could scale beyond manual operations. In retrospect, I’d examine the operating model and commercial assumptions alongside user needs and technical scalability—including how the product would work with established ways of serving clients.

I now bring relationship modelling into early product work. Making the structure visible helps product, design and engineering explore the same scenarios, uncover assumptions and build a shared understanding.