Bytesized | From Solution to Site – Why AI has to work where our frontline teams do
Dave Warfield
Technology & Transformation Director
We’re currently standing up another 132kV substation site in Wales. It’s the kind of project that tests every assumption we make about technology, because it isn’t happening in an office. It’s happening on a hillside, often out of mobile signal range, in a working environment where the priority is always the job in front of the engineer, not the software running behind it.
That’s the starting point for how I think about AI at JSM. It’s easy to talk about AI as something that transforms head-office functions, reporting, forecasting, back-office efficiency, and it does. But if that’s where the conversation stops, we’ve missed the teams who are delivering the operational elements of our projects: the engineers on site, the operations teams working shift patterns at remote substation builds, the field crews who are the reason any of this infrastructure gets built at all.
The problem with technology designed for the office
Most enterprise technology is built around a quiet assumption: a stable connection, a desk, a screen, and time to sit and use it properly. None of those things reliably exist on a live operational site. Signal drops in and out. People are wearing gloves, working at height, or mid-task when they need an answer. The cost of a tool that doesn’t work in those conditions isn’t inconvenience, it’s that frontline teams stop using it and fall back to whatever gets the job done, usually a phone call to someone back at base.
We’ve built and rolled out technology internally that fell into exactly that trap in the past, and I’d rather admit that than pretend it hasn’t happened. The lesson from it is straightforward: if a tool only works from a desk, it isn’t actually supporting the frontline, it’s supporting the idea of the frontline.
What “adaptive and accessible” actually means
That’s why, as we look at where AI can genuinely help our operational teams, we’re starting from the conditions on the ground rather than the capability of the technology. Adaptive means a tool that fits into the actual rhythm of a site visit rather than asking someone to change how they work to accommodate it. Accessible means it works on the device someone already has in their hand, in the format they need at that moment, whether that’s a quick answer, a checklist, or a way to flag something back to an engineer who isn’t standing next to them.
That’s already playing out with AI tools built by Operations, for Operations, perhaps with capability far less glamorous than the word “AI” usually suggests. Our Order Management Solution replaces exactly the kind of phone call to base I mentioned above: it gives our Digital Infrastructure and telecoms teams one live dashboard tracking every active job, its client, location, value, key dates and urgency, from wherever someone needs to check it. It’s already tracking 705 jobs. Our Route SED Finder & Digitised Gazetteer does something similar for route planning: what used to be a week of manually checking a proposed route against bridges, tunnels, underground pipes and roadworks data now takes minutes, on a single interactive map. Neither tool is trying to be clever for its own sake. Both are trying to get an answer to the person who needs it, faster, wherever they happen to be standing when they ask the question.
Why this matters more, not less, as sites get more remote
The Wales project is a useful test case precisely because it’s remote. Projects like it are only going to become more common as JSM’s pipeline grows into locations chosen for grid capacity and land, not for their proximity to head office or their mobile coverage. If our approach to technology only works well in well-connected locations, we’re building tools for a smaller and smaller share of our own operation.
The teams on these sites are also some of the most experienced people in the business. AI, used well, isn’t there to replace that judgement. It’s there to remove the friction around it: the time spent chasing information, filling in the same detail twice, or waiting for someone else to be free to answer a question. A well-designed tool, like the two above, could answer that question immediately. Used badly, it’s another system that looks impressive in a demonstration and gets ignored on site. That distinction is the whole job.
Building it with the people who’ll use it
The teams best placed to tell us whether a tool is genuinely adaptive and accessible are the ones using it in the field, not the people specifying it from head office. That’s why our approach starts with time spent on sites like the one in Wales, understanding where the actual friction is, before any technology decision gets made. It’s a slower way to do this than picking a platform and rolling it out, but it’s the only way I know of to avoid building something nobody on the ground actually wants to use.
Where this goes next
We’re early adopters of AI and are willing to adapt to get this right. The projects we’re most excited about are the ones where operational teams get real time back, and we’re already seeing that with tools like the Order Management Solution and the Route SED Finder. As the Wales site and others like it come online, we’ll get to see these tools earn their place in the field, where it counts. That’s the evidence we’re building towards, and I’m confident it will show what AI can do when it’s built for the people doing the work, and deliver continuous improvements for our clients.
