Most software evaluations start with a feature comparison, which is close to the least useful place to start. Every platform in this category will tick most boxes on a requirements spreadsheet. What separates them is not capability but the assumptions each one makes about the business buying it: about your technical resource, your structure, and your appetite for assembly.
Here is an attempt at an honest framework, written by a vendor in the category. Read it accordingly, and note that we have tried to be specific about where we lose.
The three bets
Salesforce: betting on ecosystem and extensibility
Salesforce's proposition is that whatever you need, it either exists on AppExchange or can be built. That is genuinely true, and it is backed by the deepest partner network and the most mature enterprise track record in the category.
The assumption underneath it is that you have implementation capacity: internal developers, a partner budget, or both. And a procurement process that rewards ecosystem scale. Configuration is powerful and complex; territory management can express almost any organisational structure, but "can express" and "expresses out of the box" are different propositions with different costs.
Choose it when: you are an enterprise with developer resources, complex or global requirements, and procurement that values a safe, established answer. If AppExchange breadth or existing ISO 27001 and SOC 2 attestation is a gate for you, this is a legitimate and probably decisive reason.
Be cautious when: you have no dedicated RevOps or IT function. The implementation-partner dependency is real, and the cost and timeline it implies are the most common source of disappointment for smaller buyers.
Zoho One: betting on catalogue breadth
Zoho's proposition is forty-plus applications at competitive per-user pricing. The catalogue genuinely exceeds most alternatives, including areas we do not address at all: inventory, full statutory accounting, e-commerce.
The assumption is that you want maximum optionality and are willing to do the assembly. Each application has its own data model and admin surface. Making them behave as one system is integration work, and it lands on you. Deeper automation frequently reaches for Deluge scripting, which reintroduces the technical dependency that smaller businesses are usually trying to avoid.
Choose it when: you have unusual, narrow requirements spanning many functions; you value per-app pricing flexibility; and you have the appetite to assemble and maintain the stack.
Be cautious when: your actual complaint is that your tools do not talk to each other. Buying a larger catalogue of separately-modelled applications does not solve that; it relocates it.
A purpose-built Business OS: betting on pre-integration and a specific structure
The proposition is a smaller set of modules that share one data core, opinionated about how a particular kind of business runs: in our case, branch-first and center-first, multi-location, without dedicated technical resource.
The assumption is that pre-integrated depth across sales, people, money and service beats catalogue breadth, and that customisation through configuration beats customisation through code. That is a bet, and it is wrong for some businesses.
Choose it when: you run 20–500 people across two or more branches, centers or field teams; you are currently running three or more disconnected tools; you have high lead or call volume; and you have no RevOps or IT function to run an implementation.
Be cautious when: you need ecosystem breadth, inventory management, open source and self-hosting, or certifications that are not yet in place. Those are real gaps and we would rather you weigh them now.
The four questions that actually decide it
Feature lists converge. These do not.
1. Who is going to configure and maintain this?
The single most predictive question, and the one most often skipped.
If the answer is "a partner" or "our developers", platforms that assume technical resource become viable and their power becomes an advantage. If the answer is "our operations manager, alongside her actual job", then any platform requiring code or scripting will end up half-implemented. Which is worse than a simpler platform fully implemented.
Be honest here rather than aspirational. Most disappointing implementations trace back to an optimistic answer to this question.
2. Is your structure single-site or multi-site: now or within two years?
This is the question with the longest tail, because it is expensive to get wrong and invisible at the start.
If you run one location and will continue to, location is a reporting field and any platform handles it. If you run several, or plan to, the question becomes whether branch and center are primitives in the data model or attributes you maintain. The difference does not surface during evaluation: it surfaces at the second location, by which point you have migrated your data and trained your team.
Test it directly. Ask to see a branch manager's login and where their scope was configured. Ask to rank all locations by conversion and observe how much setup that took. Ask to add a new location and count the steps.
3. What is your actual bottleneck?
Not your longest requirements list. Your binding constraint.
- If it is top-of-funnel content and inbound demand, a specialist marketing platform's depth may outweigh everything else. HubSpot leads on that dimension and we say so in our own matrix.
- If it is inventory, production or stock, an inventory-first system is the honest answer and Odoo is strong there.
- If it is customer service specifically, a mature helpdesk has years of refinement you will notice.
- If it is that nothing connects: branch chaos, manual handoffs, telecalling accountability, attendance-to-payroll reconciliation. That is the operating-system case.
Businesses routinely buy for the requirement list and then discover the bottleneck was elsewhere.
4. How fast do you need to be live, and what happens if you are not?
Implementation timelines vary from days to quarters across this category, and the difference is structural rather than a matter of effort. Configuration-based platforms deploy in days because there is nothing to build. Partner-led platforms take months because there is.
Neither is wrong. But a business that needs follow-up discipline working next quarter should not choose a platform whose realistic timeline is two quarters, however capable it is at the end of them.
A note on total cost
Compare stacks, not seats. The relevant number is not per-user cost against your current CRM: it is total cost of everything you are replacing, plus implementation, plus the recurring manual reconciliation that does not appear on any invoice.
For most growing businesses, the largest line in that calculation is time spent moving data between systems, and it is invisible in every vendor comparison including ours. Count your own hours before you compare anyone's pricing.
How to run the evaluation
Three practical suggestions.
Bring your actual structure to the demo. Not a generic scenario: your branches, your roles, your handoffs. Ask each vendor to show, not describe, how their platform expresses it.
Ask each vendor where they lose. A vendor who cannot name a competitor's genuine advantage is either not paying attention or not being straight with you. Both are informative.
Test the boring path. Not the impressive demo flow. The thing you will do two hundred times a month. Adding a lead. Logging a call. Approving leave. Running the month-end reconciliation. That is where the platform either saves you time or does not.
The best outcome of an evaluation is not choosing the most capable platform. It is choosing the one whose assumptions match your reality: because the mismatch, not the missing feature, is what makes these decisions expensive.