How the purchase usually fails
A CRM is the system that is supposed to hold the customer. The purchase fails in a familiar way: the new system is added beside the spreadsheet, the shared inbox, and the chat thread where the week is already decided. People keep the path that already works. The contract names one customer record. The work still has several.
Nobody owns the record. Sales updates an opportunity when a forecast meeting is on the calendar. The person who inherits the customer keeps the renewal in a workbook named for the quarter. Support answers from a ticket that never touches the account. Marketing sends from a list that matches neither. Leadership opens the CRM, sees a report that does not match the week, and asks someone to reconcile it. That reconciliation is the real system.
A mid-market B2B team, as an example and not a client story, often reaches this after a short list of demos. The platform that was chosen had stage names the team already says out loud. Six months later those stages are still the demo stages, half the required fields say "n/a", and the renewal date the business uses lives in the same spreadsheet. The CRM stored what it was given. It was never given the job the spreadsheet was doing.
Finish the decision before the next demo. Which jobs need a customer record today, and where each fact lives. What the CRM must own, and what may stay elsewhere on purpose. Which workflows the platform has to carry on a Tuesday, including who administers it after the integrator leaves. A feature matrix does not answer those. A page your own team can argue with does.
The stall is the same one described in why most technology adoption fails: the purchase is treated as the project, and the workflow, the owner, and the follow-through are left for later. This guide is that sequence for a CRM, written so you can run it before the contract.
Inventory the jobs that need a record
Start with the work, not the field list in the admin console. Sit with someone from sales, someone who inherits the customer, someone who answers when something breaks, and the person who pulls the report leadership reads. List the jobs that need a customer record today. Five cover most B2B teams. Write them in the words those people already use.
Pipeline. What is open, who owns it, the stage, the amount, and a date someone will stand behind. If that sentence is assembled from a CRM export, a sheet, and a chat message, the pipeline is not a record yet. The meeting starts with an argument about whose numbers are right, which means the job has no single home.
Handoff. The moment a deal becomes a customer someone else can serve. The next team needs the company, the buyer, the person who uses the product, the contract start, and what was promised. If those facts arrive in a chat message, sometimes, the handoff is not a record yet.
Renewals. A date, an owner, and the terms that decide whether the customer continues. A spreadsheet can be a view of that date for one meeting. It cannot be the only place the date is decided. When the person who keeps the sheet is out, the renewal moves or it does not, and nobody can say which.
Support. The history a person needs before they answer. Tickets may stay in a support tool. The account should not be created again there under a second spelling of the name. If support cannot see who the customer is and what was sold, the next call starts from nothing. Write whether that tool may create accounts, or only read the account the CRM already has.
Marketing list. Who may be contacted, and whether they are already a customer or an open deal. A list that cannot tell those apart will send a first-touch note to a customer, or skip the account a rep is working. The sends can live in a marketing tool. The match to the customer record needs a named owner.
For each job, write where the fact lives now, and the name of the person allowed to say it is right. "Sales ops", "the team", and a shared queue are not names. If you cannot name the person, the job has no owner, and a new CRM will not invent one.
A regional operator, as an example and not a client story, often finds the pipeline in the CRM, the renewal date in a workbook a finance lead keeps, the promised scope in the last proposal, and the support history in a tool that creates a new company whenever the domain is typed a second way. That page is the assessment. If you cannot point at where each fact lives, you are not ready to compare platforms.
Write what the CRM must own
The CRM does not have to hold every fact a customer touches. It has to hold the facts those jobs cannot run without, and it has to be the place those facts are decided. Write two short lists on the same page as the inventory.
What it must own. The account, and the people on it, with a way to reach them. The open opportunity: an owner, a stage, an amount, and a date someone will stand behind. The handoff from sold to being served. The renewal date and the owner of that date. The notes and call outcomes that change what the next person does. If two systems both claim these, they will disagree by Friday, and the spreadsheet will win because a person edited it last.
What may stay elsewhere. Billing may own the invoice, the payment status, and the contract value finance reports. The product may own usage. The support tool may own the ticket and the resolution. A marketing platform may own the campaign and the send. A spreadsheet may stay a view for one meeting, then be discarded. Write each exception in one sentence: what the other system is allowed to be right about, and which field on the CRM, if any, it may update.
A fact re-keyed by hand every week has no system of record yet. An integration writes it on a schedule a named person watches, or one person enters it and the other tool reads it. A sync that writes both ways, with no winner, puts a merged duplicate back into the forecast overnight. "We will integrate them" is not a direction.
Name one owner per object the CRM keeps. That person defines a duplicate, approves a merge, and can refuse a new field. One person may own several objects. One object cannot have two owners. A field added for a single report, with no job behind it, is how the form fills with dashes.
A platform asked to replace billing, support, and the product database on the same day usually replaces none of them. It adds a login, and Monday's work stays in the old tools. Draw the boundary before a demo that offers to be the system for all of it.
Evaluate against the workflow you wrote
Take the inventory and the boundary into every vendor conversation. If the answer comes back as a module name, ask to see the Tuesday job on the screen, in your words.
Stages someone can say in one sentence. Write them before the demo. For each stage: what is true of the deal, who may move it, and what the next person may assume. "Discovery" is a real stage when it means a problem the buyer has confirmed, not a meeting that was booked. Five to seven stages is enough for most pipelines. A stage nobody can define will be skipped.
Required fields the handoff needs: company, buyer, the person who uses the product, contract start, what was promised, and an owner. Ask to see the screen a rep uses to create a record. It should search for an existing account first, and it should refuse a save that is missing a field you kept. If "n/a", a dash, or "Unknown" still moves the stage, the new system will collect the same blanks as the old one. Use a picklist where the team already has the words, for stage, lost reason, and how the account was introduced.
Who administers it after the integrator leaves. New fields, imports, people who have left, merges, and the view the forecast meeting opens. Name the person who will do that work on a Thursday six months from now. If the answer is the partner or the vendor, the system has no owner, and the first exception lands in a spreadsheet so the CRM can stay untouched for the report. If every change waits on the integrator, you have a system you cannot run once the project team is gone.
A few more questions belong on the same page, because they are where a second inbox starts. Can a missed call become a task a named person sees the same day? Can the renewal date be required, and can a view show accounts coming due without an export? Can an import update a matching account without creating a second one for the same domain?
Score each platform against that page. A capability the workflow does not use is not a point. A missing answer is a reason to pause that vendor. In the demo, ask them to run your stages, your required fields, a handoff task to a named role, and a renewal that does not need an export. If the handoff fields do not stick, or nobody can see who receives the task when a stage changes, the platform does not carry the job.
Clean the record before you cut over
Choosing a CRM is not permission to move data you already do not trust. A migration copies what is there. Duplicates, blank owners, and fields nobody fills arrive with the records, and the new system starts out wrong. Rebuilding the CRM you already have does the same thing when configuration sits on a record nobody believes.
Clean before the cutover, not during the weekend of the import. Decide which objects a normal week uses. Name one owner for each. Merge the duplicates you are sure about. Archive what should leave the working views, and keep the history findable. Then fix the forms, imports, and integrations that made the mess. If the forecast is still decided on a spreadsheet when that work ends, the cleanup is not finished, and a new login will not finish it.
How to clean CRM data before a migration or rebuild is that pass: which records matter, who owns each object, how duplicates merge, what gets archived, and how bad data stops at intake. Run it on the system you have. The one-page list of fields you kept is the only list you migrate. Anything left off it does not get mapped or made required. What you archive, you leave behind.
The handoff is a separate afternoon, and it comes before any debate about automation. Write the states from a verbal yes to first value delivered. For each state, write who moves it, what they need in hand, and what the next person may assume. A fact the next team needs, and sales does not capture, is a required field. It is not an item for after go-live.
Map a CRM handoff in an afternoon is that session: name the record, write the states, pick the system of record, and test the map on the last three wins. The pattern in those three deals is the configuration backlog. Only then open the CRM you chose, or the one you are keeping, and add the fields, the required stage, and the task to a named role.
Plan the overlap. Keep the old spreadsheet for a defined window, with a date it stops being the backup people secretly prefer. In that window, one system is allowed to be right about the objects the CRM must own. If both are edited, the next forecast meeting argues about which record to believe. Name who checks, at the end of week one and week two, that a stage or a renewal no longer moves on the sheet.
Train the people who hand the customer off, and the people who receive the customer, before you train anyone on dashboards. Those two groups are the path the customer hits. A required field they have both used on a real deal will retire the sheet.
Put calls on the same record
A CRM that holds the account and ignores the call is still half a system. The phone logs the conversation. Someone pastes a note into the spreadsheet, forwards a voicemail to a shared inbox, or types a summary in chat. That second place becomes the record, because a person can find it later. The next conversation starts over, and the customer repeats what the company already heard.
Write the paths that must leave a record before you pick a connector. Inbound, answered: who called, why, and what happens next. Missed calls and voicemail: a named person who calls back, and a task they see the same day. Outbound, including the mobile app the team uses: the activity lands on the account, or the next person does not know the call happened. After hours: the rule, and where the result sits in the morning. A path with no named owner has nowhere to send the work, and the connector will behave like the shared inbox you already have.
Connect your phone system to your CRM walks those paths, the fields to name first, and a test on three real calls before anyone treats the link as finished. Point the connector at the match rules from the cleanup. A phone system that creates a new contact for every number grows a second set of people, with no company and no owner. The call should update the customer you already have.
If the phone platform is still an open decision, settle it on its own page: what one communications system must own, and what stays because a queue already works or a team should not move the same week. Keep the CRM cutover and the phone cutover on different dates.
A practical guide to choosing UCaaS is that sequence for numbers, queues, mailboxes, and whether a missed call can become a task a named person sees. Connect the system you are keeping.
Place a call, miss a call, and place an outbound call from the app the team uses. The account should show who, why, and what happens next, assigned to a person you named. If the result lands in a mailbox nobody owns, the spreadsheet stays the record of the conversation.
Bring the inventory, then decide
You are ready to choose when three pages exist. The jobs, with where each fact lives and who owns it. The boundary: what the CRM must own, what may stay in billing, the product, or support, and which way any sync writes. The workflow: stages in one sentence, the fields the handoff requires, and the person who administers the system after the integrator leaves. Another demo will not write those pages.
A strategy assessment is the right next step when the inventory is in hand and you want it tested against the week you actually run. Bring the awkward lines with it: the renewal in a workbook, the support tool that creates a second company, the call that ends in a chat thread. A shortlist of vendors, and no pages, turns the session into a tour.
EDGE uses this sequence inside revenue operations work. The jobs, the boundary, the workflow, the cleanup, the handoff, then configuration. Sometimes the CRM you already have can hold the design, and the project is an owner, a cleanup, and a handoff the next team can start from. Sometimes it cannot hold a required field, a renewal date someone will stand behind, or a call that has to become a task, and replacing the platform is the project. Buying nothing is one of the outcomes. It is a finished decision, available before anyone signs.
Book a strategy assessment and use the inventory as the agenda. If the jobs are still unnamed, write that page first and bring it. We will tell you whether a new CRM is the work in front of you, or whether the record you have needs an owner and a boundary before anyone signs.