Why Energy Supplier Booking Wizards Fail AI Agents

Energy suppliers run a lot of appointment booking through their websites: smart meter installations, repairs, account changes. As part of the national smart meter rollout, a typical supplier books a large volume of installation appointments every month, and an online booking wizard usually handles a meaningful share of them. The rest fall back to the call centre. When those wizards are built purely for human eyes, AI agents sent to book on a customer's behalf tend to fail, and the work falls back to the phone.

The Typical Starting Point

A common pattern for these booking wizards is a five-step process: enter your postcode, confirm your address, select your meter type, pick a date and time slot, and confirm the booking. It works well enough for humans who can see the visual progress bar and follow the flow.

For AI agents, it is often a wall. The entire wizard runs as a single-page application. All five steps share the same URL. Content swaps in and out via JavaScript with no corresponding DOM change that agents can reliably detect. The date picker is frequently a custom calendar component built with div elements and click handlers. Time slots appear as colour-coded blocks: green for available, amber for limited, grey for unavailable, with no text labels.

When you run an audit on a wizard like this, the failures cluster in predictable places. Agents get stuck on the address confirmation step because the address suggestions load asynchronously and the agent clicks "Confirm" before the correct address appears. Others reach the date picker but cannot interact with it at all, because there is nothing in the markup to act on.

You can often see the same pattern in analytics: sessions with agent-like characteristics (rapid form interactions, specific user-agent strings) that start and then abandon at the same predictable points in the flow.

What to Change

None of the fixes here are technically ambitious. They are mostly a return to standard HTML form mechanics.

URL-based step progression. Give each step in the wizard its own URL path: /book/postcode, /book/address, /book/meter-type, /book/appointment, /book/confirm. You can keep the single-page architecture for speed by updating the URL via the History API on each transition. This gives agents a reliable way to track where they are in the flow and retry individual steps if something goes wrong.

Semantic time slot markup. Replace the custom calendar with a structured layout using button elements for each available slot. Each button should contain the full date, time window, and availability status as text: "Tuesday 14 January, 9:00am to 12:00pm, available." Keep the visual colour coding, but let it supplement the text rather than replace it. This follows agent-friendly form design principles throughout.

Native form controls. Make the postcode input a standard text input with a visible label. Use a native select element for address selection, populated with results from the address lookup API. Use radio buttons for the meter type selection, and a native checkbox for the terms acceptance.

Structured confirmation data. Display all booking details on the final confirmation page in a definition list with clear labels: property address, meter type, appointment date, time window, and engineer visit reference number. This gives agents a structured block to extract confirmation details from.

What Improves

The most reliable improvement comes from making appointment selection possible at all. With semantic time slot buttons in place, agents go from no ability to select an appointment to reliably selecting one. URL-based steps help agents recover when something interrupts the flow, and native controls remove the asynchronous-timing traps on the address step. Together, more agent-initiated bookings complete instead of abandoning, which takes pressure off the call centre.

The remaining gaps in suppliers' sites usually sit outside the booking flow. Account management sections and energy usage dashboards tend to lag behind, still built with custom components and limited semantic markup, so those are the natural next areas to address.

What Often Surprises Teams

Teams tend to expect the URL-based steps to matter most, and they do help. But the single biggest improvement usually comes from the time slot buttons. The fix is straightforward: replace divs with buttons and add text content, and agents that previously could not select a slot at all begin to do so reliably.

Lessons for Other Utility Providers

Energy suppliers, water companies, broadband providers, and similar utilities all face the same pattern. Their booking and service management flows were built for human interaction and often rely on visual cues, custom components, and single-page architectures that agents cannot parse.

The fixes are not technically ambitious. URL-based state, native form controls, text labels on interactive elements. These are web development basics that got lost behind years of custom UI component development. The payoff in reduced call centre volume alone makes the work worthwhile, before you even account for the growing share of customers who prefer to delegate these tasks to agents.