Salesforce Implementation Services: 7 Essential Requirements
Umer Balaj
Founder and Salesforce architect12 January 202610 min read
A Salesforce implementation fails quietly. Nobody announces it. Two years in, half the team keeps a spreadsheet, reports get exported and fixed by hand, and someone proposes a rebuild.
The decisions that cause that are all made in the first six weeks. Below are the seven that matter, drawn from implementations we have run and, more usefully, from the ones we have been called in to repair.
Why implementations get rebuilt
Almost never because the software fell short. The common cause is a data model copied from how the business described itself in a workshop, rather than how it actually books revenue.
Once records are in the wrong shape, everything above them compensates. Automations get conditions bolted on, reports need manual correction, and adoption drops because the system asks for data nobody has at that moment.
The seven requirements
Treat these as gates. An implementation that skips one does not fail immediately, which is exactly what makes them easy to skip.
If a partner quotes a fixed price before requirement two is done, the number is a guess. Ask what happens to the price when discovery finds something. The answer tells you more than the figure.
What belongs in scope, and what does not
Most disputes are not about quality. They are about something each side assumed the other had priced.
| Work | Usually quoted | Should be |
|---|---|---|
| Data cleansing | Excluded, or billed hourly | Scoped after a real data audit |
| Integrations | One named system | Named systems, with error handling |
| User training | A single session | Sessions by role, on your records |
| Post-launch fixes | Out of scope at go-live | Thirty days minimum, included |
| Documentation | Rarely mentioned | Data model and automations, written |
How long it actually takes
For a team of 10 to 50 on a first implementation, with one integration and migration from a spreadsheet or an older CRM, plan on ten to fourteen weeks to go-live. The variance is almost entirely data.
- Discovery and data audit
- 2 weeks
- Data model and design sign-off
- 1 to 2 weeks
- Build, phase one
- 4 to 5 weeks
- Migration rehearsals
- 2 weeks
- Training and go-live
- 1 to 2 weeks
Choosing who does it
Certifications prove someone passed an exam. They do not prove anyone has migrated messy data under a deadline. Ask for these instead:
- Two references from implementations that went badly, and what they did about it.
- The data model from a comparable build, with the reasoning behind it.
- Who specifically will do the work, and what else they are on that quarter.
- What their change-order process is, in writing, before you sign.
- What happens in the thirty days after go-live, and whether it is priced.
Frequently asked questions
For a team of 10 to 50 with one integration and a straightforward migration, a first implementation typically lands between 12,000 and 45,000 USD depending on how clean the data is and how many processes are genuinely bespoke. The spread is wide because discovery changes the number. Anyone quoting precisely before discovery is guessing, and the guess is usually protected by change orders later.
Go-live is ten to fourteen weeks for most first implementations, but adoption is a separate curve. Expect four to six weeks after go-live before the org is the place people go first rather than the place they update afterwards. That gap shrinks when reps were involved in the pipeline design rather than shown it at training.
Usually no, and trying to is one of the most common reasons timelines slip. Migrate open records, the accounts and contacts attached to them, and enough closed history to make reporting meaningful, often two years. Everything older can be archived somewhere queryable without being loaded into the org.
Yes, and you should. Phase one is the data model, the core object relationships and one working process end to end. Integrations, advanced automation and reporting layers come after people are actually in the system. Phasing costs slightly more in total but dramatically lowers the risk.
The first month generates more requests than any month after it, because real use surfaces everything that discovery missed. Plan for that capacity, either with a retained team or a named person internally who owns the backlog. Implementations that go quiet after go-live are usually not finished. They are abandoned.
Umer has led CRM builds across 100+ engagements and 20,000+ delivered hours, most of them inside orgs someone else built first. He writes about the sequencing decisions that separate an implementation people use from one they work around.
