Redesign the work before you automate it

Every sales process we walk into was designed around what people could do by hand. Then agents arrive and the first instinct is to point one at the process as it stands. That makes the current process faster, including its waste. So we spend the first two weeks of every deployment redesigning the work around what AI can now do, and only then do we build.

The current process is a set of workarounds for human limits

Follow a process step by step and this is what you usually find. A rep enriching a spreadsheet by hand, row by row, because nobody else was going to. A lead sitting in a queue for a day because the person who routes leads was in meetings. A CRM rebuilt by each new head of sales, adding fields for the problems they had at their last company.

None of that is stupid. Each step was the best option when a person had to do it. But automate it and you lock the workaround in.

At a deep-tech company selling into hospitals through integrators, the partner list was a spreadsheet of about 2,700 companies. Dirty, and nobody wanted to work through it, and the obvious ask was to enrich it faster. We did not do that. We built the territory as a graph from government sources, hospital lists and integrator registries, normalised it and linked it to their CRM. The 2,700 rows collapsed to 64 ranked accounts. Enriching 2,700 rows faster would have produced 2,700 enriched rows nobody wanted to work through. Modelling the territory made the list rank itself.

The obvious automation is rarely the one that matters

At a software company we work with, enriching the whole database was the obvious thing to build. The sales team did not see missing data as the problem. Its problems were speed to lead, and phone over email, because its buyers do not answer email.

So the automation that mattered was different from the one that was obvious. Speed to lead is a routing problem, and the team had already fixed its routing. What it needed from us was narrower: a phone number next to every name, because a fast lead you can only email is still a slow lead. So what runs there now is phone-number lookup and contact enrichment for outbound, aimed at that one gap. If we had built what looked obvious from the outside, we would have built something nobody used.

Two weeks with the team is how you find the real work

Week one is observation. We sit with the people doing the work and trace inputs, decisions, handoffs and exceptions. Where does a lead come from, who touches it, what do they decide, what happens when it does not fit the rule. We inspect the systems and the information people rely on, which is often a different set from the one the org chart says.

Week two is the redesign. We decide, step by step, what belongs with agents, software or people. We rank the opportunities by what they are worth and what they cost to build. We check what the first build needs, which is usually a data source nobody has cleaned or a decision nobody has written down. And we agree the standard the first build has to meet, on real examples, before anyone writes code. You leave with a map of the work, ranked opportunities, the first scope and a baseline.

Deterministic steps stay software, judgement goes to agents, direction stays with people

The rule for splitting work is simple to state. If a step has a fixed input and a fixed output, it is software and should stay software. If a step needs judgement within limits the team has agreed, it goes to an agent. If a step is an approval or a change of direction, it stays with a person.

One example of each from the deep-tech deployment. The top-50 list refreshes every morning at 7am so the rep has a fresh list by 9am. That is software: same query, same time, no judgement. Meeting prep is an agent. At 9am it looks at that day’s external meetings, pulls previous calls, emails, deal history and similar companies from the CRM and the graph, and posts it to a shared Slack channel. What counts as similar, and what is worth surfacing, is judgement within limits. The decision to email a CFO stays with the rep. The agent can draft. The rep decides whether this is the moment.

Get the split wrong in either direction and it shows. Put an agent on the 7am refresh and you pay for judgement you do not need. Put software on meeting prep and you get a template. Let the agent decide who to email and you find out from the reply.

The audit is not hard, and companies skip it anyway

Most companies have put AI into the work as it stands, and few have much to show for it. In McKinsey’s 2025 survey, 88% of companies use AI in at least one function, 39% report any EBIT impact and about 6% attribute more than 5% of EBIT to it.

Skipping the redesign is one way to end up in that gap. Companies skip it for three reasons, and none of them is that the audit is hard.

It is uncomfortable. Tracing the process means someone writes down that the lead queue exists because two people do not talk to each other, and that the CRM has fields nobody fills in. People built those workarounds, and they are in the room.

It needs someone on site who can say no. When a rep asks for the spreadsheet enriched faster, the easy answer is yes. The right answer, in that case, was that the spreadsheet should not exist. You cannot say that from a sales call, and a vendor with a quota will not say it at all.

And vendors sell tools, not redesign. A tool is priced per seat and demos in twenty minutes. A redesign takes two weeks, with time on site, and produces a document before it produces software. The first is easier to sell. The second is what makes the software worth having.

Two weeks is the cheapest part of the deployment

“We don’t have time for an audit.” I hear this in most first calls. The team is behind on pipeline and wants something running next week. But the two weeks are the cheapest part of the deployment. The expensive part is the building that follows, and every week of it spent building the wrong thing is gone. Both builds that looked obvious above would have been quick to start: enrich the spreadsheet faster, enrich the CRM. Both would have shipped, and neither would have been used. Two weeks of following the work is how you find out which build is worth the weeks that follow.

Automate the work you have and you get the work you have, faster. Redesign it first and you get the work that should exist.