Full architecture · Sales, Service and Marketing as one build
Marketing captures it. Sales closes it. Support keeps it.
It breaks where they meet.
Bought as three separate builds, those clouds come to 439 hours. Designed as one system, 335. The 104 hours in between are not a discount and not a bundle: they are the coordination that stops existing when the same person builds all three.
€16,750 at 335 hours, fifty euro an hour, the same rate as every other line on this site.
What it costs
Three builds bought separately, and the same three designed together.
The first three rows are the prices already published on their own pages, unchanged. They are linked, so nothing here has to be taken on trust: open them and add up the numbers.
Hours multiplied by fifty, in both directions
| Sales Cloud implementation, on its ownData model, objects and stages, sharing, reports, up to 25 seats, training. | 174 hours | €8,700 |
| Service Cloud implementation, on its ownCase model, queues, email to case, reports, up to 15 agents, training. | 145 hours | €7,250 |
| Pardot to Marketing Cloud Next migration, on its ownTarget architecture, connector, prospect export with history, templates, testing. | 120 hours | €6,000 |
| Bought separately, totalThree scopes, three discoveries, three handovers. | 439 hours | €21,950 |
| Designed and built as one architectureOne data model, one build, one handover, at the smallest scope. | 335 hours | €16,750 |
| The differenceNot a discount. The coordination that does not have to happen. | 104 hours | €5,200 |
Smallest scope in every row. Larger seat counts, more objects or an existing org with automation to unpick move the hours up, and the estimate says so before the work starts rather than after. What moves them, in order, is seven decisions that are not the seat count.
Where the 104 hours go
They are the seams, and each one has a name.
An agency calls this integration and prices it as a phase. It is not a phase, it is six decisions that belong to nobody when three teams each own one third of the system. Every one of these has been found in an org that was built correctly, one cloud at a time.
The score does not survive conversion
Scoring and grading live on the Lead. Conversion carries across only the fields somebody has mapped under Map Lead Fields, so the number that decided the lead was worth a call is absent from the Contact by the time it reaches a salesperson. Built as three scopes, that mapping belongs to whichever build happens last, which usually means nobody.
Campaign influence is assumed, not configured
The Campaign Member record follows a Lead into the Contact on its own. Opportunity attribution does not: Customizable Campaign Influence has to be switched on and a model chosen. Marketing assumes the Sales build did it. The Sales build was never told it was in scope.
One Account, three definitions
Marketing works in domains, Sales works in Accounts, Support works in entitlements against the same Account. Whoever builds first sets that model and the other two build around it rather than with it. Changing it afterwards is a data migration, not a configuration change.
The sharing model belongs to whoever asked first
Org wide defaults that suit a sales team are rarely the ones a support queue needs, and the reverse is also true. Set for one and revisited for the other, this is a recalculation across every record rather than a setting.
Duplicate rules written for one object
Marketing writes Leads. Support writes Contacts. Both of them are writing people. Matching rules built while looking at one object let the same person through on the other, and the duplicate is found later by a report that disagrees with itself.
The same org described three times
Three scopes mean three discoveries, three sets of documentation and three handovers, and most of what they describe is the same org. That work is real and somebody pays for it. It is the largest single item inside the hours that disappear here.
What this does not buy
One person is one person, and that cuts both ways.
Three builds run in sequence, not in parallel. A team of six can put Sales, Service and Marketing in front of users faster in wall clock time than I can, and if the date is fixed and close then a team is the correct answer. You get told that on the first call rather than in week nine.
There is no bench behind this, nobody on call outside working hours, and no service level agreement. Above a few hundred seats, or where the programme needs several workstreams at once, a partner with a bench is the right shape and I will say so.
It is also not a repair. If the three clouds are already in place and the complaint is that they disagree with each other, that is a fault with a cause, and buying an architecture to cover it is the expensive way round. Those start at €2,000 for a single named fault, and the six that account for almost all of them are set out with the check you can run yourself before paying anybody.
What is in it
One data model, written down before anything is built.
Discovery across all three at once, then a written data model covering objects, record types, sharing and the conversion path from prospect to Contact to Case. Then the build: Sales Cloud with stages and forecasting, Service Cloud with the case model and queues in the order that keeps the cost down, marketing automation connected to both with scoring that survives conversion and attribution that reaches the Opportunity.
Then sixty days of handover, once rather than three times, and the written description of the org that makes the ninety first day possible without me. Agent design is included where it applies, which is a decision taken on the data rather than sold in advance, because an agent stops compensating for what was already broken.
Asked often enough to answer here
Questions
Why is this less than buying the three builds separately?
Because a large part of each separate build is spent finding out about the other two. One discovery instead of three, one data model agreed once, one handover, and no time spent reconciling decisions that were taken in isolation. The three individual prices are published on their own pages, so the arithmetic on this page can be checked line by line rather than taken on trust.
Can I start with one cloud and add the others later?
Yes, and it is often the right call when the budget or the certainty is not there yet. It costs more in total, and the page says so rather than pretending otherwise. What matters is that the first build is made with the later ones written down, even if they are a year away, because the expensive decisions are the ones taken before anybody knew what came next.
What if I only need two of the three?
Then it is scoped as two, at the same rate, and the hours land between the individual prices and this one. Nothing here requires buying a cloud to reach a discount. If a third would not be used, you get told that instead of sold it.
Who actually does the work?
One person, named, for all three. The same person who takes the first call writes the data model, builds the automation and runs the handover. That is the whole reason the seams are cheaper here, and it is also the limit: three builds run in sequence rather than in parallel, so a fixed date that is close is an argument for a team and not for me.
Serhii Skrypnyk · Senior Salesforce Administrator and developer · 7 Salesforce certifications · on the platform since 2018. Reviewed 30 August 2026.