What should you do before starting a CRM project?

Almost every frustrated implementation story starts the same way: the company buys the tool first and decides everything else during the configuration. The CRM project exists to invert that order, settling on paper what costs a fortune to settle once the system is live.

The difference between the two routes shows up fast. With no preparation, every postponed decision interrupts the configuration; with the implementation checklist closed beforehand, the team executes in sequence, without going back a step.

This guide organises that preparatory work in project order: scope, processes, data, integrations, roles and the definition of done. At the end, you take the consolidated checklist with you.

What causes rework in a CRM implementation?

Rework comes from decisions that were not made before the configuration: a generic scope, processes never designed, dirty data, integration assumptions taken for granted and undefined roles. Each of those gaps forces the team to decide mid-execution, and a decision made with the system under construction usually gets redone.

Caption: a CRM project settles on paper what costs a fortune to settle once the system is already live

A CRM centralises customer and lead data and interactions in one place and serves as the base for the operation's marketing and sales strategies.

The problem is that the centralisation inherits everything that existed before: a confusing process becomes a confusing funnel, duplicate data becomes duplicate contacts and a poorly agreed integration becomes a wrong report. The tool does not correct the operation, it makes it visible.

Knowing what to do before implementing a CRM is therefore an exercise in anticipation: every question answered on paper is one reconfiguration fewer. Marketing campaigns, funnels and automations are only born correct when the definitions reach the configuration ready.

How do you build a CRM project?

To build a CRM project, organise the preparation into six fronts, in this order: scope and objectives in writing, processes designed as they work today, a data inventory and clean-up, confirmed integration assumptions, defined roles and sponsorship, and criteria agreed in advance. The order matters, because each front feeds the next.

Scope is the front that locks all the others. The document records what the CRM should solve first, which departments enter the first phase and how success will be measured, and it is there that the platform's cost enters the planning before the contract is signed.

In projects run by mkt4edu, when the contract arrives generic, the first delivery is a scope document that fixes what will be built. Without it, every meeting reopens the agreement, and the configuration becomes a moving target.

Choosing the plan belongs to that same front. Comparing features with clear criteria for choosing the right CRM plan avoids paying for modules the first phase never uses.

Video: video from the mkt4edu channel on the platform decision that opens a CRM project

The six fronts follow the same logic: each one answers a question and produces verifiable evidence that it is done. Here is how that organises itself:

Table: CRM project checklist: what each front answers and the evidence that marks it as done

The evidence is what separates a front completed from a front discussed, and it is that chain of evidence that supports the right order of the configuration phases: each technical step depends on an earlier delivery existing in writing.

Do you need to design processes before the CRM?

Yes, you need to design the processes before the CRM, and design the real flow rather than the ideal one. The configuration translates processes into pipelines, stages and automations: when the design does not exist, the consultant configures by assumption, and each wrong assumption ends in a funnel rebuilt after go-live.

In projects run by mkt4edu, the legacy flow is drawn in BPMN (Business Process Model and Notation, the standard process design notation) before any configuration. The diagram exposes exceptions, loops and approvals nobody mentions in a meeting but which block the funnel when ignored.

The scale of the mapping matters too. In an operation with more than 80 request types, the full compilation came before the pipeline design: mapping the whole inventory first avoided building structures for half a dozen cases and discovering the rest with the system live.

That design also defines where marketing ends and sales begins. Inbound sales depends on a clear handover between the teams, and it is in the process diagram that the handover point becomes explicit, with a criterion and an owner.

How do you clean the data before migrating to the CRM?

To clean the data before migrating, inventory the sources, remove duplicates, standardise formats, discard whatever has no use or legal basis and name an owner for each data set. Data that enters the new system dirty contaminates segmentations, automations and reports from day one.

The inventory comes first because nobody cleans what they cannot see. List the spreadsheets, legacy systems, forms and inboxes holding contacts, and record the state of each source: volume, fields filled in and last update.

The clean-up is also a legal filter. Brazil's LGPD data protection law governs the processing of personal data, which includes the database going into the CRM: a contact with no legal basis for use must be regularised or discarded before the migration.

That filter only holds with permanent rules. Data governance in the CRM defines who can create fields, which formats are valid and how duplicates are handled, so today's clean database does not get dirty again in six months.

The migration itself has known mechanics: importing into the CRM uses column mapping and unique identifiers to create or update records. A field with no standard breaks the mapping, and a missing identifier produces duplicates at scale.

In mkt4edu's practice, a sample of the data is migrated and validated before the full load. The small-scale test reveals mapping errors, truncated fields and rejected formats while correcting them still costs little.

The reward for that discipline shows up in the operation: inbound marketing depends on segmentation and nurturing, and both depend on reliable fields. A dirty list sends the right email to the wrong person, and no automation fixes that afterwards.

The same applies to the digital marketing strategies feeding the CRM with new leads: a form with standardised fields delivers data ready to use.

Which integration assumptions should you confirm before configuring the CRM?

Before configuring the CRM, confirm in writing what each system sends, what it receives, how often the exchange happens and which system counts as the source of truth for each piece of data. An integration assumption taken for granted is the most expensive cause of rework, because the error only appears once everything is built.

In mkt4edu's experience, the integration assumptions are confirmed at the start, before any pipeline. One inverted assumption, such as believing a system would send the data it was actually waiting to receive, forces the whole funnel to be rebuilt, stages, automations and reports together.

That confirmation requires knowing the destination's structure. In HubSpot CRM, contacts, companies, deals and tickets are distinct objects, with their own properties and associations, and the integration has to say which object each piece of data enters and by which identifier.

Video: video from the mkt4edu channel on the structure a CRM project has to know before integrating

The same applies to measurement. Marketing campaigns only add up when the lead's source travels from the first form to the sale, and that journey crosses the integrations: one system in the middle dropping the source field is enough for the report to lose the trail.

In digital marketing strategies, that tracking starts in the campaign parameters and has to survive every change of system. Confirming the assumption on paper costs a meeting; discovering the failure in production costs the lost history.

At higher education institutions, the integrations with the academic and financial systems make this front even more sensitive, and the project phases for education institutions formalise each confirmation, with an owner and a deadline.

Who should take part in the CRM project?

The project needs a sponsor with the authority to decide, a project owner for day-to-day work, the owners of the marketing, sales and service processes, someone from technology for the integrations and the people who operate the funnel at the front line. Without those named roles, decisions stall and the schedule melts.

The sponsor is the most underestimated role. A CRM implementation changes a team's routine, and change breeds resistance: with nobody holding the authority to settle things quickly, every impasse becomes a lost week.

Whoever operates the funnel joins from the design stage, not only at the end. The person logging deals every day sees exceptions the manager does not, and CRM training pays off more when those people took part in the decisions that became screens.

Choosing the implementation partner belongs to this front too. HubSpot's official solutions partner directory organises companies into tiers such as Elite, Diamond, Platinum and Gold, giving a first filter of experience among HubSpot partners.

The tier is the start of the conversation, not the end. It pays to compare partners by the scope each one delivers: who designs the process before configuring, who tests the migration with a sample and who documents the assumptions in writing.

mkt4edu is an Elite HubSpot partner agency and runs CRM implementation projects with this checklist built into the method, from the scope document to the definition of done.

Which checklist should you follow before buying a CRM?

Before buying a CRM, follow the six-item checklist in project order: scope in writing, processes designed, data inventoried and cleaned, integration assumptions confirmed, roles named and criteria agreed in advance. An item without verifiable evidence counts as pending, not as done.

Consolidated, the checklist looks like this:

• Scope and objectives in writing: an approved document saying what the CRM solves, for whom and how the result will be measured.
• Processes designed: the real flow documented in BPMN and validated by whoever operates the funnel.
• Data inventoried and cleaned: sources mapped, database deduplicated and a migration sample validated.
• Integration assumptions confirmed: what each system sends and receives, signed off by the system owners.
• Roles and sponsorship defined: sponsor, project owner and process owners named.
• Definition of done agreed: the list of what has to be working for the implementation to end.

This checklist does not end at go-live. The definition of done marks the end of the implementation and the start of CRM management, the routine that keeps data, processes and automations healthy after the switch.

The same checklist makes sure the system is born ready for what comes next: inbound marketing finds a segmentable base, inbound sales finds a funnel with a defined handover and marketing campaigns find the lead's source preserved end to end.

Frequently asked questions about CRM projects

What do you lose by starting the CRM project with the tool?

Starting the CRM project with the tool, you lose time twice: in the configuration built on assumptions and in the rebuild when those assumptions fall. A rebuilt funnel, a repeated migration and a switched-off automation are the price of treating the implementation as software installation rather than an operational decision.

The preparation described here does not delay the project, it shortens it: with the six fronts closed beforehand, the configuration becomes predictable execution, with every step proved by evidence.

It is also the base that sustains marketing strategy after the switch: segmentation, nurturing and measurement only work on a system that was born organised.

If the implementation is already on the horizon, start with the scope document this week and advance item by item. The best practices for onboarding show how that preparation connects to the first weeks inside the platform.