CRM implementation, from decision to go-live

A CRM implementation is a sequence of nine decisions, not a software installation. Each step below names who runs it and what has to be true before the next one starts.

Short answer

CRM implementation is the work between buying a CRM and your team using it every day. It runs in nine steps: a needs assessment, a named owner, a mapped process, a data model, a clean data migration, configuration, email and calendar connections, a pilot on real deals, and a review after go-live. Each step ends with a gate.

What is a CRM implementation?

Implementation is everything between buying a CRM and the CRM being the place your team actually works. Installation is not part of it: a cloud CRM is running the moment you sign in. If you are still working out what CRM is, or what customer relationship management is supposed to cover, start there and come back. If you have not chosen a system yet, how to choose the best CRM is the step before this one.

The work divides into four kinds and only one of them is technical. You decide what the system has to answer. You get the data into a shape worth moving. You configure the software. And you change what the team does at four o’clock on a Thursday. The last of those decides whether the first three were worth doing.

Implementation is usually sold as a project: discovery, design, build, rollout, training, a statement of work. For a single sales team that framing is heavier than the job. What actually goes wrong is smaller and more boring: a step starts before the one before it finished. So every step below carries a gate: the sentence that has to be true before anyone moves on.

Who does the work, and what each person decides

Five roles have to exist on paper, though in a small company one person holds two or three of them. None of them can be held by nobody, and each carries a decision and a commitment of time.

  • Sponsor, usually the sales leader: decides scope, stage names, what counts as done, and what gets deferred. Has to be available for the kickoff, then a standing check-in until go-live.
  • System owner: makes every configuration choice, and holds the one account that can change fields. Has to be available for the whole of it: this is the role that carries the work.
  • Two or three reps: decide whether the daily flow is workable, and hold a veto during the pilot. Have to be available for daily use of the system throughout the pilot.
  • Whoever holds the data: decides which file is authoritative when two disagree, and what is abandoned. Has to be available for the data preparation, and the migration itself.
  • IT, or whoever runs the mailbox: decides the mail and calendar connection, access, and the security review. Has to be available for each connection, one at a time.

One way this falls apart is a sponsor with no owner: decisions get made, everyone agrees, and nothing is applied because no one’s name was on applying it. The reverse is an owner with no sponsor, who cannot refuse a field request and ends up with a form nobody fills in.

The nine steps at a glance

The table below is the whole plan on one screen: who runs each step, how heavy it is, and the gate that lets the next one start. There are no day counts in it, on purpose. How long an implementation runs is decided by how fast your sponsor answers questions and what state your data is in, and neither of those is something a vendor can estimate for you.

The weight column is worth reading on its own. The heaviest step is not configuration. It is preparing the data. If someone hands you an implementation plan with no data preparation in it, they have either seen your data or they have not asked about it.

StepWho runs itWeightDone when
1. Needs assessmentSponsor and ownerLightFour or five questions are written down with the shape of the answer each one needs
2. Name an ownerSponsorThe shortest step hereOne person’s name is on the configuration, in writing
3. Map the processOwner with two repsLight, but not to be rushedThe stages a deal passes through fit on one page, in the team’s words
4. Design the data modelOwner and sponsorMediumEvery field has a question behind it; the rest are cut
5. Prepare and migrate dataOwner and the data holderThe heaviest step in the planA sample import matches the source and duplicates have been merged
6. ConfigureOwnerMediumA rep can run a deal from first contact to a sent quote unaided
7. Connect email and neighborsOwner with ITMedium, one connection at a timeA sent email lands on the right record with nobody copying it
8. Pilot on real dealsThree or four peopleLight per person, spread across two weeksThe pilot group has stopped keeping a private spreadsheet
9. Go live and reviewEveryone, then the ownerLight at launch, lighter at the reviewThe old file is read-only and the review date is in the calendar
Nine steps: who runs each one, how heavy it is, and the gate to the next

The nine steps in detail

Each step ends with its gate, the cheapest quality control an implementation has, because all of it is easier to settle now than to unpick after go-live.

1. Write the needs assessment

Before anyone opens a configuration screen, write down what the system has to answer. Four or five questions is enough: which deals are stuck and where, what a rep should do next on each one, what is likely to close this quarter, and who has spoken to a given account recently. Next to each question, write the shape of the answer: a number, a list, a screen. Do not write feature names. A needs assessment that says “we need automations” produces a configuration nobody can test, because there is no wrong answer to it. When you do reach the capability list, the CRM features guide describes each one as the job it does, which is the language this step needs.

Gate:the questions are written, and the sponsor agrees they are the right questions.

2. Name one owner

One person applies the configuration. Not a committee, not the vendor, not “sales ops will look at it.” They do not have to be technical. They have to know how the team sells and have the access to change fields. Everyone else advises. Put the name in writing, tell the team, and give that person the authority to refuse a field request, because they will get several, and most of them are somebody’s curiosity rather than somebody’s report.

Gate:a named person, told to their face, holding the access to make changes.

3. Map the process you run today

Sit two reps down and have them describe a deal they won and a deal they lost, out loud, in order. Write the stages they name, not the stages you wish they used. Two things tend to surface here: a stage everyone skips, and a stage that is really two. Keep their vocabulary, including the ugly words. A pipeline labeled in management language gets filled in wrong, or not at all. This is also where the team agrees what has to be true to leave each stage: a working agreement between people, not something software enforces.

Gate:the stages fit on one page, in the team’s own words, and both reps recognize their own deals in them.

4. Design the data model

Now decide the objects and the fields: what a lead is, when it becomes an account and a deal, how many pipelines exist, and which key fields each stage should put in front of a rep. The discipline is one question per field. If you cannot name the report or the decision a field feeds, cut it. Required fields are the ones you will over-use; each is a small tax on every record, forever. This is also where your industry’s own words (lane, term, unit, territory) become fields, and adding them later means typing the data twice. Stage design is a longer subject than this step has room for: CRM strategy is where it is written out properly.

Gate:every field on the list has a named question behind it, and the list is shorter than the one you started with.

5. Clean the data before you move it

The step most often left until the last week. Export what you have. Decide which file wins when two disagree. Merge duplicates while the data is still in a spreadsheet, where merging is easy. Drop the contacts nobody has spoken to in years. Carrying them across pollutes every report you build later, and gives you personal data you have no reason to hold. Then import a small sample (a hundred records or so) and check them against the source by eye before importing the rest. CRM database covers where duplicates come from and how to keep them out.

Gate:a sample import matches the source, and a human has looked at the merged duplicates.

6. Configure the system

Build the pipelines, stages, fields and views from step four. Set up the quote template, and (where your plan includes approvals) the route a discounted quote follows before it is sent. Where your plan includes automations, add two or three and stop: a task created when a deal reaches a stage, a notification when the owner changes, an alert on a field you actually watch. The instinct is to configure everything you might one day want. Resist it. You cannot yet tell which of your guesses are wrong, and every wrong guess is something a rep has to work around in week one.

Gate:a rep can take a deal from first contact to a sent quote without asking anyone how.

7. Connect email, calendar and the systems next to it

Connect one mailbox first and watch it for a day. Connecting all of them at once makes it impossible to tell which change caused the problem. Then the calendar, then anything that has to exchange records with the CRM. Decide direction before you connect anything: which system is authoritative for a customer’s address, and which one merely displays it. Two systems that both believe they own a field will overwrite each other quietly for months. CRM integration covers the order and the matching keys.

Gate:an email sent from the mail client appears on the right record without anyone copying it there.

8. Pilot on real deals

Give three or four people the system and their own live deals for two weeks. Not sample data, not a training sandbox: the deals they will be asked about at the end of the month. Meet twice inside the two weeks and write down every place someone hesitated. Hesitation is the signal; complaints are secondary, because people complain about what is unfamiliar and hesitate at what is genuinely unclear. Expect to rename a stage, cut a required field and add a view. If nothing changed during the pilot, the pilot was not real.

Gate:the pilot group has stopped keeping a private spreadsheet, and the changes their feedback produced are applied.

9. Go live, then review on a fixed date

Going live is two acts. Everyone gets access and a short session on the flow rather than the features: where a deal enters, where it leaves, what they are expected to type. Then the old spreadsheet becomes read-only on a stated day. Leaving it editable is how a CRM ends up half-used. Set the review date before you launch, about a month out, and put it in the calendar. At the review, look at what is empty rather than what is full, and cut rather than add. CRM best practices covers the rhythm after that first review.

Gate:the old system is read-only, and the review is booked.

First CRM, or a replacement: the same nine steps, different weights

Two very different projects wear the same name. Coming off spreadsheets and an inbox is not the same job as moving off a CRM you already run, and the difference shows up in three of the nine steps.

On a first CRM, steps three and four are the expensive ones. Nobody has written the process down before, so the stages are being invented in the room rather than transcribed, and the field list has no precedent to argue with. The data is scattered (a sheet per rep, a shared mailbox, numbers on somebody’s phone), so step five is less a migration than an assembly. The consolation is that there is no legacy shape to fight: whatever you design is what people learn.

On a replacement, steps three and four are cheaper, because the old system already answers them. The trap there is copying it wholesale, including the fields nobody has filled in for two years. Step five gets harder instead: the export carries history, notes, attachments and identifiers, and each of those needs its own decision about whether it comes across. Step eight carries more weight too, because the team arrives with habits the new system will not reward.

  • Coming from spreadsheets: expect the argument to happen in step three, because the process has never been written down.
  • Coming from another CRM: expect it in step five, because the export contains years of decisions nobody remembers making.
  • Coming from the CRM module of an accounting or ERP system: settle the boundary first (which system is authoritative for the customer record and which one merely displays it) before a single field is mapped.
  • In every case, resist the urge to make the new system look like the old one. A pipeline copied field for field carries the last system’s compromises into this one.

What to leave for phase two

The release you go live with should be smaller than the one you sketched in step four. Everything below is legitimate work, and none of it belongs in the first month.

  • Reports beyond the two or three that answer the needs assessment. Build a report the second time someone asks the question out loud.
  • Custom objects for the parts of the business that do not fit leads, accounts and deals. They are far easier to design after a month of watching real records.
  • The second and third pipelines. How many pipelines a plan includes is on plans and pricing. One team, one pipeline, until the first one is genuinely being kept up to date.
  • Anything not released yet. In Senitix CRM, outgoing webhooks, web forms that create leads, messaging channels for WhatsApp, Instagram, Messenger and Telegram, saved email templates, macros, assignment rules, sharing rules and configurable duplicate detection are coming soon, so plan the first release as if they do not exist, because today they do not.
  • Closed deals from more than a couple of years back. Bring them across later, if a report actually needs them.

The rule behind all of these is the same: configuration you have not watched anyone use is a guess. Guesses are cheap in month two and expensive in week one.

Why do CRM implementations stall?

Five things stall an implementation halfway. None of them is a software problem.

  • No owner. Covered above, and worth repeating here.
  • Configuration before mapping. A pipeline built from a vendor default and never checked against a deal that actually happened.
  • Migration treated as an import. Data that was wrong in the spreadsheet is wrong faster in the CRM, and now it looks official.
  • Training on features instead of on the flow. Nobody wants a tour of the software. They want to know where their Tuesday goes.
  • No date for the review. Without one, the first design becomes permanent, and the first design is always a draft.

That is the pattern worth taking away: the technical part of a CRM implementation is the part least likely to go wrong.

The nine steps in Senitix CRM

Senitix CRM holds leads, accounts and contacts, deals, activities, a product catalog, reports and dashboards. It also offers multiple pipelines, custom fields, connected email and calendar, quotes with versions and a PDF, the Documents module, automations, Senitix AI, approvals, contracts, orders and invoices, forecasting and custom objects; plan details are on plans and pricing. Which of them you turn on in month one is the whole of step six, and the answer should be fewer than you want.

There is nothing to install and no mobile app to roll out: Senitix CRM runs in a web browser, so no installation project sits in front of step one. For step five, migration is a file import: every plan imports and exports CSV or Excel files, and there is no one-click connector from another CRM, so the cleanup happens in the spreadsheet, where it is easiest. For step seven, the connectors available today are Gmail, Google Calendar, Microsoft Outlook, Microsoft Calendar and any mailbox over IMAP/SMTP. A bridge to another system runs through a connected app that Senitix registers, not a self-serve API you build against directly, so it is worth raising with Senitix before you plan one.

Senitix AI sits alongside the record rather than in place of it. Within a daily request limit per user, it writes a daily digest, answers questions from records you are allowed to see, drafts email and suggests a next action, and nothing is sent or changed until someone confirms. None of it is a reason to skip step three. A suggestion can only be as good as the pipeline underneath it.

One thing to be plain about, because it applies to every product in the category: software does not enforce your gates. A stage in Senitix CRM carries guidance text and up to five key fields the team chooses, so the exit criterion agreed in step three is visible where the work happens, but it stays an agreement between people, not a rule the system imposes. The full capability list is in the Senitix CRM feature catalog, what each plan costs is on plans and pricing, and the product itself is Senitix CRM.

FAQ

CRM implementation: common questions

How long does a CRM implementation take?

There is no honest week count, because the software is not what runs the clock. It is run by how fast the sponsor answers questions, what state the data is in, and whether the pilot changes anything. The steps that stretch are the process map and the data preparation; configuration is rarely the delay. Plan the sequence and the gates rather than the calendar, and the calendar takes care of itself.

Who should own a CRM implementation?

One named person who knows how the team sells and has the access to change fields. Not a committee, not the vendor. They need a sponsor above them, usually the sales leader, to set scope and say no. Two or three reps test the daily flow and hold a veto during the pilot. In a small company one person can hold two of these roles, but none of them can be held by nobody.

Do I need a consultant to implement a CRM?

Only if the process is genuinely complex: several teams selling differently, an approval chain with real consequences, or an integration nobody in-house can own. For a single sales team, the nine steps above are ordinary internal work. A useful test: if you cannot describe your sales process on one page, a consultant will help you find it. If you can, they will mostly be typing.

What is the hardest part of a CRM implementation?

Data preparation, and it is not close. Deciding which file is authoritative, merging duplicates and choosing what not to move takes longer than every configuration screen put together. The second hardest is habit: getting people to stop keeping a private copy of the pipeline. Both are people problems wearing a technical hat, which is exactly why plans underestimate them.

Should we import all our old data into the CRM?

No. Import the records a report or a rep will actually use: open deals, active accounts, contacts someone has genuinely spoken to. History carried over unexamined is history nobody trusts, and it makes every duplicate check harder from then on. Keep the export file somewhere safe; you can always bring more across once you know which report needs it.

Can we move our data from another CRM into Senitix CRM?

Yes, as a file import. Every Senitix CRM plan, Free included, imports and exports records as CSV or Excel files, so a move from Salesforce, HubSpot or Pipedrive starts with an export from the old system and a field mapping. There is no one-click migration connector, which is why step five matters: clean and de-duplicate the export before it comes across.

What should we do in the first month after go-live?

Watch what stays empty. The stage nobody uses, the required field with the same value on every record, the report nobody opened: each of those is a design mistake with a cheap fix. Book the review before you launch, hold it about a month out, and use it to cut rather than to add. Adding is safe once the basics are being kept up to date.

Ready to grow with Senitix?

Connect with customers, win more deals and grow repeat business, all on one platform.

No credit card required.