When a website has to sell a regulated product: energy pricing before a quote
Most websites show a price. An energy retailer's website has to work one out first.
Before anyone can be quoted, the platform has to establish:
- which meter sits at their address
- which distributor serves it
- which tariffs apply
- which offers may legally be sold in that state
Only then is there a number to put on the screen. That chain runs live, while someone waits on a form.
Everything attached to it is regulated too, from the fact sheet that accompanies every offer to the wording on the offer itself. It is a transaction engine wearing a website's clothes, and it still has to stay editable by the marketing team.
Our part in the work: Drupal architecture and the delivery toolchain
The client is a national energy retailer, selling electricity and gas to households and small businesses across several states and territories. In 2020 it replatformed its public website onto Drupal(Opens in a new tab/window).
We were engaged through a partner agency, which ran the delivery programme, as the Drupal architecture and platform engineering partner, while a specialist design agency supplied the experience design.
Alongside the architecture, we stood up and ran the delivery toolchain the whole engineering team worked through:
- the source-control organisation
- the continuous integration account
- the automated code quality checks
- a containerised local environment so every developer ran the same stack
For a client, that shared setup reads as consistency: every developer on the programme worked to the same checks, whoever they worked for.
The brief itself was easy to state and hard to build: let the marketing and sales teams manage their own offers and content.
5 sign-up journeys, and one of them is moving house
The platform carries 5 separate sign-up journeys, because a household, a home office, a small business and a specialist offer are each sold and priced differently. The main one is a 5-step checkout.
Moving house has its own 7-step flow. Relocating is the highest-intent moment in energy retail, and it asks different questions: when the power needs to be on, and what a technician will find at the property.
That last part is what separates this from an ordinary web form. The output of the funnel is a work order for someone who will physically attend a house.
Around them sit the things regulation requires:
- energy fact sheets issued as part of the flow
- separate concession forms for the states that administer them their own way
- payment handled by dedicated providers
An address is not an address: validating it into a regulated meter identity
The hinge the whole funnel turns on is a translation the customer never sees. Someone types a street address the way they would write it on an envelope.
The platform validates it, then converts it into the shape the national electricity market registry expects, so a typed address becomes a regulated meter identity.
If one meter matches, the journey continues without the customer noticing. If several do, they pick from a short list. Electricity and gas resolve separately.
Everything downstream depends on that one step. Without a meter identity there is no distributor, without a distributor there are no tariffs, and without tariffs there is nothing that can lawfully be sold. It looks like a form field and it is actually the architecture.
Editable by the people who own the offers: a content model marketing can run
Energy offers change often and their presentation is regulated, so the people accountable for the wording need to change it without waiting for a release.
The offer model was built so every element of an offer card is separately editable, and page structure lives in a visual layout builder. Giving the business that control was the stated goal of the replatform, and it is the part that outlasts a redesign.
For a marketing team, that reads as autonomy: changing the wording on an offer is a content edit.
What we carried forward: request logging and integration health
2 ideas from this build have shaped how we approach integration-heavy platforms since.
The first is request-scoped debug logging: when one page depends on a dozen live calls to other systems, you want the story of a whole request in one place, not scattered across log lines.
The second is treating the health of those integrations as a feature, so anyone can see which upstream systems are answering. We have since built that idea into a package of our own.
5 sign-up journeys and a 7-step move-home flow, all hanging off a single address lookup.
Most people picture Drupal as a content site. This was a regulated transaction engine with a content site attached, and the content management was the least interesting part of it.
For platforms where signing up is the product
Everything on this page is 3 of our services running on one regulated acquisition platform: Drupal architecture for a transaction-heavy build, development against live upstream systems, and the delivery toolchain and containerised environments the engineering team worked through.
If you sell a regulated product online, in energy, insurance or telecommunications, this is the shape the engagement takes: an architecture built around the one lookup everything downstream depends on, sign-up journeys designed per customer type, and a content model the business can change without a release. The same engineering is available with AI-assisted delivery where it suits the work.
If your sign-up funnel is the slowest part of your platform to change, or your quoting depends on systems you do not control, tell us what the funnel has to do.