Should you even be picking a CRM right now?
Most teams shopping for a CRM are really trying to fix a broken system. Here’s how to tell if you need a CRM, a suite, or something else.
A founder asked me recently which CRM he should buy. Series A, fifteen people, deals closing, pipeline in a spreadsheet that had stopped being readable.
I asked him four questions. Is your sales motion repeatable yet? Is it one pipeline, or several? Who owns the customer after the deal closes? If you picked the wrong CRM now, would you still be using it in three years?
His answers were: kind of, two, delivery, probably not.
Then I asked the question that mattered more than the others: what else do you want this system to do?
He listed seven things. Track proposals. Manage project delivery. Send invoices. Store client documents. Run reports for the board. Handle onboarding. Keep the customer history usable after the sale.
At that point, the problem was clearer. He was not really shopping for a CRM. He was trying to find a system that could hold more of the business.
The word “CRM” covers too much
When most founders say they need a CRM, they are not just talking about a contact database with a pipeline. They usually mean some combination of contacts and deals, task tracking, invoicing, marketing emails, onboarding, support, documents, reporting, and collaboration.
That is why the category gets messy so fast. HubSpot is not just a CRM. Monday is not just a CRM. Zoho is not just a CRM. ClickUp and Notion both end up acting like CRMs for teams that need them to. The real question is not “which CRM should I choose?” It is “how much of the business do I expect this thing to hold?”
That changes the answer.
What usually sends people CRM shopping
Founders do not wake up one morning and decide they need a CRM. Usually something has broken.
Maybe leads are falling through cracks. Maybe the spreadsheet stopped working at a certain size. Maybe a new sales hire cannot tell what the previous one was doing. Maybe the board wants a forecast. Maybe something after the sale is failing, like onboarding, renewals, or handoffs. Sometimes a competitor started using HubSpot and now everyone feels behind.
Only some of those problems are actually solved by buying a CRM. The rest are process problems, habit problems, or category mistakes wearing CRM language.
A CRM does not create discipline. If nobody logs calls now, nobody will suddenly start because the interface looks nicer. The tool usually amplifies what is already there.
When a CRM is actually the right answer
A CRM makes sense when five things are true.
First, your sales motion is repeatable. Not just “we do deals,” but a real pattern: leads come from somewhere identifiable, they move through known stages, and the team can describe how a deal progresses.
Second, you have one pipeline, or several pipelines that are similar enough to live in the same structure.
Third, more than one person is doing sales, or you are about to make that true.
Fourth, the core unit of work is actually the deal. If the real center of gravity is the project, site, patient, case, policy, or claim, then the standard CRM data model is already starting from the wrong place.
Fifth, you only need the tool to manage the sales layer. Marketing, delivery, finance, and support can stay elsewhere and sync in where needed.
If those conditions hold, buy a CRM. Pick something that suits the team, set it up properly, and move on.
When a CRM is the wrong answer
There are a few signs that the fit is wrong at a structural level.
One is multiple pipelines with genuinely different shapes. Another is cross-functional ownership, where sales, delivery, finance, and support all need the same customer record, but each team needs to see and use it differently. A third is post-sale complexity, where the harder part of the business starts after the deal closes.
That is the point where a lot of CRM tools start to feel awkward. They are designed to move deals forward. They are not always designed to carry the rest of the business well.
We covered that more directly in Build vs Rent. The short version is that once the tool has to serve several departments with different needs, you are no longer making a simple CRM decision.
There is another signal that matters just as much: you are not really trying to buy a CRM at all. You are trying to buy a spine for the business. Sales, delivery, invoicing, support, documents, reporting. If one system is expected to hold all of that, you are in a different category of decision.
Is Airtable a CRM?
This is the right question, because the honest answer is yes, when you build it to be one.
Airtable is not a CRM product in the same way HubSpot or Pipedrive is. It is a flexible database with a usable interface. You can build a CRM in it. You can also build project tracking, onboarding workflows, invoicing systems, content calendars, applicant tracking, client portals, and internal operations tools.
That is what makes it useful in this conversation. When a team says “we run our CRM in Airtable,” they often mean something broader: they run their operating system in Airtable, and the CRM is one view into the same data.
Airtable is a strong option when “CRM” really means “CRM plus several adjacent workflows that need to share records.” It is also a good fit when the business does not map neatly to contacts, companies, and deals, or when post-sale complexity matters more than pre-sale pipeline polish.
It is the wrong fit when your sales process is simple, linear, and well served by a purpose-built CRM. It is also the wrong fit when you need native marketing automation out of the box, or when nobody on the team is willing to own the configuration.
A useful rule of thumb is this: if you would otherwise be buying two or three SaaS tools and stitching them together, Airtable may replace all of them. If you would be buying one tool and using it as intended, buy the tool.
That same idea sits behind You Don’t Need More Tools. You Need Better Systems: the problem is often less about features and more about whether the underlying system matches how the business actually runs.
What to pick instead
There are really three paths here.
The first is to rent a CRM. That makes sense when your business is CRM-shaped and you only need a CRM to do CRM things. This is where tools like HubSpot, Attio, Pipedrive, Close, and Folk fit.
The second is to rent a suite. That makes sense when you need CRM, marketing, and support to live in one ecosystem. You are not just buying the tool. You are buying the integration story.
The third is to build a composable stack. That makes sense when the system needs to hold more than the sales process and your workflow is not standard. In those cases, the better answer is often a flexible data layer, a few specialist tools, and automation connecting them.
That path usually takes longer to stand up, but it often maps to the business more honestly.
The questions that actually matter
Once you stop asking “which CRM?” a better set of questions shows up.
Does the data model match the business, or are you forcing the business into the tool?
How much of the company are you asking this system to hold?
Who owns the customer record after the deal closes?
Can the team operate and change the system without depending on a vendor or one internal expert?
What is the migration story in three years?
What does the tool really cost once you include seats, add-ons, integrations, and the second or third product you will eventually need?
Those questions are not as marketable as feature comparisons, but they tend to produce better decisions.
The approach we use
The sequence is simple.
First, identify the broken layer: data, logic, interface, or habit.
Second, decide how much of the business this system is supposed to hold.
Third, check whether the business is actually CRM-shaped.
From there, the choice is usually clearer: rent a CRM, rent a suite, or build something composable.
AI comes later. Not first. AI on messy, scattered data mostly produces noise. AI on a clean system is where leverage starts to appear.
We built a tool to help
That is the thinking behind crmfinder.opstwo.com.
It does not start with vendor comparison. It starts with what is broken, what the system needs to hold, and whether the business is even a good match for a traditional CRM shape.
Sometimes the answer is a tool. Sometimes it is a different category of tool. Sometimes it is not a tooling problem at all.
That is usually the most useful place to start.
For a good example of what happens when teams stay in tool-comparison mode for too long, this piece is worth reading: I Did Like 57 Different Demos and None of Them Work.