Planning

Context

From a sales visit to a signed-off installation

Before a heat pump gets installed, a salesperson visits the customer on site and creates an offer, specifying what system will be installed, what it will cost, and what work is involved. But a sales offer isn't an installation plan. Someone still has to check whether the technical reality matches what was promised.

That's the Technical Check. A checker reviews the offer and validates whether it's actually deliverable at the quoted price and scope. If something doesn't add up, the offer goes back. Sales makes adjustments. Sometimes the customer has to be re-approached. Only when the check passes can the job move forward into the installation queue.

I joined the planning stream to fix the bottleneck that was slowing everything down.

Project Focus

Where in the process are we working?

The planning domain spans the full journey from sales handover through to the job moving into production, across pre-planning, fine planning, offer adjustments, and downstream streams that depend on planning being accurate to do their work.

Fine planning was the bottleneck. Several parallel checks all had to be completed before a job could move forward. Any one of them could trigger a pushback loop, stalling the process and delaying everything downstream.

We focused there first. Not because the rest didn't matter, but because fixing fine planning would unblock everything that followed.

Understanding the Workflow

We started by getting close to the work

Before designing anything, we spent time with the team, sitting with checkers, watching how they worked, asking questions. We mapped the process from handover through to completion, joining daily stand-ups and following tasks as they moved between teams.

What we found was a system with many moving parts running in parallel: multiple checks, calculations, and coordination flows all triggered at handover, all interdependent. That part was actually working. The bottleneck was coming from inside the checks themselves.

Understanding the Problem

All the information hiding in open text fields

The check tool gave checkers one thing: a blank text box. Everything went in there: measurements, decisions, flags, notes. The result was a paragraph that only the checker who wrote it could reliably interpret.

Several things were making the check slower and more error-prone than it needed to be:

Low Hanging Fruit

Fix it locally first, then zoom out

Given the time pressure, we split our thinking into two horizons. The immediate fix: replace open text with structured, parameterised inputs. The broader fix: redesign the planning overview to give the whole team visibility into where things stand and what's blocking.

We started locally. Structured inputs meant the output of every check would be consistent and usable: no more manual copying, no more interpretation, no more inconsistencies in the downstream brief handed to craftspeople on site.

Mapping the Parameters

You can't structure what you haven't defined

Before we could build the form, we had to define every question, every possible answer, and every input type. I worked with the team to translate the full check process into a structured map, making explicit the decisions that had previously been made implicitly, in free text, by whoever happened to be doing the check that day.

Design Challenges

Making explicit what was always implicit

Switching from open text to a structured form meant making design decisions that the old process had never needed to make. A few things required careful thinking:

Defining the Solution

Replace open text with a guided, adaptive form

The form needed to do more than collect answers. It had to guide checkers through a consistent process regardless of experience level. We designed a dynamic, parameterised form where each response determines what comes next, adapts to the specifics of each job, and produces structured output that downstream teams can use without any manual translation.

Testing & Iteration

Validate fast, adjust often

We built a lightweight prototype to test the parameter structure with real users (quick to adjust, no heavy dev effort required). Testing revealed where the logic broke down, where answers needed more context, and where the flow felt unnatural. We iterated on the content before touching the build, then rolled out the first version and measured from there.

Impact

Structured data, measurable results

Replacing open text with parameterised inputs didn't just speed up the check. It made the results traceable. The business could now connect what was decided in the check to what actually happened on site.

Zooming Out

From fixing a bottleneck to building a process

Once the check bottleneck was unblocked, we turned our attention to the bigger picture. The structured inputs had created clean, reliable data for the first time, but there was no single place to see it all together.

We designed a planning overview that separated data by visit, giving the business a clear view of where each job stood at any point in the process. For the first time, the results of each check were traceable back to the original offer, connected all the way through to what actually happened on site.

Target State

What the structured form unlocked for everyone

The form wasn't just a faster way to do the same thing. It changed what was possible downstream, for every person who touched the job after the check was done.

Next Steps

Moving forward to our target

With the structured check process in place, the next focus was bringing the same rigour to a more complex part of the flow, one that required evaluating multiple variables per job and presenting the results in a way that supported well-informed recommendations at scale.