Case study · Sales Cloud for a group of companies
The second Salesforce rollout, built around how the group actually sells.
Seven weeks to a trained team, and access proved as the users, 46 checks of 46.
An industrial services group, a holding and its operating companies in several countries, had bought Salesforce once and stopped using it because the first implementation was never finished. I worked on the second one: a 174 hour Sales Cloud scope, started 14 August 2026, built so the system asks for each piece of the sales process at the moment it matters instead of in a document nobody reads.
This is for you if you already pay for Salesforce, your sales process lives in a standard or a spreadsheet, and the honest answer to "do we use the CRM" is "some of us, sometimes".
August to October 2026, remote, with a partner's project team and the client's administrators, in the client's production org. The group and its companies are not named and none of their figures are published. Reviewed 29 October 2026.
What changed
What changed for the group?
Before: a sales standard on paper, and a lead form that demanded a person's surname for what was really a tender. Built: tenders, companies, stages, values and access shaped to that standard, with the rules enforced on screen. Now: the team was trained seven weeks after kick-off, and directors who never log in get their company's new deals every Monday.
7 weeks
from kick-off on 14 August to the training of the group's own trainers on 1 October
46 of 46
access checks passed as two real users on every opportunity: everyone reads every deal across the group, edits only their own, and sees proposals only on their own deals
1 record
per customer company, whether someone types its name in one alphabet or another, because the key is the registration number, checked against each country's format
Every Monday
company directors without a Salesforce licence receive the week's new deals for their company by email
Before
What was going wrong before?
The group had already been through two systems. Its sales standard had been built into Salesforce once and into another CRM after that, and both times people went back to what they knew. The export from the other CRM showed why: the fields written for the standard sat almost empty, while people kept filling in the fields they had added later in their own words. The system had been built to the document, not to the work. A lead there was a tender with a name like a project code, not a person. Nobody could say which company of the group owned a deal, and access between companies existed only on paper.
What was built
Six changes, each one replacing a habit.
A lead is a tender, and it has its own create screen.
Request name, source, country, request type, customer and contact, with a new customer created from the same screen. The fields Salesforce requires on every lead are filled from the choices, and a new lead waits in a queue until someone takes it.
One customer, one record, in either alphabet.
A registration number on lead and customer, unique, with its length and format checked against the rules of the customer's country. A second matching rule warns on name, phone, website or address.
Eight tender stages that ask for things when they matter.
From New through Engagement, Proposal Preparation and Proposal Evaluation to three ways of closing. The first task or meeting moves a deal out of New by itself. The bid due date and the products are required before a proposal is prepared, a closed deal needs a reason from a list that depends on how it closed, and a won deal is locked.
The deal value is the sum of its services.
Choosing services on a deal creates the product lines; removing a service removes only the lines the system created, never one somebody added by hand. The total opportunity value is quantity times price across the lines.
Access for a group of companies.
Everyone reads every lead and deal across the group, edits only their own, and group management above them through the role hierarchy. Commercial proposals are uploaded as private records, visible to the deal's owner and to management.
Deadlines and a weekly digest, with recipients kept in a table.
A daily alert, in the bell and by email, 7 and 3 days before a bid is due and when a close date is more than five days past. A Monday digest per company lists leads, deals, tasks, meetings and every new deal of the week, to any address. Who receives what is a row an administrator edits, not a change to the automation.
The decisions that mattered
Which decisions are usually made the other way?
Treat the lead as a tender, not as a person.
The usual move is to keep the standard lead form and tell people to type something into Last Name and Company. The list then fills with invented surnames, and conversion offers the wrong company. Salesforce validates those two fields in the browser before any automation can fill them, so here the create form itself was replaced: the screen derives both fields from the customer and contact chosen, and a lead nobody has linked yet is titled by its request.
Match customers on a registration number, not on the name.
The standard matching rules compare names and a postal address. Tested in this org, Salesforce's fuzzy company name match never compared a name written in one alphabet with its spelling in another, so the same customer could be created twice without a warning. A registration number is the same in every alphabet, it is public, and its length per country is checkable, so it became the key, with the name rule kept as a second warning.
Store proposals as private records, not behind a hidden tab.
Hiding a Quotes tab from other companies looks like protection. It is not: a file attached to a deal inherits the deal's access, so anyone who can read the deal can still reach the file through search or the files list. Here a proposal is uploaded to the person who uploads it and linked to its own record, which is private, so only the owner and the management above them can open it.
Lessons
What would I do differently next time?
One stage list, agreed in writing, before the first stage is built.
The client's documents gave three different stage lists, and I began with one of them. The stages were rebuilt three times, 9 to 5 to 8, each time with the data moved and everything that named a stage repointed. Now a written decision on stages comes before the first line of configuration.
Look at the screen as the user, not only at the access query.
The access checks said a seller could read the products on their deal, and their screen showed an empty tab: the reduced profile had no page layouts assigned for nine objects. Queries prove permission, not what renders. Every access change now ends with one look through the user's own eyes.
Rename nothing that nobody asked to rename.
I relabelled Accounts as Customers because the client said "customer" in conversation. The next day they asked for Accounts back: the object holds partners too. Labels now come only from the client's own documents.
What buyers ask first
Three questions before you start
We tried Salesforce once and it did not stick. Why would a second attempt be different?
Because the second one is built from what people actually fill in, not from the standard alone, and the system gives something back for each field it asks for: a deal moves itself out of New, the value adds itself up, the deadline arrives as an alert. The group's own trainers were trained first, with an administrator guide and a step by step user guide.
We have no sandbox, and the org is already in production.
Neither did this group. Every change was retrieved fresh from the org, tried as a dry run, backed up, deployed by named file and read back. A regression of 26 scenarios, many of them run as named users, ran before each release as a test that is never saved, so nothing it creates stays in the org.
What happens when you are gone? We have no developer.
None of the logic I built is Apex: 17 flows and 25 active validation rules, all declarative, because the client has no in-house developer. Notification recipients, products and picklists are records and settings an administrator edits.
For your business
Which parts carry over to any company restarting Salesforce?
Four of the six: a create screen shaped to what your lead really is, a duplicate key that does not depend on spelling, stages that ask for fields at the moment they matter, and access checked as named people. The stage names and the services change from business to business; the order of work does not.
A quick test before anything else: open your twenty most recent opportunities and count how many have every field your own sales standard calls required. If it is under half, the standard lives in a document, not in the system, and a rebuild that starts from the document will end where the first one did. More on that in why a sales team will not use Salesforce.
Before you fund a second rollout, find out what the first one left behind. The one day check reads your org without changing anything and gives a costed verdict for €650. For scale, the Sales Cloud build on this site is priced on this same scope: 174 hours, €11,310 fixed.
What was not in this case.
The monthly revenue forecast in the same org was built by another developer and is not described here. Integration with accounting and Revenue Cloud are a separate later phase, outside these 174 hours. One known gap stays open: product lines are created when services change on an existing deal, not yet when a deal is created with services already chosen; the regression suite keeps it pinned so it cannot be forgotten.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 29 October 2026.
Read next
The question that usually comes after this one.
Sales Cloud Audit: Eight Checks, €650 Day
A Sales Cloud audit in eight checks your admin can run, or done for you: €650 for one day against your exports, €4,875 to fix all eight.
Sales Cloud Implementation Cost in 2026
Sales Cloud implementation from €11,310 for 174 hours: the seven decisions that move those hours, and why billed hours and elapsed weeks are different numbers.
Case: Residential developer, shared org
Another business's sales team could open the developer's deals and payments. A count found it; the access model was closed in dependency order.