Over the past year, there’s been a shift inside SightCall.
AI stopped being just a feature we were building and started becoming part of how we operate.
Our engineering teams don’t work the same way they did 18 months ago. They’re not writing everything line by line anymore.
They’re designing systems, guiding them, validating outputs, and focusing their time where it matters most.
What surprised me wasn’t just the productivity gains. It was the quality.
We’re delivering significantly more, with smaller teams, and the work itself is often better. Not because engineers matter less, but because their role has fundamentally evolved.
And the more I’ve seen this play out, the more I’m convinced that field service is heading toward the same kind of shift.
Solving the Knowledge Problem
For decades, service organizations worked hard to standardize processes. Dispatch, workflows, SLAs, all of it has been optimized.
But one thing has remained stubbornly resistant to scale: knowledge.
In every conversation I have with service leaders, the same patterns come up.
Their best technicians carry critical expertise in their heads. New hires take months, sometimes years, to get up to speed. Documentation exists, but it’s often outdated or disconnected from what actually happens in the field.
At the same time, pressure is only increasing.
Experienced technicians are retiring. Equipment is getting more complex. Customers expect faster resolutions, often on the first visit.
What we’re seeing isn’t just a talent gap or a tooling gap.
It’s a knowledge scaling problem.
In software, we’ve already lived through a version of this.
There was a time when scaling meant hiring more developers. More demand meant more people writing more code. That model is broken.
Today, the most effective teams aren’t just bigger, they’re structured differently. They rely on systems that can produce, refine, and reuse output at scale.
This is the lens I’ve started to apply to field service.
What if the real opportunity isn’t just making technicians more efficient, but fundamentally changing how expertise itself is produced and reused?
That’s what I call the Field Service Factory.
Learning from What Happens, As It Happens
One of the reasons many AI initiatives in service haven’t delivered on their promise is something I’ve seen repeatedly with customers.
The systems are disconnected from reality.
They’re trained on tickets, documentation, and structured fields. But service doesn’t happen inside a ticket.
Service happens on a factory floor, in a customer’s home, or on a job site. And it happens in messy, visual, contextual ways that don’t translate cleanly to text.
So the AI makes recommendations that look right on paper, but don’t hold up in the real world. Information is incomplete. Mistakes are made. Trust breaks down quickly.
What’s missing is simple, but hard to capture: what actually happened.
What the technician saw. What they tried. What worked. What didn’t.
This is where I’ve seen a different model start to emerge.
Instead of asking people to document knowledge after the fact, you capture the work itself… as it happens.
You capture the interaction between a technician and an expert. You preserve the video, the audio, and every step in the sequence of actions from problem to resolution.
From there, AI can structure it into something usable. A step-by-step guide. A visual reference. A knowledge asset that reflects reality, not theory.
We’ve seen this work with SightCall Xpert Knowledge™.
One remote support session doesn’t need to be limited to solving the single problem in front of you. It can be leveraged to create an asset that can be reused, searched, and improved upon.
Over time, that kind of resource changes the equation.
The result? Knowledge is no longer something you ask people to write.
It becomes a byproduct of doing the work.
Creating a Service Intelligence Loop
When you connect enough of these interactions, a loop starts to form.
Every service event contributes to a growing body of real-world knowledge. That knowledge gets refined, validated, and pushed back into the organization.
That way, the next technician doesn’t start from scratch. They start with everything that’s already been learned.
This is the part I think is easy to underestimate.
It’s not just about better documentation. It’s about creating a system that learns.
I think of it as a Service Intelligence Loop.
And when that loop starts to take shape, the impact is very tangible.
New technicians ramp faster because they’re not relying on static manuals. Experienced technicians spend less time repeating the same guidance. First-time fix rates improve because decisions are based on patterns across hundreds of real cases, not guesswork.
Most importantly, you’re no longer dependent on having the “right” expert available at the exact right moment.
You’re giving every technician access to the collective experience of the organization.
A New Knowledge Collection Model
I’m aware this may sound familiar.
Service leaders have invested in knowledge bases, documentation systems, and training platforms for years. And many of those initiatives have struggled.
The difference here is not just the use of AI. It’s how knowledge is created.
If capturing knowledge requires extra effort, it won’t scale. If it’s limited to text, it won’t reflect reality. If it sits outside the tools technicians already use, it won’t be adopted.
This only works if it’s embedded in the flow of work, grounded in real interactions, and continuously improved with human validation.
What I believe we’re moving toward is a different model for service organizations. Not just more efficient operations, but systems that continuously learn from every interaction.
Where technicians aren’t just executing work, but contributing to a growing body of intelligence. Where AI doesn’t replace expertise, but amplifies it.
And where the organization gets better with every job it completes.
A Service System Built for Growth
If I look at what we’re seeing in software, the pattern is clear.
Growth is no longer tied directly to headcount in the same way it used to be. AI has become a production system.
Field service is approaching a similar inflection point.
The companies that move first won’t just have better tools. They’ll have built systems that capture, structure, and reuse expertise at scale.
Let me make it concrete:
A technician is dispatched to a complex issue.
Before they arrive, they already have a clear view of what’s likely happening, what tools they’ll need, and how similar issues have been resolved in the past. Not based on a generic manual, but on real examples from their own organization.
They’re not guessing. They’re not starting from zero.
They’re building on everything that’s already been learned.
That’s the shift I’m seeing. Not another layer of documentation. Not another AI assistant.
A system that turns everyday service work into usable, evolving intelligence.
That’s the Field Service Factory.