Why Salesforce projects fail two weeks after go-live
Go-live is the easy part. The failure we see on calls happens afterwards, and it has the same three causes every time. Here they are, with what prevents each, and a checklist for the first month after launch.
Bohdan PyrihCEO, Advirix1. The team that sold is not the team that stays
A senior person runs the sale and the first weeks. Then the project moves to people the client has never met. Context leaves with the senior person; the client notices when the first change takes a month. At Viedoc, a clinical-trials platform in Sweden, a large partner had launched Salesforce for 52 users and then left. Nobody on the client side had been told how the org was built. We took it over as a Run engagement and spent the first week on a full review before touching anything.
What prevents it: the team is named in the proposal and does not change. Not a promise, a list. And a handover document that exists before the partner leaves, not after.
2. Changes go straight to production
Without environments, user acceptance testing and a rollback path, every Friday fix is a Monday incident. At GoodLeap, a lender with several Salesforce orgs, a nightly transfer of 20,000 records had been breaking about every two weeks for months; nobody could say which change had caused it, because changes were not recorded. The fix was not clever code. It was a release process: development, test and user-acceptance environments, a go/no-go, smoke tests, a rollback tested before the window. Thirteen releases later, no incidents.
What prevents it: a governed release for every change, however small, with a change record the compliance team can file. Who asked, who built, who tested, who approved, how it rolls back.
3. Only the vendor understands the org
Customisations inside a managed package, undocumented integrations, a forecasting module nobody switched on. The client cannot leave, so the vendor stops trying. At 49 Financial, the wealth firm had extended through a managed package and hit its limits: fields, storage, automation that could not be changed. The way out was a documented layer around the package, with child and external objects and event-driven integration, so the firm kept the accelerators and could still leave.
What prevents it: a documented layer around what you bought, and documentation you keep. The client must be able to leave; that is why they stay.
The quieter fourth cause: nobody owns it
The admin left, or was never hired, and the partner's project manager was the de facto owner. When the project ends, so does ownership. Licences keep renewing; logins stop. This one does not announce itself as a failure. It shows up a year later as "we pay for Salesforce and nobody uses it".
What prevents it: one named owner on the client side before go-live, with a Run engagement or an admin behind them, and a monthly list of what changed.
A checklist for the first month after go-live
- Is there a document that says how the org is built, and did someone on your side read it?
- Can your admin see every user with access, by name, and revoke any of them without calling the partner?
- Is there a test environment, and was the last change tested there before production?
- Does every change have a record: who asked, who built, who approved, how it rolls back?
- Do the integrations alert a person when they fail, or do you find out in the morning?
- Are logins going up or down week over week? If down, which screen do people avoid, and why?
- Who owns the backlog, and when does it next get reviewed?
Two "no" answers out of seven is normal. Four is where the project starts failing quietly.
Two signs on the sales call that predict it
First: the senior person cannot name who will be on the project. "Our team" is a bench, and a bench rotates. Second: when you ask how a change reaches production, the answer is about agility rather than about environments. Both are answerable in a sentence by a partner who has a process. Both are deflected by one who does not. Neither costs anything to ask, and together they predict most of the failures above.
If the partner has already left
Do not start with a roadmap. Start with a review: five days, read-only, every finding with a price. Then the one thing that hurts most, in two weeks. The order matters: a new partner who proposes a project before reading the org is repeating the first partner's mistake with a different logo. At Viedoc the first week was a review, and the first fixes came from what the review found, not from what anyone assumed.
If you recognise one of these, a Health Check tells you which, in five days, with a price next to each finding. If the partner has already left, Run starts with a full review in the first week.