When a growing business decides it needs a CRM, the conversation immediately turns to vendors. HubSpot or Salesforce? Pipedrive or Zoho? Which has the better interface? Which integrates with the email client?
These are the wrong first questions.
The right first question is: what is a customer record in your business? And the answer is rarely as obvious as it sounds.
The Question Behind the Question
Every software tool is built around a data model — an opinionated answer to the question "what are the fundamental objects in this domain, and how do they relate to each other?" A CRM has its own answer to what a contact is, what a company is, what a deal is. Your project management tool has its own answer to what a project is, what a task is, what a team member is.
When you buy a tool, you are not just buying its features. You are buying its data model. And that data model will either align with how your business actually operates — or it will fight you every time you try to use it.
Most tool evaluation focuses on features. Very little focuses on data model compatibility. This is why so many software implementations fail not at the technical level, but at the adoption level: the tool works exactly as designed, but the design does not map onto how the business thinks.
What a Data Model Is (Without the Jargon)
A data model is simply an answer to three questions:
- What are the core things we track? (Contacts, projects, invoices, products, support tickets)
- How do those things relate to each other? (A contact belongs to a company; a project has multiple tasks; an invoice is linked to a project and a company)
- What information do we need to store about each thing? (A contact has a name, email, phone, role, last contact date, assigned owner)
Getting this right before you choose tools means that when you evaluate a CRM, you are asking "does this CRM's model of a contact match my model of a contact?" instead of "does this CRM have a nice interface?" Interface can be tolerated. Data model mismatch cannot.
The Classic Data Model Failure Modes
The Account/Contact Confusion
Many B2B businesses sell to organisations but communicate with individuals. The CRM vendors know this — most CRMs have both "Company" and "Contact" as top-level objects. But the relationship between them is implemented differently across products, and neither implementation may match how you actually operate.
If your business sells to parent companies with multiple subsidiary entities, and your CRM models companies as flat with no hierarchy, you will be fighting the data model on every deal. If your business has contacts that work across multiple organisations simultaneously (common in professional services), and your CRM enforces a one-company-per-contact constraint, you will be building workarounds from day one.
The Project-Client Boundary
For service businesses, the relationship between clients and projects is core to how data flows. Does a project belong to a client? Can a client have multiple projects simultaneously? Can a project span multiple clients (consortium engagements)?
Your project management tool has made design decisions about this. If you have not thought through your own answer first, you will discover the misalignment six months into using the tool when you try to produce reporting that the data model does not support.
The Financial Object Problem
What is an invoice in your business? Is it always 1:1 with a project? Can it span multiple projects? Is it issued to a company or a contact? Do you have retainer arrangements that produce recurring invoices against a single engagement? Do you have milestone-based billing where one project produces multiple invoices over time?
Accounting software has answers to all of these questions baked into its data model. If your answers do not match, you end up with workarounds — manual processes that bridge the gap between how the software thinks and how your business operates.
How to Define Your Own Data Model
Before evaluating tools, spend time answering three questions for your business specifically.
Step 1: Identify your core entities
An entity is any kind of thing your business needs to track. Start with the obvious ones: customers, projects, transactions. Then work through the less obvious ones: partnerships, referral sources, product lines, team members, suppliers.
For each entity, write a one-sentence definition. This sounds trivial until you try it. "A customer is a company that has purchased at least one service from us" is not the same as "a customer is any company we have had a commercial conversation with." The distinction matters because it determines what gets into your CRM and what does not.
Step 2: Map the relationships
Draw a rough diagram (whiteboard, napkin, whatever) showing how your entities connect. Which entities have parent-child relationships? Which are linked by reference? Which can exist independently?
Pay particular attention to cardinality — can a contact belong to multiple companies? Can a project span multiple contacts? Can an invoice belong to multiple projects? These are the edge cases that data models handle differently, and they are the cases that will cause you pain if you do not address them before tool selection.
Step 3: Define your critical attributes
For each entity, list the ten most important pieces of information you need to know. Not everything — just the information that, if missing, would make the record functionally useless.
For a client entity, this might be: company name, primary contact, industry, relationship owner, first engagement date, current engagement status, ARR, last touchpoint date, referral source, and business size. Those ten fields are your minimum viable record.
When you evaluate a CRM, your first test is: can I store all ten of these fields cleanly, without hacks or workarounds? If the answer is no, the tool is disqualified before you look at the features.
The Integration Layer
Once you have defined your data model, the next question is how data flows between your tools. This is the integration layer — and it is where most multi-tool stacks break down.
The integration question is: for each entity, what is the authoritative source of truth, and what are the consumers?
Your CRM is likely the source of truth for client contact information. Your project management tool is likely the source of truth for project status and timeline. Your accounting software is the source of truth for financial data. None of these should be duplicating each other; they should be reading from each other.
Define the data flows explicitly:
- When a deal closes in the CRM → create a project record in the PM tool
- When a project is marked complete → trigger invoice creation in accounting
- When an invoice is paid → update ARR field on the company record in the CRM
These flows can be automated with tools like Zapier, Make, or custom integrations — but only if the data model on each end is compatible. If your CRM's "deal value" and your accounting tool's "invoice amount" represent different things, the automation will produce inconsistent data. The automation does not solve the model problem; it amplifies it.
Choosing Tools After Defining the Model
With a defined data model and mapped integration flows, tool evaluation becomes substantially more straightforward.
You are now evaluating tools against a clear brief: does this tool's model of [entity] match mine? Does it handle my edge cases? Does it expose the data I need in a format that can feed my integration layer?
This shifts you from feature-comparison to model-compatibility evaluation — and it is a much faster, more reliable process. You will eliminate most options in the first thirty minutes because they fail on model compatibility, and you will be left with a shortlist of tools that have a reasonable chance of working.
The tool selection is the last step, not the first. The data model is the brief.
If you are in the middle of a tool evaluation and want a structured framework for assessing data model compatibility, the System Audit Kit includes a data model mapping worksheet specifically for this purpose. If your stack is already in place and you are experiencing the integration failures that misaligned data models produce, book a consultation — we run data architecture reviews as a standalone engagement.
