Start with the Audi TT: what a career in field service taught Thomas Osborn about why FSM software fails

A Regional Service Manager with decades of EMEA field operations experience on the gap between what companies spec and what actually makes their teams work.

Interview by Rodion Salnik, Fieldera

Thomas Osborn has been in field service his entire career. Different companies, different industries, different countries — but the same problems keep showing up. He's worked with SAP, ServiceMax, Salesforce, ServiceNow. Not as a vendor. As the person responsible for making these platforms work after someone else signed the contract.

When we spoke, he described a failure pattern he's seen repeat so many times it barely surprises him anymore. Companies buy powerful FSM software with full customization freedom. They tell the vendor exactly what they want. The vendor builds it. The engineers — the people who actually have to use it every day — quietly stop using it.

"You've created complex workflows for your engineers in the field," he said, "so they're not giving you good data. Without good data you can't drive good KPIs, you can't drive your SLAs and you can't do any forward planning."

He's also the person who came up with one of the sharpest pieces of FSM implementation advice we've heard. Don't give them the Ferrari.

The thing that keeps striking me is that companies don't learn from each other. They make the same mistakes, over and over. And often it's because the software platforms they're using, rather than guiding the company to a good foundation, just say: our software is completely flexible, we can make it exactly what you want.

And then they let the company lead that.

Often these companies are either starting out in service for the first time or transitioning from one service model to another. They end up with a very messy system that doesn't work for them, and it has a massive impact on service delivery. I end up going in and helping them tidy it up. Look, you need to simplify this.

The frustrating thing is that it's entirely preventable. Gartner puts ERP implementation failure rates at around 70%. Field service software shows the same pattern. About 80% of features in a typical FSM deployment go unused. The tools aren't the problem.

Every company believes they are special. Every company believes that only their way is the right way and that they are the only ones collecting that specific set of data. That's what every company believes.

And then when you get to the bottom of it, they are all collecting the same thing. Response times, first time fix, travel times, efficiency times. Parts used, job reports.

They're all collecting that same core of information. But because they all insist it needs to be done their way, you end up with very, very messy workflows. And ultimately the end user, who's the engineer, never uses it.

I worked with companies running particle accelerators. Highly technical, lots of R&D, everyone wants to capture every tiny piece of data. If you asked them, your software would have to capture so much information it would make it difficult to use. But the reality is that most of that information is not core to how the business actually operates. They want to feel special. They all want to measure the same things.

When a company starts building a new software tool, they go to who they believe the key stakeholders are. Project management teams. Finance teams. HR teams. Resource management teams. And everybody's asking for different sets of data.

The software supplier gets flooded with requests from everywhere. There's no central focus. You end up with a field service management tool that makes things more complicated, not less.

The workflows don't work for the engineer. So the engineer doesn't record good data. So the finance team or the sales team or project management is frustrated because they can't find the data they want. They keep pushing harder for their version. And you end up with a very, very messy package.

What gets missed almost every time is involving the engineers right at the beginning. The people speaking with the software team will always focus on a laptop. But an engineer is not sat at his computer all the time. Any workflow that involves the computer from beginning to end slows that engineer down. So the engineers develop workarounds. Or they just stop filling things in.

That's the adoption failure chain. It goes: complex workflow, engineers don't use it, bad data, no KPIs, no SLAs, no forward planning. It's predictable. And it starts at the requirements stage, before a single line of code is written.

Around 58% of field service teams cite managing technician adoption as a major hesitation with new technology. That number tracks. The hesitation is earned.

It came from watching this happen enough times. The software providers go in with a completely open brief. Look at everything our software can do. All these wonderful features. And the client, who often doesn't yet know what they actually need, starts spec-ing complexity they can't handle.

What they should be doing instead is saying: this is the car you've got. We're going to teach you how to drive it.

Rather than: do you want traction control? Do you want automatic gearbox? Do you want the metallic paint?

Because what happens when you hand someone a Ferrari and they've never driven one is entirely predictable. If you give them the super duper fancy Ferrari, with all the bells and whistles, they will spin it off the track at the very first corner. And they will blame the car.

If you teach them to drive in an Audi TT, they will be fast, they will be solid, they will think you are the best thing on the world, and then you can show them what extra bits you can add.

That's the whole problem in one analogy. And it applies whether you're talking about a £20,000 system or a £2 million enterprise rollout.

The consultant layer is the person in the middle. The person who sits between the software vendor saying "it can do whatever you want" and the client saying "here's what we think we need" and slows everything down long enough to ask: what data actually matters to you?

If the software company is able to say to their client, let's sit down in a meeting, tell us what you want to know — we will make sure that you get to know it out of your software. What's important to you? What are the numbers you want to gather? What does your engineer need to do in 30 seconds on a mobile device?

That's different from selling features. That's guiding the company into how to actually use the product.

It's an extra layer that doesn't always exist in software companies. And it's the one that makes the difference. We've got a brilliant piece of software — but so have ten other companies. If a business starting out in service can reach a consultant level that gives them a clear roadmap, that's where you stand out from the crowd.

The breakdown almost always traces back the same way. The decision makers signed the contract. It all looked great on paper. Looked great on the golf course. But when it hit the company — the people who need to use it, the people who need to integrate it into their workflows — they were only just finding out about it. That gets harder and harder the bigger you scale it.

ServiceMax is a good example. It's a powerful piece of software. If used correctly, it can give you all the data you need. But it gets misused constantly. And when it fails, people blame the software. It's a real shame, because the tool isn't the problem.

An audit. Before anything gets configured, before any requirements get written, someone needs to ask: what data do you actually need to run this operation?

Because when you do that across enough companies, the answer is almost always the same. Response times. First time fix rates. Travel times. Parts used. Job reports. That's the core. Everything else is an extra.

A great way to make the company feel special is this: you use exactly the same form for every company. They won't know, because they haven't seen it. But they get their own colour scheme, and they get their little banner, so it looks like it was built just for them.

That's the foundation. Get the engineers using it. Get clean data coming in. And then, once the team is actually adopting it, once you can see what they're doing with it, you add the extras. Because now you know what the extras should actually be.

Think of it as four steps. Audit what data you actually need. Simplify down to a baseline engineers can use in the field. Get adoption before adding anything new. Then expand, because now you know what the expansion should look like.

Every company wants the Ferrari. The Audi TT is what makes them fast.

The question to ask is whether the vendor leads with consultancy or features.

If the first conversation is about everything the software can do — all the customization, all the options, all the bells and whistles — that's a signal. Because that's exactly the environment where you end up over-spec-ing and under-delivering.

The vendor who stands out is the one who asks, before showing you anything: what are you trying to measure? What does your engineer need to do in 30 seconds on a mobile device? What does your dispatch team need to see at the start of every morning? What does a failed SLA cost you in real terms?

If they're asking those questions first, they're playing the consultant role. That's the one that's usually missing. And when it's there, implementations look completely different.

The failure pattern Thomas describes isn't specific to any platform. SAP, ServiceMax, ServiceNow, IFS — he's watched all of them succeed and fail in the same companies, across the same industries. The platform rarely explains the outcome.

What explains the outcome is whether anyone audited what data mattered before configuration started, whether engineers were involved before requirements were locked, and whether someone played the role of the person in the middle: the one who slows things down long enough to ask the right question before anything gets built.

That's the role the industry keeps skipping.

Fieldera was built around the same recognition. Every deployment starts with a Week 1 operational analysis: mapping current workflows, identifying the data the operation actually depends on, before a single module gets configured. Deployment runs 4–5 weeks, because the foundation is built right the first time with the engineers in mind. The platform adapts when the operation changes, without requiring a specialist architect or a contract extension.

fieldera.ai

Thomas Osborn is a Regional Service Manager with a career in EMEA field operations across multiple industries. Connect with Thomas on LinkedIn

Why do FSM software implementations fail even with powerful platforms like SAP or ServiceMax?

The platform is rarely the problem. Implementations fail when companies configure for complexity they don't yet understand, driven by the wrong stakeholders, without anyone auditing what data actually matters. Engineers end up with workflows too slow to use, stop recording clean data, and the whole chain breaks: no good data, no KPIs, no SLAs, no forward planning.

What data does field service management software actually need to track?

Across industries and company sizes, field service operations collect the same core information: response times, first time fix rates, travel times, efficiency times, parts used, and job reports. Everything else is an extra. Building the system around this core first — before adding complexity — is what drives engineer adoption.

How do you get field engineers to actually use new FSM software?

Start with a workflow they can complete in under a minute on a mobile device. Engineers are not sat at computers; any process that requires a laptop from start to finish will get bypassed. Involve engineers in requirements before anything is built. And deploy a simple baseline first. Once the team adopts it, add complexity, because then you know what complexity is actually needed.

What does a field service management consultant actually do?

A good FSM consultant closes the gap between what a company thinks it needs and what will actually make its operations work. That means auditing requirements before configuration starts, managing stakeholder expectations across finance, ops, and engineering, and ensuring the platform is built for the people using it in the field, not for the people who signed the contract.