CRM, ERP or a custom portal: which software does your business need?
Choose business software by the workflow it needs to improve, with a practical checklist for scope and ownership.
A CRM manages customer relationships and sales activity. An ERP coordinates operational records such as orders, inventory and finance. A custom portal gives a particular group of users access to a defined workflow or information. Choose by the business process, required integrations and ownership needs before deciding whether to configure an existing product or build software.
Match the software to the operational problem
| System | Common purpose | Typical users | Success measure | |
|---|---|---|---|---|
| CRM | Manage enquiries, opportunities and follow-up | Sales and customer service teams | Fewer missed follow-ups and clearer pipeline status | |
| ERP | Coordinate linked operational transactions | Operations, inventory and finance teams | Fewer reconciliation errors and more reliable records | |
| Customer portal | Let customers view or submit relevant information | Customers and account managers | Fewer status requests and faster self-service | |
| Internal application | Support a workflow that existing tools handle poorly | A defined operational team | Less manual re-entry and shorter completion times |
Map one complete workflow before listing features
Take a real example, such as an enquiry becoming an order and then a delivery. Record who starts each step, what information they need, where they store it and what can go wrong. A missing reminder may be a CRM configuration problem; conflicting stock records may require an inventory integration. Buying a larger system does not automatically resolve unclear ownership or inconsistent data entry.
Separate the source of truth from convenient copies. If product availability lives in an inventory system, a sales portal should not maintain a second editable stock figure without reconciliation. Decide how changes are shared, how errors are retried and which team resolves conflicts. The difficult part of an integration is often the exception path, not the successful demonstration.
Compare configuration, integration and custom development
Configure an existing product
Start here when the workflow is common and available software meets the essential requirements. Evaluate permissions, export options, reporting and user training as well as the feature list. Ask how costs change with users, records, storage and required extensions. A trial should use representative tasks and sample data.
Connect the systems you already use
Integration can remove repeated data entry without replacing every tool. Confirm that the required API access, identifiers and update methods are available. Define what happens when a service is unavailable or a record is deleted. Include monitoring and a clear owner for failed synchronisation.
Build a focused custom application
Custom development is worth evaluating when the workflow is distinctive or existing tools impose material limitations. Start with a tightly defined process and explicit acceptance criteria. Budget for maintenance, backups, access management and documentation alongside the initial build. Ownership terms should explain source code and data access.
Avoid an unnecessary all-at-once replacement
A phased rollout can reduce disruption when the existing system contains years of operational knowledge. Plan migration, reconciliation, user training and a rollback path. Running two systems temporarily can help validation, but only when responsibility for the authoritative record is explicit.
What to put in a software development brief
- 01
Users and permissions
List each user group and the actions it can take. Include external customers, administrators and staff who change roles. Identify sensitive information and decide who can view, edit, export or delete it. Use sample records without personal customer data during early scoping.
- 02
Workflow and exceptions
Describe the main process and the difficult cases: duplicate records, cancelled orders, failed payments, rejected approvals and interrupted uploads. Specify what users should see when an operation fails and what evidence support teams need to resolve it.
- 03
Integrations and migration
Name the systems, available documentation and data owners. Define fields, unique identifiers and import validation. Set an acceptable reconciliation result and agree who signs off migrated records before the old process is retired.
- 04
Acceptance and maintenance
Write observable outcomes such as completing an approval without manual spreadsheet entry. Assign acceptance testers and specify handover materials, backup checks and maintenance responsibilities. Measure the workflow before launch so the team can compare the result with a real baseline.