CRM, ERP & business software 
The short answer
The cost of a custom CRM depends less on the number of screens than on the processes, data, connections and rules the product must support.
The rules the product must support.
- 01Map one priority process before listing features.
- 02Audit data, permissions and integrations before finalising the estimate.
- 03Start with a pilot group to reduce organisational risk.
01
What really drives the budget
A custom CRM budget covers five areas: processes, user journeys, data, integrations and rollout. Complexity depends less on screen count than on the rules the product needs to support.
Make these factors visible before comparing estimates. Similar interfaces can conceal very different levels of effort.
The five factors to examine
- 01
Business processes
The steps, exceptions and approvals to coordinate.
- 02
Roles and permissions
What each role can view, change or approve.
- 03
Data quality
Volumes, duplicates and missing information to migrate.
- 04
Connected tools
Flows with accounting, marketing and operations.
- 05
Adoption
Piloting, training, support and handover to the team.
02
Map the process before designing screens
A useful CRM reflects how teams prospect, qualify, sell and support customers. A feature list alone does not explain the responsibilities or decisions connecting these steps.
Discovery makes the main journey, exceptions and required information visible. This map becomes a shared basis for design and estimation.
Questions to make explicit
- 01
Who creates or qualifies an opportunity?
- 02
Which steps can block a sale?
- 03
Which indicators trigger a decision?
- 04
Who can change sensitive information?
- 05
Which exceptions require approval?
03
Estimate data, permissions and integrations
Importing inconsistent files, deduplicating contacts and synchronising tools requires explicit rules. Migration is more than moving columns.
Assess each connection based on API quality, data volumes, exchange frequency and the consequences of losing synchronisation.
The data journey
- 01
Existing sources
Files, legacy tools and forms
- 02
Cleaning and migration
Formats, duplicates and mapping rules
- 03
CRM
Permissions, history and business logic
- 04
Ecosystem
Accounting, marketing and reporting
| Dimension | Simple case | Complex case |
|---|---|---|
| Data | One clean source | Several incomplete or conflicting sources |
| Permissions | A few stable roles | Permissions by team, territory or data type |
| Integrations | Reading from a stable API | Two-way synchronisation or legacy tools |
| Automation | Simple alerts and tasks | Conditional rules and multiple approvals |
| Traceability | Standard history | Detailed audits and compliance requirements |
04
Illustrative example: a sales team with scattered files
Imagine a B2B business whose salespeople track prospects across several files while preparing proposals in another tool. Managers have no shared view of opportunities.
This example is deliberately fictional: it illustrates how to reduce scope without hiding decisions that still need to be made.
The initial scope
- Centralise contacts and companies
- Share a common sales pipeline
- Assign each opportunity clearly
- Display an initial dashboard
- Defer secondary automations
A first release in four steps
- 01
Map
Understand the current process and its exceptions.
- 02
Prototype
Validate the priority journey with users.
- 03
Test migration
Import a representative data sample.
- 04
Launch a pilot
Observe usage before extending the rollout.
What this example helps you decide
- The essential scope of the first release
- Unknowns to investigate before committing
- Features that can wait without blocking learning
05
Roll out without disrupting the organisation
A CRM changes habits, responsibilities and sometimes how performance is measured. Rollout is therefore part of the product, not just its communication.
A phased approach lets a small group test rules and data before the whole organisation changes how it works.
From discovery to continuity
- 01
Discovery
Align needs, scope and responsibilities.
- 02
Prototype
Validate journeys and sensitive rules.
- 03
Pilot
Test with a small group and controlled data.
- 04
Rollout
Train, support and respond to feedback.
- 05
Handover
Document access, the product and maintenance.
Prepare
- ✓Data and samples
- ✓Owners and approvers
- ✓Success criteria
- ✓Training and support
Avoid
- ×An immediate full switchover
- ×Untested migration
- ×Late training
- ×Depending on one person
06
Compare proposals on the same basis
A useful proposal separates discovery, design, migration, integration and support. It also explains the assumptions behind the estimate.
Comparing totals alone often hides differences in scope, expected quality or responsibility.
| Area | What should be explicit |
|---|---|
| Discovery | Deliverables, workshops and expected decisions |
| Design | Journeys covered and level of fidelity |
| Migration | Volumes, cleaning, testing and responsibilities |
| Integrations | Flows, frequency, errors and maintenance |
| Quality | Testing, security and acceptance criteria |
| Handover | Code, access, documentation and support |
Six questions before comparing prices
- Is the priority scope described in the same way?
- Are assumptions and exclusions visible?
- Are migration and data cleaning included?
- Do integrations cover error handling and maintenance?
- Are acceptance criteria and responsibilities clear?
- Will access, code and documentation be handed over?