A Salesforce implementation is the work of configuring the platform around how your teams sell and support customers, connecting it to your other systems and moving your data in safely. Licences are the small part of the project. Process design, data quality, integrations and user adoption decide whether the system is used or abandoned.
This article walks through the stages of a typical implementation, the decisions that matter most, and the costs that surprise first-time buyers. It is written for business owners and managers who are deciding whether to start a project, not for Salesforce administrators.
Stage one: map how your teams actually work
Good projects begin with conversations, not configuration. Someone should sit with sales, service and operations staff and write down how leads arrive, who owns them, what makes an opportunity qualified, how cases are handled and what managers need to see each week.
This map is the specification. Without it, a consultant configures a generic template, and people keep using their own spreadsheets because the system does not reflect their routine.
Stage two: design the data model and security
Next comes the structure: which objects and fields you need, who can see which records and how reports will be built. Decisions here are hard to undo later, because automation, reports and integrations all sit on top of them.
The aim is the smallest model that supports your reporting. Every extra field is something staff must fill in and someone must maintain, so restraint pays off.
Stage three: configure first, customise second
Salesforce can do a great deal through standard configuration and Flow automation. Custom code in Apex or Lightning Web Components should be reserved for requirements that configuration cannot meet, because code adds maintenance and risk.
A sensible team builds in a sandbox, keeps changes in version control and tests with real users before anything reaches production. That discipline is what keeps an org tidy as it grows.
Stage four: connect your other systems
A CRM is far more useful when enquiries from your website and WhatsApp land in it automatically, and when orders and invoices from your ERP or billing system appear on the customer record. These connections are built through Salesforce's APIs or middleware, and they need logging, retries and alerts so that failures are visible.
Agree which system owns each piece of data before building. Most integration problems come from two systems each believing they hold the correct version.
Stage five: migrate and clean your data
If you are moving from another CRM or from spreadsheets, plan time for cleansing. Duplicates, inconsistent formats and missing fields should be fixed before import, not after. Good migrations use test loads into a sandbox, reconcile record counts and totals, and let business users review samples before the final load.
Stage six: train people and measure adoption
A system nobody uses has failed, however well it was built. Short, role-based training, simple layouts and removal of fields nobody needs all help. Track a few measures after launch, such as record completeness and login activity, and fix problems early.
What it costs, and what surprises people
Salesforce charges licences separately from implementation work. Implementation cost depends on how many teams you roll out to, how much customisation and integration you need and how messy your data is. A focused first release for one team costs far less than a multi-team programme, which is why a phased plan is sensible.
Common surprises are data cleansing effort, the time business staff need to spend in workshops and testing, and ongoing administration after go-live. Budget for a support arrangement, whether that is a trained internal administrator or a retainer with your implementation partner.