- Step 1
Write down how you actually sell
Not how you wish you sold. Interview the two people who close most, and the one who complains most.
- Step 2
Build one pipeline with honest stages
Every stage needs an exit criterion a new hire can check without asking.
- Step 3
Design the smallest useful field set
Start from the report, never from the form.
- Step 4
Clean, then migrate
Cleaning happens in the export file, not after the import.
- Step 5
Automate the boring parts only
Automate what is stable. Leave the rest manual for a month.
- Step 6
Train, then watch adoption
Adoption is a metric. Measure it weekly for the first month.
Step 1. Write down how you actually sell
Every bad CRM starts with a good intention. Someone opens the tool and starts building stages. Two hours later there is a pipeline that matches nobody.
Start on paper instead. Ask three questions. Where do deals come from. What has to be true before a deal moves forward. Why do deals die.
Interview the two people who close most. Interview the person who complains most about admin. Those two views together give you the real process. Write it as short sentences. A page is enough.
Expect disagreement. That disagreement is the actual project. Software cannot resolve it, and configuring around it makes it permanent.
Time needed: half a day to two days, depending on how many people sell.
Step 2. Build one pipeline with honest stages
Most teams need one pipeline. Some need two, when the sales motions genuinely differ, for example new business and renewals. Very few need more.
Aim for five to seven stages. Name them after what the buyer has done, not what you hope. Qualified means the buyer confirmed a budget and a timeline. Proposal sent means the proposal is in their inbox, not in your drafts.
Give each stage an exit criterion. A new hire should be able to move a deal without asking. If two colleagues would place the same deal in different stages, the stage names are wrong.
Step 3. Design the smallest useful field set
Fields are where CRM projects get heavy. Someone asks for a field. It costs nothing to add. Six months later there are forty, and reps skip all of them.
Work backwards. List the reports you want. For each report, write the fields it needs. Any field that appears in no report is optional at best.
Make required only what blocks a decision. Deal source, expected close date, value, and possibly segment. Everything else can stay empty without breaking the forecast.
Use single option lists rather than free text wherever you plan to filter. Free text cannot be reported on, and reps will type four spellings of the same word.
Step 4. Clean, then migrate
Migration order matters. Organisations first, then people, then deals, then activities and notes. Import in that order and relations attach themselves.
Clean in the export file. Deduplicate on email for people and on domain for organisations. Normalise country names and currencies. Remove contacts with no activity in three years, or park them in a separate list you can import later.
Decide a cut off for deals. Open deals move. Deals won in the last two years move, because you need history for reporting. Older lost deals rarely earn their place.
Always run a test import into a sandbox or with a sample of fifty records. Check a handful by hand. Then run the full import in one go, not in pieces.
More detail per source is on the pages for HubSpot, Salesforce and spreadsheets.
Step 5. Automate the boring parts only
Automation is the most satisfying step and the most dangerous. Anything you automate on top of an unstable process becomes a rule nobody dares to change.
Safe things to automate in week one:
- Create a follow up activity when a deal enters a stage.
- Notify an owner when a deal has been idle too long.
- Set a default value or owner when a deal is created from a web form.
- Move a deal to lost after a defined period with no reply, with a reason.
Wait on anything that sends email to a customer, changes ownership silently, or writes to another system. Run those manually for a month, then automate what proved stable.
Step 6. Train, then watch adoption
Training is not a demo. Run it in two parts. A session for administrators on fields, automations and reporting. A session for users that covers only their daily path. Log a call. Move a deal. Send a proposal. Find yesterday's work.
After go live, treat adoption as a number. Deals with a next activity. Deals updated in the last seven days. Emails synced per user. Check it weekly for four weeks. Where a number is low, ask the person before you change the system. Usually the process is unclear, not the tool.
Plan a review at day thirty. Remove fields nobody filled. Rename the stage that keeps causing arguments. Add the two automations the team asked for. That review is worth more than any extra week of configuration before go live.
How long the whole thing takes
A team of five with clean data can complete all six steps in two to three weeks. A team of twenty coming from another CRM needs six to ten weeks. The variable is almost never the configuration. It is data and decisions.