Every group that goes shopping for a CRM for multiple companies runs into the same moment somewhere around the third demo. The platform is impressive. The pipeline views are clean. Then someone asks a plain question: can the sales director of Company B see the deal Company A is working on with a customer they both sell to, without seeing the rest of Company A's book? The answer arrives wrapped in words like "absolutely, with the right configuration", and the configuration turns out to be a project.
That moment is where the real cost of group CRM is decided, and it has almost nothing to do with features on a comparison grid. It has to do with what the product assumes exists beneath the features: one company, one customer list, one hierarchy of people who roll up to one leader.
Executive Summary
Mainstream CRM platforms are built on a single-entity data model, where an account has one owner, users sit in one hierarchy, and reporting rolls up to one organisation. Groups running several trading companies need something structurally different: fine-grained visibility control within each brand and between brands, plus reporting that aggregates across legal entities. Because those needs sit in the foundations rather than in the feature layer, they arrive as configuration projects, and groups pay for them in implementation hours, shadow spreadsheets and custom automation nobody wants to own. Harvard Business Review, citing a dozen analyst reports, put CRM project failure rates anywhere from 18% to 69%, averaging about a third. Market structure explains the gap better than any vendor's negligence: groups are a smaller addressable market with a longer buying cycle, so their fundamentals rarely justify roadmap space.
Why do mainstream CRMs assume a single company?
The assumption is commercial before it is technical. A platform that wants the widest possible market builds for the shape most of that market takes. In the UK, the Office for National Statistics counted 2.73 million VAT and PAYE registered businesses as of March 2025, and the overwhelming majority of them are exactly what a generic CRM expects: one trading entity, one sales team, one customer base. Design for that and you address almost everyone. Design for the group of six companies under a holding structure and you address a sliver, through a procurement process involving an FD, a group IT lead and three brand managing directors who disagree.
In practice, this is the most misunderstood part of the category. Multi-entity capability looks like a feature request and behaves like an architectural one. Permission and visibility control at record level, configurable both inside a brand and across brands, has to be in the foundations of the data model. Bolting it on later means layering rules on top of a system that was designed to answer a simpler question, and the layers are what the implementation invoice pays for.
The result is a product that fits no audience exactly. Generic design steers towards the average customer, and groups sit well outside the average.
Figure
How often CRM projects are judged to have failed
- Lowest analyst estimate18%
- Average across reports~33%
- Highest analyst estimate69%
Failure here covers over-budget delivery, data integrity problems and technology limitations, not only abandonment.
Source: Harvard Business Review, Why CRM Projects Fail (2018), averaging a dozen analyst reports
What breaks first when one CRM runs several trading entities?
Four things break, and they break in a predictable order.
Visibility goes first. Most CRMs are built to manage who sees what inside a single brand, and they do that job with more effort than anyone expects. Between brands the problem changes character, because the rule is no longer about seniority. A group needs one entity's team to see a named customer relationship and nothing else about the entity that owns it, which is a different question from "who reports to whom". Groups that get this wrong either open everything up, which creates a commercial and data protection headache, or lock everything down, which is how the same customer receives three uncoordinated approaches in a fortnight. We have written separately on how CRM permissions across group companies should be scoped.
Ownership goes second. A single-entity CRM gives an account one owner, because that is how commission and forecasting work in one company. A group selling to a shared customer through two subsidiaries has two owners, two margin profiles and, frequently, two contract holders. Shoehorning that into one owner field is where the spreadsheets begin.
Routing goes third. Passing a lead from one company to another inside the same group looks trivial and turns out to require attribution, consent handling and a referral record that both sides trust. Our piece on sharing leads between companies in the same group covers why the hand-off rather than the lead itself is the hard part.
Reporting goes last, and it is the one the buyer notices. A group CEO or FD rarely logs into a CRM except to look at numbers, so the moment consolidated pipeline requires a custom build, the platform has failed the person who signed for it.
| Dimension | Single trading company | Group of trading entities |
|---|---|---|
| Record visibility | One rule set applies to everyone inside the business | Rules must differ within each brand and again between brands |
| Account ownership | One owner, one team, one commission plan | Several owners across legal entities on the same customer |
| Lead flow | Routed inside one pipeline | Referred between entities, with attribution and consent |
| Reporting | One view of pipeline and revenue | Entity-level views plus a consolidated group roll-up |
| Licensing | Seats track headcount | Seats multiply every time a collaborator is added |
| Administration | One administrator, one configuration | Brand autonomy pulling against central control |
Multi-entity capability looks like a feature request and behaves like a foundation.
What does the workaround actually cost a group?
The bill arrives in three currencies: consulting hours, seller time and delayed decisions. Only the first one shows up in the finance system, which is why the other two survive for years.
Take a group of four trading companies sharing sixty sales seats, all on one mainstream platform configured by an implementation partner. Salesforce's 2026 State of Sales research, based on a survey of 4,050 sales professionals, put average selling time at 40% of a seller's week, with the most junior cohort down at 35% and losing roughly two hours a week to manual data entry. If a group's cross-entity workarounds add even one extra hour of re-keying and reconciliation per rep per week, that is sixty hours across the group, week in and week out. Nobody ever raises a purchase order for it.
The second cost is duplicated tooling. Salesforce's earlier State of Sales edition found sales teams using an average of ten tools to close deals, with 94% of organisations planning to consolidate. Groups consolidate less than most, because each brand solved its own gap locally. Gartner's 2023 survey of 501 sellers found 77% struggling to complete their assigned tasks efficiently, which is the lived experience behind every abandoned CRM.
The third cost is the reporting lag. When a group-level pipeline view has to be commissioned rather than opened, the answer arrives after the decision it was meant to inform. We have argued this at length in the cost of custom CRM reports and in group reporting across multiple companies.
Figure
Where a seller's week actually goes
40%
Of the average seller's time is spent selling
The rest goes to admin, research and tool-switching
35%
Selling time for the most junior cohort
Roughly two hours a week lost to manual data entry
87%
Of sales organisations already use AI somewhere
Prospecting, forecasting, lead scoring or drafting
Group structures add reconciliation work on top of the admin load every sales team already carries.
Source: Salesforce, State of Sales 2026 (survey of 4,050 sales professionals)
Why can't the large vendors simply fix this?
Two structural reasons, and neither is about engineering talent.
The first is roadmap arithmetic. Every quarter of build capacity goes to the features that move the largest addressable market. Groups are a minority of prospects, buy more slowly, and involve more stakeholders, so a foundational rework of the permission model loses to a feature with broader appeal every single time. That pattern holds for a decade, and by the end of it the single-entity assumption is load-bearing across thousands of customer configurations.
The second is pricing. Conventional SaaS bills per seat, and collaboration between entities means more people touching the same record. A group doing exactly what the group structure exists to enable, cross-selling the shared customer, generates more seats and more cost. Moving away from per-seat billing now would mean voluntarily repricing a public revenue base, which is close to impossible once analysts are modelling seat growth. A collaborative commercial model has to be designed in from the beginning, which is the argument we make in our work on SaaS pricing models.
There is also a reason the fix is genuinely hard rather than merely unprofitable. McKinsey's analysis of technology in mergers found that 50 to 60% of initiatives intended to capture synergies are strongly related to IT, with successful integrations delivering 10 to 15% cost savings. Commercial systems sit right on the line where group value is either realised or quietly lost. Getting the data model wrong is expensive in both directions, and Gartner's research has put the average annual cost of poor data quality to organisations at at least $12.9 million.
What should a group weigh instead of a feature list?
The buyer and the user in a group are different people with different failure modes, and most evaluations only serve one of them. The FD or group CEO wants a consolidated number they trust, produced without a change request. The sales and account teams want to work a shared customer without emailing a colleague in another company to ask what was quoted. A platform can look excellent to one and be unusable by the other.
That split explains the two ways groups leave a CRM. Some systems go unused, because the day job got harder. Others become too complicated and too expensive, because the group paid to force a fit. Both outcomes trace back to the same origin, a product engineered for the average business meeting an organisation that is structurally not average. If your group is still weighing architecture, one CRM or one per company sets out the trade-off, and our multi-entity CRM pillar collects the rest of the argument.
Frequently Asked Questions
Can a standard CRM handle multiple companies?
A standard CRM can be configured to hold data for several companies, usually through business units, record types or separate pipelines within one instance. The constraint is cross-entity behaviour: sharing a customer between two trading companies while restricting everything else, and reporting across entities without a custom build. Those needs sit in the underlying data model, which is why they typically become configuration or development projects rather than settings.
Why do CRM projects in group structures fail more often?
Failure rates for CRM projects generally are high across the board. Harvard Business Review, averaging a dozen analyst reports, cited estimates ranging from 18% to 69%, with roughly a third the commonly quoted figure. Group structures add variables that raise the risk further: more stakeholders with competing requirements, permission rules that cross legal entities, and reporting that must reconcile several sets of books.
What does multi-entity support actually mean in a CRM?
Multi-entity support means record-level permission and visibility control that can be configured both within a brand and between brands, ownership models that allow more than one entity to hold a relationship with the same customer, and reporting that aggregates to group level while preserving entity-level views. Branded email templates and separate pipelines address presentation rather than structure.
Is one CRM for the whole group better than one per company?
Both arrangements have real costs. Separate systems preserve autonomy and simplify permissions, at the price of manual consolidation and invisible cross-selling. One shared system enables collaboration and group reporting, at the price of harder permission design and the risk that every brand has to accept a compromised process. The decision usually turns on how much genuine trading overlap exists between the entities.
Why don't major CRM vendors build for groups of companies?
Platform roadmaps prioritise capability that serves the largest addressable market, and groups of trading companies are a minority of prospects with longer, more complex buying processes. A foundational change to the permission and reporting model competes against features with far broader appeal. Per-seat pricing compounds the problem, because cross-entity collaboration increases seat counts, so the commercial model rewards the current design.