Scale and control
Enterprise CRM without the licence
Enterprise CRM usually means four things: many locations, strict permissions, an audit trail and reporting across the lot. None of the four requires a platform licence and a partner. All four require designing them in from the start.
The four requirements behind the word
When a business says they need an enterprise CRM, they rarely mean more features. They mean these, and they are worth separating because they are priced very differently.
- Many locations, branches or entities, each needing its own view while head office sees everything, and with records that cannot leak sideways between them.
- Permissions that hold up to an auditor, meaning field level rather than screen level, attached to roles, with export and deletion logged separately from editing.
- An audit trail, so the question of who changed this and when has an answer that is not a memory.
- Reporting across everything, consolidated and by entity, on numbers that reconcile with finance.
Notice that none of them is a feature you would see in a demo. They are structural, which is exactly why retrofitting them costs several times what building them in does.
What an enterprise platform actually costs
The licence is the part that gets quoted and rarely the largest number. A realistic three year picture for a 120 seat deployment, in US dollars.
| Line | Enterprise platform | Built system |
|---|---|---|
| Licences, 120 seats | 180,000 to 430,000 over 3 years | None |
| Implementation partner | 60,000 to 250,000 | Included in the fixed price |
| Sandbox and environments | Extra tier | Included |
| Internal administrator | Usually a hire | A few hours a month plus aftercare |
| Change requests | Partner day rate | 60 an hour, quoted first |
| Who owns the configuration | The platform | You, as code in your repository |
We are not claiming a built system matches an enterprise platform on breadth. It does not, and for a business that genuinely needs that breadth the licence is fair value. The point is narrower: many companies buy the platform for the four requirements above, then pay a partner to build most of what they use anyway.
Permissions, designed rather than accumulated
Permissions become unmanageable when they grow by exception. We define them once, from roles and a short list of genuinely sensitive things, before anyone is invited in.
That list is usually shorter than expected: margin and cost, salaries and rates, case or clinical notes, client financial detail, and anything a regulator can ask about. Everything else is better visible, because hidden information is what makes people build private spreadsheets.
Four rules then apply without exception. Permissions attach to roles and never to individuals, so removing a leaver is one action. There are always at least two administrators. Export and delete are separate, logged permissions. And access to sensitive fields is logged with who read what, because that is the first question after any incident.
The practices around this are set out in CRM best practices, and the permission model is written into the two page scope before the build starts.
Single sign on, provisioning and the IT conversation
Three requests come from IT rather than from the business, and they are all reasonable.
Single sign on against Microsoft Entra or Google Workspace, so there is no separate password and a disabled account loses access everywhere at once. This is a standard integration and we build it when asked.
Provisioning and deprovisioning, so joiners and leavers are handled by the directory rather than by someone remembering. In practice most businesses this size are well served by a weekly reconciliation report rather than full automated provisioning, and we say so rather than selling the larger option.
A security review. We answer questionnaires, provide the architecture in writing and support a penetration test against a staging copy. Because the system is in your account, your own security team can review it directly rather than reading a vendor's certification.
What we build
What changes at enterprise scale
The same system, with four structural decisions made at the start rather than added later.
Entity and location model
Records belong to a branch, region or legal entity, with visibility rules between them and consolidated reporting across all of them.
Field level permissions
Roles that can see a customer without seeing margin, or a case without seeing the financial detail, enforced at the data layer rather than in the interface.
Full audit trail
Every change to a tracked field stored with who, when and the previous value, queryable, and retained for the period your policy requires.
Reporting that reconciles
Consolidated and per entity, on the same identifiers your finance system uses, so two reports of the same month agree.
Questions we get asked
What makes a CRM an enterprise CRM?
Four structural things rather than features: multiple locations or entities with controlled visibility between them, field level permissions attached to roles, a real audit trail, and reporting that consolidates and still reconciles per entity. None of them shows up in a demo, and all of them are expensive to add afterwards.
Can a custom CRM handle a large organisation?
For the four requirements above, yes, and at a fraction of a platform licence. What a built system will not match is the breadth of an enterprise suite across every department. If you need that breadth genuinely, the licence is fair value, and we will say so during discovery rather than after.
Do you support single sign on?
Yes, against Microsoft Entra or Google Workspace, so there is no separate password and disabling a directory account removes access immediately. Full automated provisioning is available, though most businesses of this size are better served by a weekly reconciliation report, which is cheaper and easier to verify.
How are permissions handled across locations?
Records belong to a branch, region or legal entity, and visibility rules decide what crosses between them. Head office sees everything, a branch sees its own, and regional roles sit in between. The rules attach to roles rather than to individuals, so staff changes are a single action.
Can our security team review the system?
Yes, and they should. The code is in your repository and it runs in your hosting account, so your team can read the architecture, run a penetration test against a staging copy and check the configuration directly. That is a different kind of assurance from reading a vendor's certification.
Tell us how your business works. We will quote the CRM that fits it.
A 30 minute written brief from you, a fixed price and a two page scope from us within two business days. No call required, no obligation.