Product Engineering

Building for the Human in the Loop

Internal tools get built as though the user has infinite patience because they are paid to be there. They do not, and the cost of pretending otherwise shows up in revenue.

Alongside the customer-facing app, we build tooling for field and telesales teams who place and manage orders on a customer's behalf. It is invisible externally and it carries real commercial weight — those teams handle a meaningful share of transactions, and they handle the accounts that need handling.

Internal tooling has a characteristic failure mode. Because the user is an employee, the implicit assumption is that friction is acceptable — they are paid to be there, they can be trained, they will cope.

They do cope. They cope by working around the tool: parallel spreadsheets, memorised workarounds, calling a colleague who knows the trick. Every one of those is your product failing quietly, and none of it appears in your metrics.

What is actually different about this user

They are on a call. The customer is waiting. Anything that takes more than a couple of seconds happens while someone listens to silence, and the agent will avoid it next time.

They are expert. They use it all day, every day. Onboarding hand-holding that helps a new customer actively slows them down. They want density, keyboard paths, and no confirmation dialogs on things they do forty times a day.

They know things the system does not. That this customer always wants the larger pack. That this delivery window is unrealistic for that address. Tooling that cannot accommodate operator knowledge forces them outside it.

Design for the person who has done this ten thousand times, not the person doing it once.

The thing that changed our approach

Watching them work. Not a survey, not a requirements session — sitting with agents while they took real calls.

Within a morning you see the workarounds, which screens they never open, where they hesitate, and which piece of information they always need but have to go and find. None of it comes out in a requirements gathering, because the workaround has become invisible to the person performing it. They no longer experience it as friction; it is just how the job is done.

Where AI belongs here — and where it does not

Assisted sales looks like an obvious AI surface, and parts of it are: surfacing likely reorders, flagging an unusual order pattern worth a question, summarising account history before a call.

What does not work is anything that takes the decision away. The agent is accountable for the order. A system that acts on their behalf, unpredictably, in front of a waiting customer, will be routed around within a week — and correctly so.

The design principle we settled on: AI proposes, the operator disposes, and the proposal must be inspectable. An agent who cannot see why something was suggested cannot defend it to the customer, and will not use it twice.

A metric worth watching

Track how often orders are amended immediately after placement. A high rate usually means the tool made the wrong path faster than the right one — which is the most expensive kind of efficiency.

← All writing Next: Dependency Debt Is a Tax You Pay Without Noticing →