-
Sarah Machin
Sarah MachinA behind-the-scenes look at what it takes to successfully implement Salesforce Field Service, from someone who did it, and did it well. Sarah Machin, our Business Change Consultant, reflects on the journey from “Engineer Schedule v9_FINAL_FINAL.xls” to an intelligent business hub during her time as Business Service Director.
The conversation didn’t start with a strategy document or a digital transformation roadmap.
It started the way many operational improvements do — in the middle of a meeting, with someone quietly asking a very sensible question.
Someone had opened a spreadsheet to check the engineer’s schedule for the week. Another person had a different spreadsheet open that seemed to show slightly different information. A third person was scrolling through emails, trying to confirm which update had arrived most recently.
After a few minutes of comparing notes, someone asked:
“Out of curiosity… which version of the spreadsheet are we actually using?”
A short silence followed.
Someone replied, “I think it’s the one I sent yesterday.”
Someone else said, “I made a few updates this morning.”
At that moment, it became clear that the organisation had reached a milestone that many service businesses eventually encounter:
The spreadsheet had quietly become the system.
As I look back, that moment felt like the beginning of a much bigger shift — one where the organisation stepped back and asked whether there might be a more connected way of managing field operations.
Ideally, one that didn’t involve quite so many files called Final_v9_THIS_ONE_REALLY_FINAL.xlsx.
When “it works” isn’t enough anymore
In my previous role, before Salesforce Field Service was introduced, coordinating field work relied on a mixture of tools and a lot of careful human coordination.
Schedules were maintained in spreadsheets. Updates were shared through email. Important details lived across shared folders, documents and occasionally someone’s notebook.
And to be fair, it worked.
In fact, systems like this often work surprisingly well because the people running them become experts at keeping everything aligned.
Schedulers know exactly where to look for information. Engineers understand the process. Managers know who to ask when something needs updating.
But as organisations grow, those systems start to feel more than a little stretched.
Schedules take longer to update. Information has to be checked in multiple places. And occasionally someone asks the question that makes everyone glance nervously at their inbox.
“Does anyone know which version of this file is the latest?”
At that point, people check their emails just to make sure and occasionally mild panic spreads across the room.
None of this means the process was poorly designed. It simply evolved and was now supporting a much larger operation than it was originally built for.
The opportunity wasn’t just to introduce a new system; it was to simplify how everything worked together.
Every operations team has a spreadsheet whisperer
If you spend enough time around service operations, you’ll eventually meet the spreadsheet whisperer. In my experience, every team has one.
They built the master spreadsheet several years ago. It has multiple tabs, impressive formulas and possibly a macro that nobody else is brave enough to touch.
If something breaks, they know exactly where to look.
If a column moves, they know which formula needs fixing.
If a pivot table starts behaving strangely, they somehow persuade it back into line.
To everyone else, the spreadsheet looks slightly mysterious, but to them, it makes perfect sense.
The only challenge is that when a critical operational process relies heavily on one person’s understanding of a complex spreadsheet, the organisation has unintentionally created a single point of failure disguised as an Excel file.
Moving that knowledge onto a shared platform improves resilience — even if it slightly reduces the spreadsheet whisperer’s reputation as the only person who can “fix the system”.
On a positive personal note, the whisperer can now take the occasional holiday in peace…
Bringing field operations into one place
One of the biggest changes after introducing Salesforce Field Service was surprisingly simple.
Everything moved into one place.
Instead of job details, schedules and updates living across several different tools, they could all be managed within the Salesforce platform.
For people coordinating the work behind the scenes, this made a noticeable difference.
Schedulers could see workloads clearly. Managers had better visibility of what was happening across the field teams. Job histories were easier to find.
For engineers, having job information available on mobile devices was equally valuable.
They could review details, capture notes and update records while still on site — which meant fewer administrative tasks waiting at the end of the day.
The improvements weren’t dramatic or flashy.
Things just started running more smoothly.
And there were fewer moments where someone had to call a colleague and ask them to “quickly check the spreadsheet”.
Discovering the hidden systems
Digital transformation projects often reveal something interesting.
Once you start mapping how work actually happens, you discover a small ecosystem of unofficial supporting systems.
There might be:
- a spreadsheet tracking engineer availability
- a document listing special customer instructions
- a shared folder containing site photos
- or a notebook someone carries because it’s still the fastest way to jot something down
None of these exists because people want complicated processes.
They exist because someone solved a practical problem.
Over time, though, they create a landscape where information lives in several different places.
A unified platform doesn’t remove these workarounds overnight, but it does start bringing operational information back together.
Which means fewer moments where finding an update feels like a digital treasure hunt.
The curious case of the Friday admin day
One of the more interesting changes that happens with mobile field service tools involves something many engineers quietly recognise:
The unofficial Friday admin day.
In many service teams, the end of the week becomes the time when engineers catch up on paperwork – entering notes, updating systems and finishing reports from earlier in the week.
It’s rarely written into the official schedule.
But everyone knows it exists.
Once engineers can update records directly from their mobile devices while they’re on site, much of that catch-up work disappears.
Job notes are captured immediately. Updates happen in real time.
From an operational perspective, the impact can be significant.
If every engineer gains back even half a day previously spent on administration, that time can now be used for additional service work.
Multiply that across an entire team, and the numbers quickly become impressive.
From the perspective of the senior leadership team, giving every engineer back a day of productive time each week can make you look like an operational hero.
From the engineers’ perspective, however, the reaction may be slightly more complicated.
After all, if Friday used to be the quieter admin day, turning it back into a fully scheduled workday might make you very popular with the CFO…
…but slightly less likely to appear on the engineers’ Christmas card list.
Small moments that show the system is working
Every field service implementation has a few small moments that signal things are working.
There’s the first time an engineer closes a job entirely from their phone and says:
“That was actually easier than before.”
There’s the moment a scheduler realises they can see everyone’s workload without opening three spreadsheets.
And there’s usually a meeting where someone discovers that information they used to chase through several email threads is now available instantly.
None of these moments appear on the official project timeline.
But they’re often when people realise the system is genuinely helping.
The day the scheduler trusted the automation
There’s another milestone that happens quietly during most field service implementations.
It’s the day the scheduler trusts the automation.
Schedulers usually know their operations inside out. They know which engineers prefer certain areas, which jobs need extra time and which routes work best during different parts of the day.
When automated scheduling is introduced, they naturally keep a close eye on it.
The system creates a schedule.
And the scheduler adjusts it.
Then one day, something unexpected happens.
The schedule looks… right.
Routes are efficient. Workloads are balanced. Travel time makes sense.
The scheduler reviews it and realises there’s nothing to change.
That moment may seem small, but it’s an important milestone.
The system is no longer just recording work.
It’s helping plan it.
Getting buy-in from the CEO
Projects like this also need support from the top.
Getting buy-in from the CEO usually isn’t about the technology itself. It’s about what it enables for the organisation.
The conversation tends to focus on questions like:
- How efficiently are we delivering services and can we prove it?
- Can our operations scale as the business grows?
- Do we actually have visibility of what’s happening day to day?
- Can we make more money from this?
Platforms like Salesforce Field Service provide something many growing organisations struggle with – a clear operational picture.
Instead of piecing together reports from multiple sources, leadership teams can see service activity, utilisation and performance much more clearly.
It moves the conversation from “what happened last month?” to “what’s happening right now?”
And that level of visibility tends to resonate very quickly with leadership teams.
Go-live week: The real test
No implementation story is complete without mentioning go-live week.
There’s always a mixture of excitement, nervous energy and a lot of last-minute checking and re-checking.
Schedulers review routes again. Engineers test the mobile app. Someone inevitably suggests running the old system “just in case”.
Then the first real jobs start coming through the system.
The day goes more smoothly than everyone feared, and breathe!
There might be a few quick adjustments, a couple of “how do I do this again?” questions, and at least one engineer who prints their job sheet just in case.
But by the end of the week, something interesting happens.
The new system already starts to feel normal.
Which is usually the best possible outcome.
Looking back: It’s not really about the software
Looking back on the implementation, it’s clear the project wasn’t really about introducing new software.
It was about evolving how the organisation works.
Over time, the changes start to influence how teams collaborate, how information flows and how decisions are made.
Day to day, the improvements might feel small.
But gradually things run more smoothly.
And if the result includes fewer spreadsheets, fewer “final version” attachments and slightly calmer conversations with the finance team, that’s usually a good sign the change was worthwhile.
Because when engineers, schedulers, managers and leadership teams all feel like things are working better, it usually means the organisation has found a better way of doing things.
Which, in the end, was the whole point of asking that original question:
“Is there an easier way to do this?”
Key Takeaways for Leaders
For organisations considering a field service transformation, a few lessons tend to stand out:
- Technology is only part of the story – Real transformation happens when systems, processes and people evolve together.
- Small efficiencies scale quickly – Saving a few minutes per job can translate into significant gains across an entire field workforce.
- Operational visibility matters – When leaders can see what’s happening across the operation in real time, decision-making improves dramatically.
- Adoption is everything – The most successful implementations involve engineers, schedulers and managers from the beginning.
- And finally, every organisation eventually retires a spreadsheet that once ran the entire operation.
When that day arrives, it’s usually a good sign the business has taken a step forward.