Questions to Ask Before You Buy a CRM (That Your Vendor Won't Bring Up)

You're about to spend $50k–$250k on a system. What are you actually buying?

The average mid-market CRM or ERP implementation — licences, implementation, integrations, training, and internal time — lands somewhere between $50,000 and $250,000. That's before you factor in productivity loss during transition and the cost of doing it again if it doesn't work.

And most of the time, it doesn't work. Not because the software is bad. Not because the vendor was dishonest. But because the buying process focuses on the wrong things: features, pricing tiers, ROI projections, and case studies from businesses that are nothing like yours.

The most important questions you need to answer before buying a CRM aren't about the system at all. They're about your business. How work moves through it. Where information breaks down. What decisions you're trying to make faster, and who actually needs what data to make them.

Every piece of content you'll find online about "questions to ask before buying a CRM" falls into one of three traps. Either it's a vendor checklist (does it have email integration? does it have a mobile app?), a generic guide (define your requirements, get stakeholder buy-in), or a comparison article that funnels you into choosing between platforms before you've figured out what you actually need.

This isn't that. The questions below are ones you need to ask your own team — before you talk to a single vendor. They're harder than "which CRM should I buy?" But they're the only questions that make the answer matter.

The question nobody asks first: "How does work actually move through our business?"

Before you evaluate any system, you need to be able to describe — concretely, in a way that every department agrees on — how a piece of work moves from first contact to final invoice. A sales lead, from the moment it's created through to the point where cash is received. A project, from proposal acceptance to delivery sign-off and payment.

Most businesses can't do this cleanly. They can describe it roughly. But when you push for specifics — who updates what, when, in which system, and what triggers the next step — things get murky fast. Different people describe the same process differently. Some steps exist only in someone's head. Some handoffs rely on one person remembering to do something.

This is where most CRM projects go wrong — not at implementation, but here, years before the purchase decision. The vendor demo shows you a clean, logical flow. You nod along because it makes sense. But that clean flow is built on the assumption that your data is clean, your processes are consistent, and your team will adopt the system. None of those assumptions survive contact with reality unless you've done the foundational work first.

Kaizen's operating principle is: map the flow before you touch the system. It sounds obvious. Almost nobody actually does it before buying.

Five questions to ask your own team before you talk to a vendor

These aren't questions for the executive sponsor. They're questions to work through with the people who actually do the work — your sales team, your project managers, your delivery leads, your finance people. The answers will tell you more about what you need from a CRM than any feature comparison.

• Where does information get entered more than once? If a client detail lives in your quoting tool, your project management system, and your accounting software — each one entered by a different person — that's not a data problem. That's an architecture problem. The cost of that re-entry is real and measurable, and any CRM you buy needs to address it, not add to it.
• What decisions are we making on data that's more than a week old? If you can't answer "what's the margin on our active projects right now" without spending an afternoon pulling numbers together, your systems are giving you a rear-view mirror instead of a dashboard. A CRM won't fix this unless you know which data flows need to connect.
• If we connected finance and operations tomorrow, what would we want to see first? This question bypasses wishful thinking and gets to operational priority. When your accountant and your project manager are looking at different numbers, what's the version of the truth you actually want? That's your integration requirement — not a feature list.
• Who are the people holding everything together manually — and what would free them up? Every business has someone who is effectively a human integration layer. They know where everything is, translate between systems, and fill the gaps. When they're on leave, things break. That person's job is your current-state architecture. Understanding what they do tells you exactly what the system needs to automate.
• What broke last time we grew 30%? Growth exposes the gaps that daily operations hide. The signs that you've outgrown your current setup are usually visible in hindsight. Looking at the last growth phase tells you where the architecture was load-bearing and what assumptions it was built on. If the same things will break again at the next growth stage, that's your design brief.

The purpose of these questions isn't to produce a requirements document. It's to develop a shared, accurate picture of how your operation actually works — not how you'd like it to work, and not how the vendor assumes it works.

Three questions to ask any vendor (that most don't want to answer)

Most vendor demos are theatre. They show you a polished system running on clean data, with perfectly configured workflows that match a generic mid-market business. They answer the questions you ask and don't volunteer the ones you should have asked.

These three questions are designed to separate vendors who genuinely want to solve your problem from vendors who want to close your deal.

• How will you learn how our business actually works before you propose a solution? A vendor who answers this with "we'll do a requirements workshop" is fine. A vendor who answers this with "we've got a proven methodology for businesses like yours" without first asking what makes your business specific is telling you something important about how the implementation will go. The right answer involves real curiosity about your operational model — not a template.
• What happens when our requirements change mid-project? They always do. You'll discover a workflow mid-implementation that nobody mentioned in scoping. The question isn't whether scope will shift — it's how the vendor handles it. A good answer describes a structured change management process. A bad answer involves vague reassurances about "flexibility." How a vendor responds to this question predicts what your invoice will look like at month three.
• Can you show me a reference from a business our size, in our industry, where the system is still working well eighteen months after go-live? Go-live is easy. Adoption is hard. A CRM that's working twelve months after implementation — actually being used by the people it was built for, with data quality that's maintained — is a much higher bar. Any vendor confident in their implementation quality will be happy to make this introduction.

If a vendor can't or won't answer these questions clearly, that's not a reason to walk away — it's a reason to ask more carefully. But if the evasion continues, it tells you something about what the relationship will look like once they have a signed contract.

What "ready to buy" actually looks like

A business that's genuinely ready to buy a CRM looks different from one that's been pushed there by a vendor demo or a board directive to "do something about the systems."

Ready looks like this: they can describe their operational flow end-to-end. They know where data breaks down. They've talked to the people who actually do the work, not just the executives who sponsor the project. They have a clear picture of what "connected" means for their specific business — what decisions would be faster, what visibility would be clearer, what manual work would disappear. And when they walk into a vendor conversation, they're leading the process, not following a demo script.

Not ready looks like this: they've sat through three demos and they're comparing feature lists. They have a vague brief ("we need a CRM to manage our pipeline better") that hasn't been tested against how the pipeline actually works today. Their requirements are a wishlist, not a design specification. The people who'll use the system weren't consulted. And the implementation budget doesn't include the cost of the internal time it'll take to actually configure and adopt the tool.

This preparation work isn't complicated. It's just uncomfortable. It requires looking honestly at how your operation runs today — including the parts that are embarrassing, the processes that rely on one person, the data that's unreliable. The businesses that do this work first get better outcomes from their implementation, spend less on remediation after go-live, and end up with systems their teams actually use.

Where to start

Don't start with a vendor shortlist. Don't start with a feature comparison. Don't start with a budget.

Start with a current-state map. Pick one workflow — the one that's most important to your revenue — and follow it from first touchpoint to final payment. Write down every step. Note every system it touches. Mark every handoff. Count how many times the same data gets entered by different people. Identify where the delays happen. Find the steps that rely on a single person knowing something.

That map is your design brief. It tells you what the system needs to connect, what it needs to automate, what data it needs to hold, and what decisions it needs to support. It also tells you what you can skip — the features that look impressive in a demo but don't actually match how your business works.

Once you have that map, you can walk into any vendor conversation with a concrete brief rather than a vague problem statement. You'll ask better questions. You'll evaluate answers more critically. And you'll end up with a system that's actually built for your operation — not for the generic mid-market business in the vendor's case study.

If you're not sure where to start, or if the map reveals something more complex than you expected, that's exactly the conversation Kaizen's Operational Scorecard is designed for. Thirty minutes, no pitch — just a structured look at how work flows through your systems and where the gaps are costing you.