Rethinking Field Service

The Field Service App is a personal proof-of-concept project exploring what a modern field service platform could look like if it were designed around the people actually using it.

It isn't a finished commercial system, and it isn't currently a replacement for any of the systems used within the business.

Instead, it's an experiment.

A fairly large one.

The aim is to explore how engineers, coordinators, managers and customers could potentially interact with the same service operation without everyone feeling as though they're wrestling with different pieces of software.

Rather than beginning with:

What features should a field service system have?

I started with a different question:

What information does each person actually need at this exact moment?

That question has shaped almost everything I've built.

Most enterprise software is understandably designed around the organisation.

I wanted to experiment with designing something from the field engineer outwards.

A technician standing beside a machine doesn't need fifty fields, six menus and a dashboard full of corporate data.

They need to know what they're fixing.

Where it is.

What's happened to it before.

What they need to do next.

And what happens if they can't complete it today.

That philosophy became the foundation of the project.

The engineer experience is deliberately intended to be calm, simple and mobile-first. The complexity can still exist underneath, but the person holding the phone shouldn't have to fight it.

I call this idea quiet complexity.

One of the biggest ideas behind the project is continuity.

A piece of equipment shouldn't become a stranger every time somebody raises another service request.

Installation, maintenance, repairs, parts, previous faults and future work are all chapters in the same story.

So I've been exploring ways of making service history more useful rather than simply storing it.

That changes the engineer's experience from:

Here's today's fault.

to:

Here's today's fault, and here's the context you need to understand it.

It sounds like a small distinction.

In the field, it can be enormous.

Another important part of the proof of concept has been resisting the temptation to give everyone the same dashboard.

An engineer, coordinator and senior manager might all be looking at the same service operation, but they're asking completely different questions.

The engineer wants to know:

What do I need to do?

The coordinator wants to know:

What needs attention?

The manager wants to know:

Where can we improve?

And the customer ultimately wants to know something much simpler:

What's happening with my equipment?

The project therefore explores role-specific experiences where information becomes progressively more detailed when somebody needs it, rather than dumping everything onto the first screen.

This is where the project gets particularly interesting for me.

Field service generates an enormous amount of information simply by operating.

Repairs happen.

Parts are used.

Equipment develops faults.

Engineers revisit sites.

Jobs are completed.

Customers wait.

Individually, these are service records.

Collectively, they can become operational intelligence.

The proof of concept explores how that information might help a service organisation understand patterns, make better decisions and spot opportunities for improvement.

I'm deliberately keeping some of the detail behind that part of the project private.

There are several ideas within the prototype that I believe could provide genuine operational value, and this website isn't the place to publish the blueprint.

🔧 Some things are better demonstrated than documented.

Another area I've been exploring is the customer's experience.

Great engineering is only one part of great service.

A repair can be technically perfect while the overall experience still feels poor if the customer doesn't know what's happening.

Has someone been allocated?

Do you need anything from us?

Are you waiting for a part?

Is another visit required?

What's happening next?

Those questions create emails, calls and administration because customers naturally want visibility.

So part of this project asks a simple question:

What if good communication was part of the workflow rather than another task somebody had to remember to do?

That's an idea I think extends far beyond field service software.

There's also an important reality that software prototypes can easily forget.

Field engineers don't work from pristine desks with perfect Wi-Fi.

They work in plant rooms.

Basements.

Gyms.

Loading areas.

Warehouses.

And occasionally places where your phone appears to have forgotten that the internet exists.

So I've deliberately tried to think about the environment in which the system would actually be used.

Mobile usability, unreliable connectivity, quick interactions and reducing unnecessary input have influenced the project from the beginning.

There is plenty of technology underneath the prototype, but that isn't really what this project is about.

The interesting part is the thinking.

Understanding a workflow.

Finding friction.

Questioning why something exists.

Removing unnecessary steps.

Connecting information that currently lives separately.

And occasionally asking the dangerous question:

Why do we do it that way?

Sometimes there is a very good answer.

Sometimes there isn't.

Both are useful discoveries.

It's important to be clear about the project's current position.

Some elements use demonstration data, some workflows are experimental, and many areas would require considerably more development, testing, security review, integration work and organisational input before they could ever become a live operational system.

That's intentional.

The purpose of a proof of concept isn't to pretend you've finished.

It's to make an idea tangible enough that people can explore what might be possible.

Ultimately, this project isn't really about building another field service app.

It's about asking whether field service software can become less about recording what happened and more about helping people decide what should happen next.

Can an engineer have better information before opening their tool bag?

Can the office spend less time chasing information?

Can managers understand the operation without turning engineers into dots on a map?

Can customers feel informed without having to ask?

Can information generated through everyday service eventually help the wider business make better decisions?

Those are the questions I'm interested in.

And that's why I keep building.

Not because I think I've already found every answer.

But because after years of working in the field, I've collected quite a few questions worth asking.

The Field Service App is my attempt to start answering them.