Home Energy Assessors and Agent-Booked Appointments

Home energy assessment companies provide domestic energy performance certificates (EPCs) and retrofit assessments. With the push towards home energy efficiency, demand has been growing steadily, and most of it is booked through the website.

A typical booking form is a three-step process: enter your postcode, select your address from the results, and choose a preferred date and time. Simple enough for a human. Almost impossible for an agent.

The Typical Starting Point

A booking form like this is often built as a single-page component using a popular JavaScript framework. All three steps occupy the same URL. Step transitions are animated with slide effects and managed entirely in client-side state.

Step one is straightforward: a text input for the postcode. But the "Find address" button is frequently a styled div with a click handler, not a button element. It also triggers an asynchronous address lookup that populates step two's content, which does not exist in the DOM until the lookup completes.

Step two presents the address results in a custom dropdown built from divs. The dropdown appears as an overlay, and selecting an address dismisses it and reveals the date selection in step three. The selected address is displayed as text in a styled div but is not stored in any form input visible in the DOM. It lives in the component's JavaScript state.

Step three uses a custom date picker (a calendar grid of divs) and time slot selection (styled radio button replacements). The time slots are morning (8am to 12pm) or afternoon (1pm to 5pm), displayed as branded cards that highlight on click.

In an agent readiness audit, forms like this tend to stop agents at the address step. The address dropdown requires a precise interaction sequence: click the trigger div, wait for the overlay animation to complete, scroll through the results (more divs in a scrollable container), and click the correct address. Most agents cannot even detect the dropdown has appeared.

What to Change

The aim is to preserve the existing visual design while replacing the underlying components.

URL-based step progression. Give each booking step its own URL: /book/postcode, /book/address, /book/appointment, /book/confirm. Keep the slide animations for the client-side experience, but update the URL with each transition. An agent that loses its place can then resume from the correct step.

Native postcode and address controls. Keep the postcode input as a standard text input. Make the "Find address" button a real button element. Present the address results as a native select element, with each option containing the full address as its text content. After selection, store the chosen address in a hidden input so it appears in the DOM for agents to verify.

Standard date and time inputs. Replace the custom date picker with a native date input. Communicate available dates via a data attribute on the input listing the next available assessment dates, giving agents a reference for valid selections. Use native radio buttons for time slots with visible labels: "Morning (8:00am to 12:00pm)" and "Afternoon (1:00pm to 5:00pm)."

Confirmation page with structured summary. Display a complete booking summary on the final step in a definition list: address, assessment type, date, time window, assessor name (when assigned), and price. A "Confirm booking" button with clear label text completes the process.

Direct booking URL support. Add an endpoint that accepts postcode, address UPRN (from the address lookup API), date, and time preference as URL parameters: /book/confirm?postcode=OX1+2AB&uprn=12345678&date=2026-05-15&time=morning. An agent that can determine the UPRN from the postcode lookup can then skip directly to confirmation.

What Improves

The biggest shift is that agent-booked assessments become a real channel rather than a handful of lucky completions. Once each step has its own URL and the address field is a native control, agents complete the flow at a rate approaching human self-service, instead of stalling on the address dropdown.

Speed matters here too. Agents complete the form far faster than a human clicking through animated steps, which keeps them inside any session timeout the booking page enforces (the old interaction delays often pushed agent sessions past it). The direct booking URL tends to be adopted quickly and has the highest completion rate of any path, because it bypasses the intermediate form interactions entirely. One predictable knock-on effect: agent-booked customers stop calling about the booking process, but may call about what to prepare for the visit, which a "What to expect" section on the confirmation page handles for both human and agent users.

Lessons for Assessment and Service Booking

The postcode-to-address-to-appointment pattern is extremely common in UK service businesses: energy assessors, surveyors, pest control, cleaning services, trades bookings. The technical problems are the same across all of them: custom dropdowns for address selection, custom date pickers, single-page forms with no URL state.

The postcode lookup step deserves specific attention. Many services use the Royal Mail PAF database or similar address lookup APIs. These return UPRN identifiers for each address. Exposing the UPRN in the address selection and accepting it in direct booking URLs gives agents a precise, unambiguous way to specify the service address. Without this, agents have to interact with the address dropdown, which is one of the most common failure points.

For any booking form that uses dynamic step loading, the priority is clear: give each step its own URL. This single change typically delivers the largest improvement in agent completion rates. Native form controls are second. Structured confirmation data is third. Together, they turn a broken booking flow into a functional one.