Ask five organizations what they use their CRM for, and you may get five very different answers.
For one, it's primarily a shared directory of contacts and organizations, with a history of emails, meetings, and other interactions. For another, it manages a sales pipeline from initial outreach through a signed contract. A nonprofit may use its CRM to manage donors, grants, or program participants. Another organization may rely on the same platform to process recurring financial transactions, trigger workflows, generate reports, and exchange data with several other systems.
Even the term CRM can obscure how different these systems have become.
Before an organization can select or configure a CRM, it needs to decide what role the system should play—and then make the many decisions required to support that role.
Some are obvious. What information needs to be stored? Who needs access? What reports are required? What other systems need to be connected?
Others are easier to overlook. What constitutes a relationship the organization wants to track? Who owns that relationship? Which interactions should be visible to colleagues? When teams handle the same process differently, should the CRM accommodate those differences or should the organization agree on a common approach? What belongs in the CRM, and what belongs somewhere else?
A polished product demonstration can make all of this look deceptively simple. The screens are clean. The workflow makes sense. A few clicks produce a useful dashboard. But the demonstration is usually showing a system in which hundreds of organizational decisions have already been made.
Your organization still has to make its own.
CRM implementations concentrate an enormous number of organizational decisions into a single initiative — often including decisions the organization didn't realize were waiting to be made.
Start by deciding what you mean by CRM
CRM originally meant customer relationship management, and the basic idea is still useful: a shared system for managing information about the people and organizations with whom you have relationships.
In practice, that definition leaves a tremendous amount of room for interpretation.
For a small organization moving away from spreadsheets, a CRM might provide a central place to track contacts, organizations, conversations, and follow-up activities. Instead of relationship history living in individual inboxes, personal notes, or someone's memory, the organization begins to build a shared institutional record.
Other organizations expect much more. The CRM may manage sales opportunities, fundraising, grants, marketing campaigns, events, contracts, support requests, program participation, financial transactions, or complex approval processes. It may exchange information with accounting systems, marketing platforms, websites, data warehouses, and specialized applications.
Modern CRM platforms reflect this range. Some provide relatively opinionated workflows that organizations can adopt with modest configuration. Others are highly extensible platforms that can be customized and built upon until the original CRM functionality is only one part of a much larger environment.
The important question is what your organization needs the CRM to do.
It's remarkably easy to skip past that question. A vendor may demonstrate a workflow that looks almost exactly like what you need. People may start discussing features, fields, integrations, licenses, or migration before the organization has established the boundaries of the system itself.
Should the CRM track a relationship with a donor but leave donation processing to a purpose-built fundraising platform? Should it store information about a grant while another system manages the detailed grant workflow? Should every email with an external contact become part of the shared organizational record? Should a specialized business process be built into the CRM simply because the platform makes it possible?
Different organizations will reach different conclusions. The decisions need to be intentional.
Before selecting or configuring a CRM, an organization should be able to articulate the job it's asking the system to do. Without clear boundaries, the CRM can gradually become the answer to every adjacent problem—and each additional responsibility adds complexity the organization will eventually have to manage.
A CRM forces an organization to define how its work actually happens
Once the boundaries are reasonably clear, the CRM has to represent how the organization thinks its work gets done.
Implementation has a way of revealing that there isn't always one shared version.
A process that sounds straightforward at a high level can look very different when someone tries to configure it. What makes someone a prospect? When does a prospect become an opportunity? Who owns the relationship with an organization when several people work with different contacts there? Which activities need to be recorded? Which fields are required? What happens when the normal process doesn't apply?
The same questions arise outside traditional sales environments. Organizations have to decide what constitutes an active donor, a grant, a partner, an investor relationship, a program participant, or whatever else the CRM is intended to represent.
Some of these questions may never have needed explicit answers before.
People developed their own ways of working. Experienced employees knew the exceptions. Different teams used the same words to mean slightly different things. Someone remembered why a particular account was handled differently. A spreadsheet included a column that made perfect sense to the person who created it five years ago.
People are remarkably good at working around ambiguity. Software is less accommodating.
Someone eventually has to decide what a field means, when a workflow starts, who can see a record, which values belong in a dropdown list, what happens next, and how an exception should be handled. Decisions that once lived in people's heads or were negotiated informally have to be translated into the structure of a system.
CRM implementation makes organizational ambiguity visible.
And that can be valuable. Implementation creates an opportunity to ask why a process works the way it does, whether different approaches really need to remain different, and where greater consistency would help.
Some variation will be legitimate. Some exceptions really do matter. Others may be the accumulated result of individual preferences, workarounds, legacy systems, or decisions nobody has revisited in years.
The CRM can't resolve those questions. The organization has to make them deliberately, collectively, and with an understanding of their downstream consequences.
The more the CRM does, the harder it becomes to change
Over time, a CRM can take on far more responsibility than anyone originally intended. In addition to contacts and relationship history, it may support intake forms, automated workflows, reporting, financial or transaction data, integrations with other platforms, and specialized business processes.
Much of that functionality may be useful and entirely appropriate. The challenge becomes visible when the organization wants to replace the CRM.
At that point, replacing the system means understanding everything that has become dependent on it. Which capabilities are still necessary? Which can be retired? Which should move to more specialized platforms? Which genuinely belong in the replacement CRM? What integrations and dependencies will need to be rebuilt?
An organization may think it's replacing one system when it's actually untangling an ecosystem of business capabilities that have become connected to it.
Broader uses of a CRM can make perfect sense. Consolidating related capabilities can reduce friction, improve reporting, and create a more coherent experience for users. But every additional dependency affects the organization's ability to change direction later.
For smaller organizations in particular, CRM selection can expose broader technology strategy questions. Decisions about where information lives, which systems should handle which processes, how platforms should integrate, and what complexity the organization is prepared to maintain extend well beyond the CRM itself.
Buying a CRM doesn't eliminate build decisions
Choosing a commercial CRM still leaves plenty of decisions about what the organization will build and maintain.
Some CRM products provide established structures for managing contacts, pipelines, activities, and other common processes. Organizations can configure those structures to meet their needs without fundamentally redesigning how the platform works.
For many organizations, those constraints are useful. If a process isn't particularly unusual, adopting a well-designed standard workflow may be simpler and more sustainable than recreating every detail of the current approach.
Other platforms are designed for extensive customization. Organizations can create new data structures, workflows, interfaces, automations, integrations, and applications to accommodate highly specific requirements.
The flexibility can be enormously valuable. It can also make almost every request technically possible.
But what's possible is a very low bar for deciding what to build.
Every customization becomes part of the environment the organization has to own. It may require documentation, testing, security review, user support, and maintenance as the underlying platform changes. Years later, someone may need to reconstruct why it was built before deciding whether it should survive the next upgrade or migration.
We explored these questions more broadly in Buy Versus Build in the Age of AI. Commercial CRM platforms make the boundary especially interesting because organizations can buy the underlying product while building substantial amounts of their own technology on top of it.
CRM projects therefore require an ongoing judgment call: how much should the organization adapt its processes to the platform, and how much should it adapt the platform to its processes?
A specialized process may justify substantial customization. A common business process may be better served by changing how the organization works.
Either way, the organization should understand what it's choosing to own.
Be intentional about what data comes with you
Replacing an existing CRM introduces another deceptively simple question: What should happen to all the data?
The default assumption is often that everything needs to migrate. Years of accumulated information can feel inherently valuable simply because the organization has it.
Some of it will be essential: active contacts and organizations, relationship history, open opportunities, current grants, transaction records, or information needed for ongoing work, reporting, or compliance.
Other data may include duplicates, obsolete fields, outdated contacts, incomplete records, abandoned categories, or information collected for purposes that no longer exist. Some may still have historical value without needing to live in the new CRM.
Older records, for example, might be retained in a secure, read-only archive. The information remains available when someone genuinely needs it without recreating years of accumulated complexity in the new environment.
Migration also provides a valuable opportunity to improve data quality. Duplicate contacts can be resolved, terminology standardized, obsolete fields retired, and records cleaned up before they become the foundation of a new system.
Garbage in, garbage out still applies. Historical information can also remain valuable without belonging in the new CRM.
Decide what needs to support active work, what needs to be retained for historical or regulatory reasons, what needs cleanup, and what can be left behind. Then design the migration around those decisions.
A new CRM provides a rare opportunity to reconsider years of accumulated information practices. Don't automatically carry every historical decision into the new system.
Some of the hardest decisions are about behavior
A well-designed CRM only provides a useful shared organizational record if people use it consistently.
Consider email.
Many organizations want the CRM to provide a history of interactions with important contacts. Someone preparing for a meeting can see that a colleague spoke with the same person last week. A new employee can understand the history of a relationship without reconstructing it from other people's inboxes. Colleagues can coordinate outreach rather than operating independently.
But "track email in the CRM" leaves a lot of decisions unresolved.
Which emails should be captured? Should every message exchanged with a CRM contact be visible to everyone who can access the record? Should users decide which correspondence gets recorded, or should the process be automated? What happens when a message contains sensitive or confidential information? Are there relationships that require greater restrictions?
If people are expected to make those decisions manually, will they do it consistently?
Similar questions appear throughout a CRM. Someone needs to add the meeting notes, update the contact information, change the opportunity stage, record the next step, close out an activity, or classify a relationship correctly.
Each action may take only a few seconds. Collectively, they can require a meaningful change in how people work.
Training can teach people how to use the system. Adoption depends on agreement about what the organization expects people to record, update, and share; which practices are required; and where individual judgment is appropriate. Managers have to reinforce those expectations, and the processes need to be realistic enough to survive a busy week.
The CRM also needs to provide value back to the people being asked to maintain it. If employees primarily experience the system as a place to enter data for someone else's reporting, keeping it current will always be a struggle.
People have much more reason to contribute when the CRM helps them understand relationships, find useful history, coordinate work, remember commitments, and avoid duplicating someone else's efforts.
The quality of a CRM ultimately depends on the organizational practices that keep the information inside it useful and trustworthy.
Go-live is a milestone
CRM projects naturally build toward launch.
There are configurations to complete, data to migrate, integrations to test, users to train, and a date when everyone begins working in the new system. A tremendous amount of energy goes into getting there.
Then people start using the CRM for real work.
A workflow that made perfect sense during design turns out to have too many steps. A required field is difficult for users to answer reliably. Reports expose inconsistent interpretations of a category everyone thought they understood. An exception that seemed rare during requirements gathering happens every week.
People are also developing new habits, often while unlearning informal processes they've followed for years.
Expecting a period of refinement after launch gives the organization room to learn from actual use. Feedback can be evaluated, data quality monitored, training reinforced, and configuration adjusted. New requests will emerge, too, and some will be worth pursuing while others may simply recreate old habits in the new system.
The organization itself will keep changing. People join and leave. Programs evolve. Sales or fundraising strategies shift. Reporting requirements change. New platforms are introduced.
The CRM has to evolve along with it.
Treating go-live as a milestone rather than a finish line creates space for the learning and iteration required to make the system sustainable.
Someone needs to own the decisions after launch
Once a CRM is live, it needs ongoing stewardship. Fields and workflows will need to change. New integrations or access requirements will emerge. Data quality issues will surface, and people will discover that seemingly straightforward terms or categories aren't being used consistently across the organization.
All of this is typical. A CRM has to change as the organization changes. Without clear ownership, though, small modifications can gradually make the system harder to understand, maintain, and trust.
CRM governance creates a structure for managing that evolution intentionally.
The structure should be proportional to the organization and the system. A six-person organization doesn't need an elaborate CRM steering committee, but staff still needs to know who owns the system, who can approve changes, who's responsible for data quality, and who resolves competing requests.
Larger or more complex environments may need more formal decision-making, particularly when the CRM supports multiple business functions, contains sensitive information, or connects to other critical systems.
Change also needs some discipline. Flexible platforms make it easy to respond to every request with a new field, automation, customization, or integration. Small changes accumulate quickly.
Before adding something, it's worth asking what need the request is addressing, whether other users or processes will be affected, whether the CRM is the right place to solve it, and what the organization will have to maintain afterward.
CRM governance also overlaps significantly with broader information and data governance. Definitions, ownership, access, retention, lifecycle, and data quality all affect whether people can trust and appropriately use the information in the system.
Questions to ask before starting a CRM initiative
Many of these decisions are easier to make before product selection and implementation are well underway.
Executives should make sure the organization has considered some fundamental questions before implementation gets too far along:
- What do we mean by CRM? What capabilities are we actually trying to create or improve?
- What problems are we trying to solve? Can we describe the outcomes we want without referring to a particular product?
- What belongs in the CRM? Which relationships, processes, and information should it manage, and which belong elsewhere?
- How consistent are our processes today? Where do teams genuinely need different approaches, and where have different practices simply evolved over time?
- What will people need to do differently? What information will employees need to record, update, or share for the CRM to work as intended?
- What information should be shared? Which correspondence, notes, and relationship history should colleagues be able to see? Where do we need greater restrictions?
- If we're replacing a system, what should come with us? What data needs to migrate, what needs cleanup, and what can be archived or left behind?
- How much customization are we prepared to own? Where should we adapt our processes to the platform, and where is customization worth the long-term commitment?
- How will the CRM fit into our broader technology environment? What systems need to connect to it, where should authoritative information live, and what dependencies will we create?
- Who will own the CRM after launch? Who will make decisions about changes, data quality, permissions, new requirements, and competing priorities?
You won't have every answer at the beginning. Discovery, design, testing, and actual use will surface new questions.
Knowing which decisions need to be made—and making them intentionally—puts the initiative on much stronger footing.
CRM implementations are organizational initiatives
A good CRM can give an organization a shared understanding of important relationships, preserve institutional knowledge, improve coordination, support better reporting, and replace fragmented processes built around spreadsheets and individual inboxes.
Getting there requires choices about processes, information, technology, ownership, and behavior. Those choices will look very different for a six-person organization implementing its first CRM and an enterprise replacing a heavily customized platform.
In both cases, CRM implementation makes assumptions about how the organization works explicit. Making those decisions intentionally gives the organization a much better chance of creating a system that remains useful long after go-live.
Related reading
Information & Data Governance: An Executive Guide
A practical guide to information ownership, lifecycle, governance, risk, and the organizational foundations required to manage information well.
Buy Versus Build in the Age of AI
A closer look at what organizations take on when they build or heavily customize technology—and why the ability to build something is only one part of the decision.
Every Technology Decision Is an Organizational Decision
A broader look at how technology decisions affect people, processes, governance, knowledge, and the way an organization operates.
