Where to start with AI in a business that runs on phone calls

By Richard Sands, VP of Engineering at Ofload

The instinct in a traditional business is to look for the big AI transformation project, because that's what justifies the spend. It's the wrong instinct, and it's the reason most of these programmes quietly stop being mentioned about nine months in.

The constraint was never the technology. It's adoption. You can put a genuinely good tool in front of someone who moves freight for a living, and if it adds one step to their day they'll be back on the spreadsheet by Thursday. That isn't resistance to change. It's a reasonable response to being handed something that made the job harder.

So the useful question is where to start.

Look for the boring, repeated thing

Start with small efficiency wins. A step someone repeats forty times a day. A piece of research that currently takes an afternoon. Something with a clear before and after that the person doing the job can feel without anyone explaining it to them.

Those compound, and while they're compounding they build the thing you actually need, which is a team that believes the tools help. Big-bang adoption tends to produce the opposite. People comply, nothing gets faster, and you've spent your credibility on the first attempt.

What's changed for us

I'll be specific, because generalities about AI are cheap.

Somewhere between 70 and 80% of our code is now written by AI. That's changed the shape of the work more than the volume of it. Context switching has gone up enormously. Instead of holding one piece of work, an engineer is moving between ten, and things happen faster than the judgement around them naturally keeps up with. Managing that has become a real part of the job rather than a side effect of it.

Research and scoping time has shrunk hugely. If you're deciding where to look first in your own business, look there, because it applies to everyone and not just engineers. The gap between "we should look into this" and "here's a working version" used to be measured in weeks.

It's also changed who can build. Once these tools are available beyond the engineering team, the line between engineering expertise and domain expertise gets blurry. In our world the domain experts are the people moving the freight and managing carrier relationships, and they understand their own workflows more deeply than any engineer will. That turns out to matter more than I'd assumed. Engineers still have a large part to play, because they think differently about how data moves and where the guardrails sit. But the person who knows the problem is now much closer to being the person who solves it.

On the operational side, the most valuable application has been observability. Watching the whole system, spotting when something is going wrong, finding the trend before it becomes an incident, and in some cases fixing it. We release six or seven times a day. That's only safe because we can see what's happening.

The part that doesn't make the case study

Your data ends up in more places than you have visibility over. When you open these tools up across a business, information moves in ways nobody has fully mapped. We want people using them as much as they can, and that has meant building the guardrails alongside the rollout rather than reviewing it afterwards. If you're weighing this up, treat it as a design question from day one.

The other thing worth expecting: speed cuts both ways. If your processes are messy, you now have messy processes running fast, and you find out about all of them at once.

Trust is the actual blocker

Underneath all of it is a trust problem, and it's a fair one. AI isn't deterministic. It's an algorithm putting words together, and it can take a single word and run somewhere you didn't intend. In an industry where a wrong date format means a driver turns up at the wrong gate, that's a real objection rather than a hypothetical one.

Which is why evals are where we're putting the effort. The question we keep coming back to is how we'd reliably know when a workflow regresses. A model gets updated, a prompt gets edited, an edge case turns up that nobody wrote for, and the output still reads as perfectly reasonable. That's the part that catches you out. It fails in a way that looks fine. An eval is how you see it: you define what a good output looks like for a given workflow, run it against real cases, and check it on every change rather than waiting for someone in operations to notice something is off. It's unglamorous work, and it's the thing that makes everything else safe to run.

Be deliberate about what you automate and what you don't, and keep a person on the judgement calls. Some things shouldn't be handed over yet. Knowing which ones is most of the skill.

The question people don't ask out loud

If I lean into this, am I automating myself out of a role?

Worth taking seriously rather than reassuring people past it. My honest view is that this has always been part of working in an operations business. You hire yourself out of a role, and then you go and do something more valuable. AI makes that cycle faster, which is uncomfortable, but the direction is the same one it's always pointed in. The people who take on the tools tend to end up with more range.

You can mandate that shift or you can do it softly. We've gone softly, starting with the small wins and letting people find their own reasons. It looks slower from the outside. It's the only version I've seen hold.

See the roles we're hiring for.