The questions to ask when choosing a CRM stack

Stack selection usually starts with a shortlist of vendor names and ends with a decision nobody can explain eighteen months later. The names are the least useful place to begin.

Start instead with the tool classes. Four of them cover almost everything a CRM programme needs, and most confusion in selection comes from two vendors in different classes being compared as if they did the same job.

We are deliberately not ranking products here. The right combination depends on your data, your volumes and the team you actually have, and the same vendor can be an excellent fit for one brand and a poor one for its competitor.

Learn the four tool classes before the demos

The engagement platform sends the messages. It holds journeys, campaigns, templates, frequency rules and channel delivery across email, push, SMS, in-app and web. Braze, Bloomreach, Insider and Maestra sit in this class, among others.

The customer data platform collects, resolves and segments customer data, then pushes audiences to downstream tools. Some engagement platforms include CDP-style capability, which is where category confusion usually starts.

The warehouse is where your customer, order, product and event data lives in queryable form. Snowflake and Databricks are common choices, alongside the cloud-native options.

The reverse-ETL tool moves data from the warehouse into operational tools, so a segment defined in SQL becomes an audience in the engagement platform. Hightouch is the best-known example of this class.

A stack can combine these in several shapes. Warehouse plus reverse-ETL plus engagement platform is common now, and so is CDP plus engagement platform with no warehouse involvement.

Both shapes work. What does not work is buying two tools that each assume they own segmentation.

Start from the warehouse question

The first real question is where the single version of your customer will live, and who controls it.

If you already have a warehouse with clean order and event data, build the stack around it. Define segments in SQL, sync them out, and keep the engagement platform focused on delivery and journey logic. You get one definition of "active customer" that marketing and finance can both point at.

If you have no warehouse and no data team, a CDP or a data-capable engagement platform will get you live much faster. The trade-off is that your segment logic now lives inside a vendor, and moving it later is real work.

Questions to ask in either case:

• Who can change a segment definition, and how long does that take?
• If we replaced the engagement platform next year, what would we have to rebuild?
• Where is the identity resolution happening, and can we inspect its rules?
• Can analytics reproduce a marketing segment independently?

Ask what the engagement platform is actually for

Demos tend to showcase journey builders. Useful, but rarely the deciding factor. The differences that matter show up in operations.

Work through these with each vendor, using your own scenarios rather than theirs:

• Channels: which do you need on day one, and which are genuinely native rather than a partner integration?
• Volume and velocity: peak sends per hour, and how real-time the triggers are in practice.
• Deliverability controls: dedicated IP options, warm-up support, seed testing, and how sending reputation is managed. If you are starting from a new IP, our note on IP warming from zero covers what that process demands.
• Localisation: how multi-language content is handled inside one journey.
• Permissions: whether you can let a regional team build without letting them send.
• Data in and out: event ingestion limits, and whether you can export raw event data on your own schedule.

That last one matters more than it looks. If you cannot get event-level data back out cheaply, your revenue reporting is stuck inside the vendor's definitions, which is the problem we describe in CRM to revenue measurement.

Price the running cost, not the licence

Licence fees are the visible number and often not the largest one. Build a two-year cost view that includes the parts vendors do not quote.

Count implementation, which is usually three to six months of work for a mid-sized programme. Count warehouse compute if segments run frequently. Count data volume growth, since most contracts price on profiles or events and both grow faster than expected.

Count the internal cost too. A stack that needs a data engineer to change a segment has a permanent staffing requirement attached to it, and that cost outlives any discount you negotiate at signature.

Then ask about the exit. Contract length, data export format, notice period, and what happens to your journey logic if you leave.

Match the stack to the team you have

The most common selection error we see is buying for the team the company plans to hire rather than the one it has.

A warehouse-first stack rewards a team with SQL skills and analytics support. A CDP-led stack rewards a marketing team that needs to move without engineering. Neither is more advanced, and they fail in different ways.

Run a proof of concept on one real programme, not a sandbox. Build your actual onboarding journey, with your actual data, and see how long each step takes. Two weeks of that beats two months of feature comparison.

Where a selection needs an independent view, or the build needs hands, that is what our implementation team does.

What to do this week

• Write down which of the four tool classes each product in your current stack occupies, and mark any job that two tools both claim.
• Pick one segment definition and trace who can change it, where it lives, and how long a change takes to reach a send.
• Build a two-year cost view for your current stack including implementation, compute and internal time, then compare it to the licence figure you usually quote.