Sales Cloud · implementation and rebuild
Most Sales Cloud projects fail on scope,
not on Salesforce.
Describe the shape of your rollout below. You get the phases, the elapsed weeks, an investment band and, more usefully, the specific risks that this shape of project carries. No form, no call, no email.
Elapsed
-
Fixed price
-
Scale
-
Engagement
-
What makes up the price
Phases
Every line above is a fixed price, not a range. It becomes the contract price once the written scope is signed, and it cannot move upward afterwards. Everything is built inside your own org and documented as the work happens, so nothing here depends on any one person staying available.
What actually takes the time
The build is the short part.
Nobody underestimates configuration. What blows the timeline is data that will not migrate cleanly, integrations owned by a team that has other priorities, and a sales organisation that was never asked what it needs.
Discovery that ends in a written model
Objects, record types, stages, roles, sharing. Written down and signed off before a field is created. Skipping this is what produces the rebuild eighteen months later.
Data migration
Deduplication, owner mapping, historical activity, attachments. The volume matters less than how many systems the records came from and whether anyone can decide which version wins.
Integrations
Each connected system is a separate small project with its own owner, its own credentials and its own change window. Two is routine. Five is a programme.
Adoption
Training, a launch that does not land in quarter end, and someone in-house who can change a field without opening a ticket. This is where implementations quietly fail after go-live.
Fit
Worth reading before you book.
This is for you if
- Between 10 and 300 sales seats, and a real revenue process to encode
- You want the architecture written down, not held in a consultant's head
- You would rather pay once than retain an agency indefinitely
- Someone in-house is willing to own the system after handover
- You want the build documented as it happens, not summarised at the end
This is not for you if
- You need twenty people on site from Monday
- Procurement requires a partner tier on the invoice
- The requirement is "make it like our old system, exactly"
- Nobody internally can be freed up to answer questions weekly
The base package
What EUR 13,000 already contains.
Most quotes hide the base and itemise the extras, which makes comparison impossible. This is the opposite: the base is fully described, and everything above it is a line you can strike out.
A written data model
Objects, fields, record types, page layouts and the relationships between them, documented before a single field is created. This document outlives the project. When a new administrator joins in two years, it is what they read first.
The revenue process, encoded
Stages with exit criteria that mean something, not a list of nouns. Lead and opportunity conversion, ownership rules, and a sharing model that reflects who is actually allowed to see what. Up to 25 seats and one selling motion.
Reports and dashboards that get used
A pipeline dashboard for the VP, an activity dashboard for managers, and a personal view for each rep. Built from the questions your leadership actually asks in the Monday meeting rather than from a template.
Training and documentation
Two sessions: one for administrators, one for the people who will live in the system daily. Both recorded. Administrator documentation covers not only what was built but why, so future changes do not undo past decisions by accident.
Sixty days after handover
Questions answered, small fixes made, and one review session at the end of the period to catch what surfaced only once real work went through the system. This is part of the price and is never invoiced separately.
Failure patterns
Five ways these projects go wrong.
None of these are Salesforce problems. All five are decisions taken, or avoided, before anything is configured.
The stages describe the seller, not the buyer
"Proposal sent" says what your rep did. It says nothing about whether the customer is any closer to buying. Pipelines built this way forecast badly, because a deal can sit in a late stage indefinitely while the buyer has quietly moved on. Exit criteria have to be observable from the customer's side.
Everyone gets every field
The fastest way to kill adoption is a page layout with sixty fields, of which nine matter. Reps stop filling any of them, the data degrades, and within a year the reporting that justified the project no longer works. Fields have to earn their place by being used in a report, an automation or a conversation.
Migration is left until the end
Data is treated as a task rather than a phase, scheduled two weeks before launch, and then someone discovers that the old system has three records for the same company and nobody can decide which one survives. That decision belongs to the business and it takes longer than the technical work.
Automation is written by whoever is available
Over five years, four people each add a rule that solves the problem in front of them. Individually they are fine. Together they fire on the same record in an order nobody has ever traced. This is what makes a rebuild cost more than a greenfield build, and it is why an audit belongs in front of one.
Nobody owns it on day ninety-one
The consultant leaves, the documentation was never written, and the only person who understood the design is no longer answering. Small changes stop being made, the system drifts from how the team actually sells, and eighteen months later somebody proposes replacing it. This is the most expensive failure of the five and the easiest to avoid.
Before we start
What you need to have ready.
None of this is difficult, but a project where these are missing runs slower and costs more, because discovery turns into archaeology.
Have ready
- A named decision maker who can settle a disagreement between two teams in one meeting
- Two hours a week from someone who actually sells, not only from someone who manages
- An export of whatever you use today, however messy it is
- A list of the reports leadership looks at, even if they live in a spreadsheet
- Admin credentials for the systems you want connected, or the name of whoever holds them
Not needed yet
- A finished requirements document. Discovery produces it
- Clean data. That is the migration phase, not a prerequisite
- Salesforce licences purchased in advance
- Agreement across the whole company. Two teams disagreeing is normal and gets recorded
Questions
Asked often enough to answer here.
How does a solo consultant compare with a Salesforce partner?
A partner brings a team, a methodology and a logo procurement recognises. That is worth paying for above a certain size. Below it, you are funding a delivery manager, a solution architect and two junior configurators, of whom one does the work. For mid-market scope, senior-led delivery costs less and produces a system fewer people have touched.
Why is Sales Cloud implementation priced fixed rather than hourly?
Hourly billing pays the consultant for being slow. A fixed price on a written scope moves that risk to me, which is where it belongs, since I am the one who can estimate it. If I am wrong about how long something takes, that is my problem, not a change order.
Are Salesforce licences included in the implementation price?
Not included and never marked up. Licences are bought directly from Salesforce at whatever you negotiate. I will tell you which edition your requirements actually need, which is frequently one tier below what was quoted to you.
Can the implementation work alongside an in-house admin?
Preferably. An in-house administrator who sits in discovery and shadows the build ends the project able to maintain it, which is the whole objective. It also shortens handover, and that is reflected in the estimate.
Should Agentforce be part of a Sales Cloud implementation?
Yes, but not first. An agent deployed on a foundation that was built last month is a different proposition from one deployed on five years of drift. If Agentforce is on your roadmap, say so in discovery and the data model gets built with that in mind at no extra cost.
Bring the estimate to the call.
Thirty minutes. Read out what the estimator gave you and I will tell you where it is optimistic, where it is generous, and what I would cut first.
Serhii Skrypnyk · RevOps Architect · 7 Salesforce certifications · on the platform since 2018