Diagnosis
Signs your Salesforce implementation failed — and how to fix it
A Salesforce implementation has failed when the sales team keeps a private spreadsheet, leadership does not trust the forecast, or nobody can explain why a field exists. The fix is almost never starting over in a new org. In most cases the right move is a reimplementation in place: audit what is actually used, remediate the data, rebuild the two or three processes that matter, and retire the rest — typically 8 to 20 weeks, without taking the revenue team offline.
Last updated July 30, 2026 · Skydog Ops
The symptoms, in order of severity
- Reps maintain a shadow spreadsheet. This is the definitive signal. Everything else is a matter of degree.
- Leadership adjusts the forecast by instinct before presenting it. The system is producing numbers nobody defends.
- Deals are entered at the end of the quarter, not when they happen. The CRM is a reporting chore rather than a working tool.
- There are twelve required fields on the opportunity and four of them are always the same value.
- Nobody can say what a stage means. Two reps describe 'Negotiation' differently.
- Reports exist in a folder nobody opens, and the real number comes from a spreadsheet a RevOps analyst maintains.
- The admin queue is entirely break-fix. No one has shipped an improvement in six months.
- Automation fires and nobody knows what triggered it, so nothing gets changed for fear of breaking something.
Why implementations fail
| Root cause | How it shows up | Fixable in place? |
|---|---|---|
| Process was never defined | Stages copied from a template; no exit criteria | Yes — this is the most common and most fixable |
| Built for management reporting, not for reps | Heavy required fields, no workflow value to the person entering data | Yes |
| Dirty data migrated in | Duplicates, orphaned records, unreliable owner history | Yes, with a remediation phase |
| No enablement after go-live | Team trained once, never again; new hires learn from each other | Yes |
| Over-customization | Custom code and triggers nobody understands, blocking every change | Usually — selective retirement rather than rebuild |
| Fundamentally wrong data model | Objects that do not describe the business at all | Sometimes — this is the one case where a new org may be right |
Reimplementation beats starting over
A new org means re-migrating data, rebuilding every integration, retraining everyone, and losing history — while the original problems, which were usually about process rather than platform, follow you across.
Reimplementation works in the existing org: audit usage against configuration, decide what earns its place, remediate data, rebuild the two or three processes the business actually runs on, and retire the rest deliberately. Integrations, history, and licenses stay intact.
- Weeks 1 – 3: audit. Field usage analysis, automation inventory, data quality assessment, and interviews with the people who avoid the system.
- Weeks 4 – 6: process redesign. Stage definitions with exit criteria, a required-field set the team will actually complete, and a reporting model leadership signs off on.
- Weeks 7 – 14: rebuild and remediate. Deduplication, automation consolidation, and configuration changes released in increments while the team keeps working.
- Weeks 15 – 20: enablement and handover. Documentation, admin training, and a change process so it does not drift again.
When a new org is genuinely the answer
- The data model does not describe the business and never did — for example, a services business modeled entirely as product transactions.
- A merger requires consolidating two orgs, and neither is the obvious survivor.
- The org is on a retired edition or carries technical debt that blocks the products you need to buy.
- Even then, most of the reimplementation work still has to happen. A new org does not skip the process definition step; it just adds a migration to it.
CRM Reimplementation™ at Skydog
CRM Reimplementation™ is Skydog's term for exactly this work: coming into a Salesforce or HubSpot implementation that went wrong and fixing it in place, without a rip-and-replace and without taking the revenue team offline.
Engagements start with a paid audit that produces a written finding on what to keep, fix, and retire — deliberately useful whether or not you continue with Skydog.
FAQ
Common questions
How do I know if our Salesforce implementation failed?
The clearest signal is that the sales team keeps its real pipeline somewhere else — a spreadsheet, a notes app, or their heads. Supporting signals include leadership adjusting the forecast by instinct, deals entered only at quarter end, and required fields that always hold the same value.
What percentage of CRM implementations fail?
Industry estimates of CRM project failure range from roughly 30% to 70% depending on how failure is defined. The wide range says more about the definition than the software: most 'failures' are adoption failures, where the system works as configured but the team does not use it.
Should we start over with a new Salesforce org?
Usually no. A new org re-incurs migration, integration, and training cost while carrying the original process problems across. Starting over is justified when the data model fundamentally does not describe the business, or when a merger forces consolidation of two orgs.
How long does it take to fix a broken Salesforce implementation?
Eight to twenty weeks for most organizations: three weeks of audit, three weeks of process redesign, and the remainder rebuilding and remediating in increments while the team keeps working in the system.
How much does it cost to fix a failed Salesforce implementation?
Typically $60,000 to $200,000 in partner fees, against $150,000 or more for a full rebuild in a new org. The audit phase is usually priced separately and small, so you know the scope before committing to the remediation.
Can we fix Salesforce without disrupting the sales team?
Yes, if changes ship in increments rather than as a single cutover. Audit and data remediation happen in the background; process and configuration changes are released in small releases with enablement attached to each. There is no reason for a reimplementation to require a system freeze.
