Sales Cloud · what the number is made of
The cost is hours.
Seven decisions move them, and none is the seat count.
Two companies of the same size get quotes that differ by a factor of three, and neither quote is dishonest. They are pricing different scopes with the same words. Below is what actually moves the hours, so an estimate can be read rather than compared on the total.
Reviewed 30 August 2026.
Before the seven
Hours and elapsed weeks are two different numbers.
Almost every disappointment in this category comes from treating them as one. Hours are the work: they are what gets billed and they are reasonably predictable once the scope is written down. Elapsed weeks are how long it takes in the calendar, and they are decided mostly by how fast decisions arrive from your side and how long real users take to test.
A build can burn its hours in six weeks and still take five months. When that happens the usual conclusion is that the estimate was wrong. Usually the estimate was right and the thing being measured was the wrong thing.
What moves the hours
Seven decisions, in the order they usually surface.
Each of these is a decision about your business rather than a line in a price list, which is why two companies with the same headcount and the same product get different numbers. An estimate that has not asked about all seven is a guess with a number attached.
Distinct permission shapes, not seat count
Twenty-five seats that all work the same way is one shape. Split the same twenty-five into inside sales, field sales, a manager tier that sees everything and a finance user who sees amounts but not notes, and it is four. Each shape is a profile or permission set, a page layout, a set of sharing rules and a test of its own. Ask how many genuinely different jobs the seats do. That number moves the hours far more than the seat count does.
How many systems the data comes from
One clean export from one system is a day. The same record count arriving from a CRM, a spreadsheet somebody maintains and an accounting package is not three times the work. It is more. Somebody now has to decide which source wins when the three disagree about a company name, an owner or an address. That decision is a meeting, not a script.
Integrations priced on the failure cases
The happy path of an integration is usually a day. What costs is what happens when the other side is down, returns a record that already exists, or changes a field name without telling anybody. An integration with no agreed behaviour for those three is not finished, it is deferred, and it comes back as an incident during the first busy week.
Whether there is existing automation to unpick
A greenfield org is cheaper than an org with four years of workflow rules, process builders and a managed package nobody remembers installing. Before anything new is built, somebody has to establish what currently fires on save and in what order. On an org that has been running a while, that archaeology is routinely the largest single item and it is invisible in every quote that has not looked.
The number of definitions that have to be agreed
Reports are cheap. Agreeing what qualified means, when a deal is committed, and which date counts as the close date is not, because it is not a configuration task at all. It is getting two or three people who currently disagree to write one sentence down. Implementations stall here more often than they stall on anything technical.
Approvals and quoting, if they are in scope
Discounting rules, approval chains and anything resembling a quote add a disproportionate amount, because they are the part where finance and sales have different requirements and both are correct. If this is in scope, it should be scoped and priced as its own phase rather than folded into the build, where it silently doubles.
Who is available to answer questions
The cheapest implementations have one named person who can decide, reachable within a day. The expensive ones have a committee. This is not a soft factor: a decision that waits a week stops a workstream, and the hours spent re-establishing context when it resumes are real hours that appear on the invoice.
What quietly inflates it
Seven ways the number grows after it was agreed.
None of these appear in a scope document. All of them appear on the invoice, and every one is cheaper to prevent in week one than to correct in week nine.
Discovery that produced a document nobody signed
A discovery phase that ends without a written data model and a named person who agreed it has not ended. It will be repeated in week six, at full rate, under time pressure.
Migration planned against record count
Somebody estimates the migration from how many rows there are. The work is in how many fields need a mapping decision and how many of those decisions have no obvious answer. Ten thousand clean rows are cheaper than eight hundred dirty ones.
Testing by the person who built it
The builder tests the path they had in mind. What breaks is the path somebody else takes. If nobody from the team that will use the system has tried to do their actual job in it before go live, the first week of use is the test, and fixing in production costs more.
Training scheduled after go live
Training a week after the system is live means the team spent that week building habits around the parts they guessed at. Those habits then have to be undone, which is harder than teaching nothing at all.
Everything routed through one sandbox
Building and testing in the same place means an unfinished change is visible to whoever is testing, and the resulting confusion is billed as investigation. This is cheap to get right at the start and expensive to introduce halfway.
Reports left to the end
Reporting is treated as the last phase, so the definitions that reports depend on are settled last, after the data model that should have expressed them is already built. Report requirements belong in discovery precisely because they expose disagreements early.
A go live date chosen before the scope
The date is announced to the business, then the scope is written to fit it, then the scope turns out to be larger. What gives is testing and handover, which are the two things that decide whether anybody still uses the system in a year.
How to read a quote
Ask for the hours, not the total.
A total can be compared only against another total for the same scope, and the scope is exactly what differs. Hours can be compared directly. Ask what rate produced the number, how many hours it contains, and what happens when the estimate turns out to be wrong: who absorbs it, and at what point you are told.
Then ask which of the seven above the estimate assumed. The answers are more informative than the price, because an estimate that assumed a clean export and one that assumed three source systems are not competing offers at all.
Asked often enough to answer here
Questions
So what does a Sales Cloud implementation actually cost?
On this site, 8,700 euro for 174 hours at the smallest honest scope, which is a written data model, objects and stages, sharing, reports, up to twenty five seats, training and a sixty day handover. That number is hours multiplied by fifty and it is published rather than quoted, so it can be compared. What moves it is the seven items above, and an estimate that has not asked about all seven is a guess wearing a number.
Why do quotes for the same company differ so much?
Because most of them are pricing different scopes while using the same words. One includes migration from three systems and one assumes a clean export. One includes the approval chain and one calls it phase two. The way to compare is to ask each quote how many hours it contains and what happens when the estimate is wrong, rather than to compare the totals.
How long before the team is actually working in it?
Six weeks of elapsed time at the smallest scope before go live, and the honest answer for adoption is a few weeks after that. Elapsed time is decided by how quickly your side answers questions and how long real users take to test, and both of those belong to you rather than to the builder. A build can consume its hours in six weeks and take five months if decisions wait a week each time.
Can the scope be cut to bring the number down?
Yes, and there is a right order to cut in. Integrations, approvals and quoting come out first and become their own phase, because they are self contained. Seats and reports come out next, because both are cheap to add later. What should never be cut is the written data model, the testing by real users, and the handover, because those are the three that decide whether the money already spent survives the year.
What if the org already exists and is a mess?
Then this is not an implementation, and pricing it as one is how projects go wrong. An org with existing automation needs the archaeology first: what fires on save, in what order, and what depends on it. That is priced separately, and a narrower read only diagnostic against your own exports is 500 euro delivered within three working days.
€8,700 for 174 hours at the smallest scope. Sales, Service and Marketing designed together rather than as three builds is 335 hours rather than 439. Every number on this site is hours multiplied by fifty and published rather than quoted.
Serhii Skrypnyk · Senior Salesforce Administrator and developer · 7 Salesforce certifications · on the platform since 2018. Reviewed 30 August 2026.