The Implementation That Failed First

The Problem

Our client's field operations — scheduling, dispatching, work orders, technician management — were running on ServiceTitan. It wasn't the right fit for the business, and the cost wasn't justified by what it delivered. A migration was necessary.

That part was never in question. Everyone agreed the platform had to change. The disagreement — though nobody framed it that way at first — was about how to change it, and who got a say. That unspoken disagreement is what sank the first attempt.

This is worth sitting with, because it's the crux of the whole story. The field service software wasn't the hard problem. The organization's readiness to adopt a new one was.

The First Attempt

The initial migration targeted Salesforce Field Service Lightning. It had executive sponsorship. It had a defined timeline. It had a development team and a budget. On paper, it had everything a project is supposed to need.

What it didn't have was the department lead.

The person whose team would live in the system every day was resistant from the start. Requirements shifted continuously — every time the project team thought it had a spec, it moved, because the requirements were being defined for the department lead rather than with them. When deployment finally arrived, the department lead raised concerns that the rollout would destabilize the HVAC operation — the revenue engine of the business. Faced with that risk at the eleventh hour, the president pulled the plug.

Months of work. Real money. Nothing shipped.

The instinct in that moment is to blame the holdout — to conclude the project would have succeeded if not for one uncooperative manager. That's the wrong read, and acting on it would have guaranteed the next attempt failed the same way. The resistance wasn't the problem. It was the symptom. The project had run a top-down selection process and then asked the person who'd absorb all the operational risk to be enthusiastic about a decision they had no part in making. They weren't being difficult. They were being rational. Anyone protecting a working operation should be skeptical of a system chosen without them.

What We Did Differently

We didn't relaunch the project. We changed who owned it.

The department lead was given ownership of the software search from the beginning — not consulted, not surveyed, but genuinely put in charge of it. They built their own evaluation criteria, grounded in what the HVAC operation actually needed day to day, and identified their top three candidates. In parallel, and deliberately kept separate, we ran our own evaluation on our own criteria, weighing integration requirements, total cost, and fit with the broader systems roadmap.

Then we compared lists.

FieldPulse was number one on both.

That convergence is the entire mechanism. Alignment wasn't negotiated after the fact or manufactured in a kickoff meeting — it emerged from two independent processes landing in the same place, before a contract was signed. There was no buy-in to win, because there was nothing to win it against. The person most likely to resist had instead arrived at the same answer on their own, which made them the change's advocate rather than its obstacle.

From there the work was almost anticlimactic: contract negotiation, implementation planning, and a migration path the operations team helped define rather than received. The hard part — the human part that killed the first attempt — had already been solved by the process itself.

The Outcome

The migration to FieldPulse is underway with cross-functional alignment and a clear implementation path. Projected savings: $60,000 per year in platform costs.

The number matters less than the second-order effect. The first attempt produced a sunk cost and an organization more skeptical of the next initiative. The second produced a team that's moving into a system they chose — which is the difference between an implementation and an adoption problem you'll be managing for the next two years.

Why This Matters for Your Business

The specifics here are field service software. The pattern is not.

If you've ever bought a system that nobody uses, paid for licenses that sit idle, or watched a rollout stall because one department dug in — this is that story. It's the most common way software money gets wasted, and it has almost nothing to do with the software.

The person who has to live in the system gets a vote. Not a demo invitation. Not a feedback session after the shortlist is set. An actual vote, early, with real weight. Anything less and you're buying resistance along with the license.

Executive sponsorship is not the same as buy-in. The failed attempt had the president's backing, a budget, and a team. It still died. Authority moves a project forward; ownership is what makes it land.

A failed implementation isn't a total loss if you're honest about why. The first attempt told us exactly what the second one needed. Most organizations skip that step, blame the tool, and repeat the pattern with a different vendor.

We've been on both sides of this. That's why we can tell you which one you're heading toward.