For contractors whose Salesforce or Field Service project stalled, went over budget or left dispatch back on spreadsheets, we triage the build and get crews working in it again.
Rescuing a trade contractor's implementation starts with whatever is keeping dispatch off the system. That might be a scheduler that errors on longer jobs, technicians who cannot close work orders offline, automation that sends a flood of notifications on every change, or a license plan that priced subcontracted labor out of reach. We triage quickly, fix the blockers that stop crews from being scheduled and billed, and then decide with you which parts of the original design to keep, repair or remove. The aim is a stable, working org, not a restart.
Field service projects fail in particular ways. Partners without trade experience often build the scheduler around single-visit calls and then find it cannot handle multi-day installs or crews. Licensing gets planned for every worker, including subcontracted labor who never needed full access, and the cost makes the business pull back. Mobile flows copy office forms, so technicians abandon them within weeks. Integrations to accounting are left half finished, which means hours and parts are still keyed by hand. By the time a rescue is requested, office staff have usually rebuilt parallel spreadsheets and trust in the system is low, so early visible wins matter as much as technical fixes.
We test the scheduler with real job types and durations and find where it fails. An industrial-services firm came to us after a previous partner's Field Service build errored on longer projects; correcting the multi-day appointment configuration allowed them to schedule extended jobs again. We apply the same approach to installs, shutdowns and multi-crew projects, alongside service calls that need to fit around them.
Contract crews rarely need to touch the app themselves. In that same engagement, we tracked outside laborers and their credentials on a custom object, which removed the per-worker licensing that had made the build unaffordable. We review which users truly update records from the field, which only need to appear on schedules, and which should use simpler forms, and design access around those roles.
Failed builds commonly leave flows with hard-coded users, notifications that fire in bursts and work orders that must be entered twice. We restructure task-creation flows to use variables, remove redundant triggers and set up a two-way sync between work orders and service appointments where the design had them drifting apart. Saves get faster, dispatch stops reconciling two records, and inboxes get quieter.
Technicians judge the whole project by the mobile app. We rebuild the core flows for arriving, logging time and parts, capturing photos and closing a job, keep them short, and pilot with a few respected technicians before rolling out. Their feedback shapes the release, including field names and step order, and a working app is the fastest way to retire the paper tickets that returned.
A rescue opens with a short assessment: interviews with the owner, service manager, dispatch and a field lead, a review of the org and any documentation, and a list of what was promised versus what works. We rank issues by effect on scheduling, billing and crews, then stabilize the top items first, often in a tightly scoped engagement. Changes are tested in a sandbox against real jobs and released in small steps with clear notes. Once dispatch is running reliably, we plan the remaining work as an ordinary roadmap.
Half-built invoicing and job cost connections are finished or replaced, and reconciled against real jobs so month-end stops depending on rekeyed hours.
We fix inventory mappings so parts consumed in the field reduce the right stock location and transfers between trucks do not create phantom quantities.
Where bids never connected to Salesforce, we link estimate totals and scope to opportunities so won work arrives in project setup without retyping.
It is tempting to redesign everything once problems are visible. Fix what blocks dispatch and billing first, then decide on larger changes with evidence from a stable org. A system that works modestly is easier to improve than one that is being rebuilt while crews wait.
Much of a failed build is usually salvageable, such as the data model, some flows or the integration framework. An honest inventory of what can be kept protects the money already spent and shortens the path to a working system for dispatch and the field.
Office staff and technicians may have stopped believing the system will work. Announce fixes, show results in morning meetings and invite the loudest critics into testing. Parallel spreadsheets fade once people see the system handle a busy day without problems.
Client names are anonymized.
Most can be saved. The data model and much of the configuration are often sound, with problems concentrated in scheduling setup, automation and mobile design. We assess before recommending anything, and if parts truly need rebuilding we say which and why. Starting over throws away work already paid for and resets adoption, so it should be a conclusion from evidence rather than a reflex.
It depends on what is broken, but we aim for visible progress early. Scheduling errors and runaway automation can often be fixed in a short, focused engagement once diagnosed. The industrial-services rescue we mentioned above fit that pattern. Larger issues such as an unfinished accounting integration take longer and are planned as their own phase after dispatch is stable.
Yes, when it exists. We compare documents against what is actually configured, because the two often differ after a troubled project. Where documentation is missing, we produce a current-state summary as part of the assessment. That record becomes the baseline for your internal team or any future partner, which reduces the chance of repeating the same mistakes.
Admin access to production and a sandbox, the original statement of work, any design documents, a list of known problems from dispatch and the field, and the spreadsheets people now use as workarounds. Those spreadsheets are especially useful, because they show exactly which jobs and steps the system was meant to handle and currently does not.
One onshore team with 150 Salesforce certifications, a Salesforce Consulting Partner since 2017.
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.