Why do so many implementations fail?
The pattern repeats with uncomfortable consistency: the tool is chosen, it is configured with the stages it shipped with, the contacts are imported, the team is trained on where to click, and three months later the important information is moving through chat and spreadsheets again.
The cause is not the platform. It is that it was configured before anyone mapped the sales process, so the system asks the team for more work than it gives back. And when a rep has to choose between closing a deal and updating a record, they close the deal every time.
How do you map the real sales process?
By asking about facts, not about stages. The useful conversation is not “what are your sales phases?” but “walk me through the last five deals you closed, one by one, from first contact.”
The real stages come out of those accounts, and they almost never match the diagram in the corporate deck. A well-defined stage describes a verifiable fact — “proposal sent,” “diagnostic call booked” — and not a rep's mood, like “interested” or “in progress.”
The proof that the mapping worked: you ask two reps what a stage means and they say the same thing.
How do you choose the tool?
With three questions, in this order, and the feature comparison comes last.
- How does your team sell today? If you cannot describe it in stages with verifiable criteria, no tool is going to help you yet.
- Who is going to administer the system? If the answer is “nobody in particular,” rule out the most complex option without discussing it.
- What has to be connected? If the CRM has to talk to an ERP or to billing, that integration weighs more than any feature in the comparison.
Broadly: HubSpot when marketing and sales work together and you need adoption fast without a technical team; Zoho when budget rules; Salesforce when the processes are genuinely complex and somebody is administering the platform.
How do you budget without surprises?
By separating two line items that follow different logics. The license is public and predictable: you look it up on a pricing page. The implementation is not public because it depends on your operation.
Six variables move the number, in rough order of impact: integrations, quality of the source data, number of distinct sales processes, customization, history migration, and users to train.
As a reference for effort: one pipeline with no integrations and clean data is measured in weeks; several pipelines with one integration and a migration, in one to three months; multiple integrations with custom objects and several business units, in three months or more.
Which costs always get forgotten?
| Forgotten cost | When it shows up |
|---|---|
| Cleaning the data first | When you open the database, not when you quote |
| Your own team's time | Mapping and validation sessions: hours nobody is selling |
| Support afterwards | A living CRM changes: new processes, fields that stop earning their place |
| License growth | Every month, if the user structure was planned badly |
They are what produce the feeling that a project “went over budget” when it was never inside it.
What do you configure first?
The main pipeline and nothing else. The temptation to configure everything before launching is strong and is almost always a mistake: it stretches the project, delays the learning, and produces automations built on assumptions nobody has tested.
The order that works: main pipeline and minimum properties → team adoption over a few weeks → automations on what is already being used → integrations. Each phase surfaces problems the previous one hid, and finding them one at a time is far cheaper.
Which fields should be required?
As few as possible, and each one has to earn its place. When a field is required but gives nothing back to whoever fills it, the team learns to beat it: “n/a,” “1,” and “pending” appear — and from there the data stops being trustworthy for everyone.
A practical rule: if nobody is going to filter, segment, or report on that field in the next three months, it should not be required yet.
What has to be settled before migrating data?
Four things, and the first is the one most underestimated.
- Clean before, not after. If you migrate duplicates, you will have the problem in two systems.
- Decide which history comes over. Migrating everything costs more without adding anything; old history is rarely consulted. Set a cut-off by age and archive the rest outside the CRM.
- Normalize the picklist values. “Bogotá,” “bogota,” and “BOG” are three different values to any system.
- Inventory what consumes CRM data. Integrations, reports, and also the spreadsheets somebody maintains by hand. Those last ones are what break without warning.
How do you secure adoption?
By designing the system to give back more than it asks for. Three concrete levers:
Make the pipeline describe reality. A rep adopts a system that reflects how they work and dodges one that asks them to translate their reality into someone else's categories.
Make it automate something from day one. If the CRM saves them writing the same follow-up email twenty times, it earns the right to ask them to update a record.
Make the reports change visible decisions. When the team sees the weekly meeting decided on CRM data, keeping it current stops being bureaucracy and becomes influence.
How do you know whether the implementation worked?
Not by the number of active users, which is easy to inflate. Three honest signals: what share of open deals has an estimated close date, where the real follow-up on an important deal happens, and whether any concrete commercial decision came out of a CRM report in the last month.
If the important follow-up still lives in a chat group, the CRM is working as a dead archive, no matter how many users log in every day.
And if I already have a CRM that does not work?
Changing tools is almost never the first move. Most failed implementations fail on configuration and process, and migrating without fixing that reproduces the same problem on another platform, with the cost of the migration on top.
The path that works is going back to the mapping and reconfiguring on that basis. If you are going to migrate as well, use it: a migration is the only cheap window to redesign, because it is the one time everyone accepts that things are going to change.
That prior mapping is exactly the scope of a HubSpot Discovery, and it is the difference between reconfiguring once or three times.