The 10 Steps of a CRM Implementation That Actually Sticks

The hard CRM implementations are not the first ones. They are the second ones.

A first implementation starts with an empty account and a team who have never had one. A replatform starts with a decade of records, four integrations nobody documented, three pipelines that made sense in 2019, and a sales team with muscle memory. Add a department that has never touched the CRM and you are running two projects at once: a migration and an adoption.

The ten steps below are the order to work in. They are the same ten steps whether you are moving off a system your team has outgrown or extending the one you already run, but each step means something different the second time around, so that is how they are written here.

Two of them get skipped almost every time, and both cost real money later: who owns the code your partner writes for you, and what Australian privacy law says about moving customer records between systems. Those are steps two and three.

The ten steps

In order:

1. Write down what the new system has to do that the old one could not.
2. Choose the platform, and read who owns what you commission.
3. Clean the data, name the team, and check who is allowed to see it.
4. Define what a successful transfer looks like, in numbers.
5. Get the final yes from the people who will use it.
6. Budget for the dip as well as the subscription.
7. Leave room for what you will want in a year.
8. Roll out the basics: test transfer, core rollout, full implementation.
9. Assess against the criteria you wrote in step four.
10. Revise, go full, and keep the team together.

1. Write down what the new system has to do that the old one could not

On a first implementation this step is a brainstorm. On a replatform it is a list of complaints, and you already have it.

Write the specific ones. The report nobody can build. The field sales fill in by hand every week because the integration never wrote it. The handover between sales and service that happens in email because the old system had no way to hold it. Then get the numbers next to them: how long a deal sits in each stage now, how many records you actually have, how many of those are duplicates.

This is also the moment for mapping your sales process before onboarding starts. The process you run is the thing the new system has to hold, and the version in the leadership team's head is rarely the version the reps follow.

Keep the ambitious list, then split it in two: what has to work in the first week, and what you want by the middle of next year. Step eight needs that split.

2. Choose the platform, and read who owns what you commission

If you have spent two minutes in a room with us you know we froth HubSpot. It is not the only CRM going, so check the competition properly, and make sure you are not paying every month for features you are certain you will never open.

Then run a risk assessment, because you are moving live data out of a system your business currently depends on. The four risks worth writing down:

• Loss of data, some of which may be hard to recover.
• Loss of time, because a transition always creates a slow-down.
• Data corruption, the errors you do not find until months later.
• Loss of functionality, things that used to be easy and now are not.

The mitigation is a sample transfer. Any decent data partner will run a data quality audit on a test sample before anyone commits to the full run.

Now the part that gets skipped. A replatform almost always involves custom work: a custom coded workflow action, an integration between HubSpot and your ERP, a migration script, a calculated property nobody else has. In Australia the default position is that whoever wrote the code owns copyright in it, even though you paid for it, unless the contract assigns that copyright to you. IP Australia sets out the rule. So read the agreement before it is signed, and look for an assignment clause covering anything commissioned, or at minimum a licence broad enough that your next partner can maintain what this one built. The version of this that hurts arrives two years later, when you want to change partners and the integration holding your quoting together belongs to someone else.

If you are weighing doing it in house against bringing someone in, here is what implementation support actually looks like now.

3. Clean the data, name the team, and check who is allowed to see it

A migration is the one chance you get to leave the rubbish behind. Weed out the dead records, fix the fields you know are wrong, and decide what you want to be able to report on in future, which is usually more than the handful of fields you fill in today.

While you are in there: moving customer records means moving personal information between systems, often to a new storage location and usually through a third party's hands. That is exactly what the Privacy Act 1988 and the Australian Privacy Principles under it govern, and the OAIC publishes both. Two practical consequences. Keeping that information secure is your problem under APP 11, including while it sits as a CSV export in someone's downloads folder. And there are separate rules about disclosing personal information overseas, which is worth checking before a partner's offshore team is handed a copy of your contact database. Do the deletion before the migration. Records you never move cannot leak.

In parallel, name the team. Some of it will be in house, some of it your partner's. The skills you need:

• Project manager, to own the plan and the sequence.
• Data analyst lead, to own the migration itself.
• Systems engineer, to handle the technical work and the connections.
• Application developer, to build the parts the platform does not do as standard.

On a replatform there is a fifth person who never appears on the project plan and should: whoever knows why the old system is the way it is. Half the odd configurations in there are load bearing, and only that person knows which half.

Leadership is what makes a rollout work, especially leaders who can explain what the change is for. Beyond them you need the yes from management, sales and marketing, customer service and R&D.

4. Define what a successful transfer looks like, in numbers

This part is not hard, it is just usually skipped. Decide what done looks like and write it down before the transfer, because afterwards everyone argues from memory.

On a replatform the criteria are countable. Record counts match on both sides. Every open deal has an owner and a close date. The three reports your CEO opens return the same numbers as the old system for the same date range. Every integration that wrote to the old CRM writes to the new one. Get agreement on that list, because changing the definition after the build has started is slow and expensive.

5. Get the final yes from the people who will use it

Here the project team puts the proposal to the whole company, and you will get a volley of feedback back, some of it contradictory. Take it anyway. Somebody always raises the unforeseen problem that saves you a fortnight.

Middle managers matter most at this point. They may not have contributed to the design, but they know how their customer-facing teams will actually use the thing on a Tuesday afternoon. Spend real time selling the change internally.

On a replatform you will hear one objection over and over: the old one did X. Half the time they are right. Keep a public list of those, and answer each one, including the ones where the answer is that we are not rebuilding it.

6. Budget for the dip as well as the subscription

Set a realistic number before the transfer starts. Subscription charges and partner fees are the easy part. The rest of it: downtime, time out of the field for training, and the period where productivity drops while people learn where everything moved to.

Replatforming adds one more line most budgets miss. You will run both systems at once for a while, because nobody turns the old one off the day the new one goes live. Put the overlap in the plan.

HubSpot's dashboards and menus are plain enough that most teams get productive quickly, which shortens the dip. It does not remove it. If you want the other side of the ledger, this is what a bad implementation actually costs a growing business.

7. Leave room for what you will want in a year

Build for the department you are adding next as well as the one you are migrating now. The test is simple: if bringing service into a sales-only portal means rebuilding your property structure and renaming your pipelines, you built it too narrow.

Allow budget for the parts you will not use immediately. The custom object you will want when the second brand arrives is much cheaper to design now than to retrofit later.

8. Roll out the basics

An implementation runs in three stages:

1. Test data transfer.
2. Core systems rollout.
3. Full implementation.

Move a sample of customer data first, check it against your step four criteria, then roll out the core and get people using it fast so business continuity does not suffer. Your partner should be running training, in person or as material people can work through themselves.

Order matters more on a replatform than on a first build. The core is whatever your team uses every day: the pipeline, the records, the two reports leadership reads. Marketing email, campaign tracking, the newsletter and the social connections can follow a fortnight later on their own timetable, and nobody will notice.

9. Assess against the criteria you wrote in step four

This is where you find out whether reality matches the plan. If it does not, you have not gone to full implementation yet, so you can still change it before everyone is deep in.

Four things to judge:

• Integration, how well has the transition gone?
• Completeness, is all the data there?
• Accuracy, is it right?
• Fitness for purpose, can the team do their job in it?

You will get plenty of feedback from the people who have to live in it. Some of that is a genuine gap and some of it is that nobody likes learning a new system. Separating the two is the job. Give it a few weeks and most of the unfamiliarity complaints stop arriving.

10. Revise, go full, and keep the team together

Make the changes, take them back to the team, then go.

Two things after that. Plan a review at set intervals, monthly at first, and do not disband the implementation team the week after go-live. You will still need them as you finesse the setup and train the next intake.

Then name the person who owns the portal. A replatform with no owner drifts back into the state the old system was in, one unapproved field at a time, and in three years someone will write step one all over again.

The question worth asking before any of it

If you migrated tomorrow and every record came across cleanly, what would still be broken?

If you can answer that in one sentence, the answer is usually a process problem, and a new CRM will hold a broken process just as faithfully as the old one did. Fixing it first is cheaper than migrating it. That is most of what our RevOps and HubSpot work turns out to be.

So: what is on your list, and which of it is actually the software's fault?