A CRM requirements checklist defines what your customer relationship management system must enable before you compare products. It should cover the sales process, customer data, ownership, pipeline stages, follow-up rules, integrations, reporting, permissions, migration, security and exit requirements.
The essential order is: map how an enquiry becomes revenue, decide what information and controls that process needs, then test software against those requirements. Starting with demonstrations or feature lists usually reverses the decision. The business ends up adapting its process to a product it has already chosen.
For an established service business, the best CRM is the smallest dependable system that supports the real customer journey, clear ownership and useful evidence.
Why CRM selection often goes wrong
Many CRM projects begin when a spreadsheet becomes difficult to manage, leads are being missed or reporting is unreliable. The pressure to solve the problem quickly encourages teams to compare familiar products before defining what the system must achieve.
The underlying questions are operational:
- Where do enquiries originate?
- What makes an opportunity qualified?
- Who owns the next action?
- Which stages reflect genuine progress?
- What follow-up is required at each stage?
- Which information must be visible to sales, delivery and management?
- What must happen when a prospect becomes a customer?
If those answers are unclear, a new platform will preserve the uncertainty behind a more polished interface. Duplicate records, inconsistent stages, forgotten tasks and untrusted reports can continue because the operating rules were never defined.
CRM selection should follow process design. Our guide to the systems a new business needs first applies the same principle at an earlier stage: a tool is useful only when its role, owner and relationship to the rest of the business are clear.
Start with the commercial outcome
Write one sentence explaining what the CRM must improve. Avoid broad goals such as “centralise everything” or “increase efficiency”. They cannot be tested.
A stronger outcome might be:
Every qualified website enquiry has an owner, a dated next action and a visible route from first response to won, lost or nurture.
That sentence creates measurable requirements. The CRM must receive the enquiry, identify its status, assign responsibility, record the next action and preserve an outcome. It also exposes what the CRM should not become: an indiscriminate store for every document, message and operational task.
Add two or three supporting measures, such as time to first response, opportunities without a next action, stage ageing or qualified-to-proposal rate. Use measures the team can define consistently.
Map the process before documenting features
Record the current journey from first contact to customer handover. Include website forms, telephone enquiries, referrals, email, events and any other genuine source.
For each step, identify:
- The trigger that begins the step.
- The person or role responsible.
- The information required to continue.
- The decision being made.
- The expected next action and timing.
- The system currently used.
- The point at which work is delayed, duplicated or lost.
Review recent enquiries and ask the people who handle them. Exceptions often reveal requirements that a neat process diagram misses.
Then simplify. A service business rarely needs fifteen pipeline stages. Each stage should represent a meaningful commercial change, not a minor task. If two stages have the same owner, evidence and next action, they may be one stage.
Define the minimum customer data
A CRM should hold enough information to support a defined purpose, not every field a platform makes available.
Document the data required at each stage. Typical categories include:
- Contact and organisation details.
- Enquiry source and campaign information.
- Service or problem of interest.
- Qualification evidence.
- Budget or commercial range where appropriate.
- Decision timing and relevant stakeholders.
- Consent, communication preference and lawful-basis records where required.
- Opportunity value, stage, owner and next action.
- Won, lost or nurture outcome and a consistent reason.
Separate required information from useful and optional information. Required fields should be limited to what the team can collect accurately and use. Excessive mandatory fields encourage workarounds, poor-quality entries and delayed updates.
The ICO’s current guidance on data protection by design and by default says organisations should consider personal-information use from the planning stage and limit collection, processing, retention and access to what is necessary for the stated purpose. That makes the data model a selection requirement, not a compliance task to add after implementation.
Specify ownership and pipeline rules
Software cannot resolve ambiguous accountability by itself. Define who owns a record, when ownership changes and what happens if the owner is unavailable.
For every pipeline stage, document:
- Entry criteria: the evidence required to enter the stage.
- Owner: the role accountable for progress.
- Required fields: the information needed at that point.
- Next-action rule: what must be scheduled and by when.
- Exit criteria: the evidence required to move forward.
- Stale rule: when the system should flag inactivity.
- Outcome rule: how won, lost, disqualified and nurture records are handled.
These rules prevent optimistic pipelines in which opportunities move forward without a verifiable buyer action. They also create useful automation requirements. The system may assign enquiries, create response tasks, flag opportunities without a next action or begin nurture after an agreed outcome. Automate a clear rule, not uncertainty.
List the integrations and data flows
The CRM is part of a wider commercial system. Map the information entering and leaving it.
Common connections include:
- Website forms and landing pages.
- Shared or individual email accounts.
- Calendar and meeting booking.
- Telephone or call-recording services.
- Marketing email and consent records.
- Quoting, proposal or electronic-signature tools.
- Invoicing, finance or payment systems.
- Customer onboarding and service-delivery platforms.
- Analytics and reporting.
For each connection, state the direction of the data, the triggering event, the fields exchanged, the system of record and the failure response. “Integrates with the website” is not a complete requirement. “Creates or updates a contact and opportunity within two minutes of a valid form submission, preserves source fields and alerts the owner if transfer fails” is testable.
Use the Acquisition Works services overview to see how website, conversion, CRM, automation and measurement requirements should be considered as one journey rather than separate purchases.
Set reporting requirements from decisions
Ask which decisions the business needs the CRM to support. Then define the data and calculation behind each report.
Useful operational questions include:
- Which sources create qualified opportunities rather than raw enquiries?
- How quickly are new enquiries receiving a meaningful response?
- Which opportunities have no owner or next action?
- Where does pipeline movement slow down?
- Why are suitable opportunities being lost?
- What value is realistically expected by period and stage?
- Which follow-up activities are associated with progress?
Define terms before selecting charts. If “qualified lead”, “proposal sent” or “sales cycle” means something different to each person, the platform will calculate inconsistent assumptions accurately.
Include exportable detail behind important summaries. Management should be able to trace a headline measure to the records that produced it.
Treat permissions and security as functional requirements
CRM records can contain personal information, commercially sensitive notes and customer history. Access should follow job requirements rather than convenience.
Document:
- User roles and the records each role can view, create, edit, export or delete.
- Administrator responsibilities and backup administrators.
- Authentication and multi-factor requirements.
- Joiner, mover and leaver processes.
- Audit history for material record changes.
- Export controls and monitoring.
- Backup, recovery and business-continuity expectations.
- Supplier incident and breach support.
The National Cyber Security Centre’s secure user-management principle recommends permissions applied to individual human or machine identities, including role-based access control. Its guidance for small organisations also stresses protecting accounts and maintaining recoverable backups. Those controls should appear in the evaluation, contract and implementation plan.
Include migration, contract and exit requirements
Selection is incomplete until the business knows how it can enter and leave the platform.
Define:
- The sources and volume of existing records.
- Which data will be cleaned, merged, archived or excluded.
- Required import formats and validation rules.
- Ownership of notes, files, activities and custom fields.
- Available export formats and whether relationships are preserved.
- API access and any usage limits.
- Contract term, renewal, price-change and cancellation rules.
- Data return, deletion and support at the end of the contract.
The ICO’s guidance on controller-processor contracts explains that qualifying contracts must address processing details, security assistance, individual rights and what happens to personal data at the end of the arrangement.
GOV.UK’s current service guidance on choosing tools and technology also recommends understanding total cost of ownership and preserving the ability to make different choices later. Its guidance on managing technical lock-in in the cloud highlights open standards, formats and control of data as practical SaaS considerations.
A small company can still become dependent on a workflow it cannot export, an integration available only on a higher package or a contract that becomes expensive when the team grows.
Build a weighted CRM requirements checklist
Convert the work into a comparison sheet. Group requirements under commercial process, data, workflow, integrations, reporting, permissions, implementation, support, contract and exit.
For each requirement, record:
- The requirement in testable language.
- Why it matters.
- Priority: essential, important or optional.
- How it will be demonstrated or verified.
- The person responsible for acceptance.
- One-off and recurring cost.
- Product limitation, workaround or dependency.
Weight requirements by commercial importance before demonstrations begin. A visually impressive optional feature should not compensate for failure on lead ownership, data export or a critical integration.
Ask vendors to demonstrate your scenarios using realistic sample records. Test the journey from enquiry through assignment, follow-up, stage change, reporting and handover. Include an exception so the team can see how the system behaves when the process is not perfect.
Calculate the total implementation requirement
Licence price is only one component. Compare:
- Setup and configuration.
- Data cleaning and migration.
- Integration build or connector plans.
- Training and adoption support.
- Internal administration time.
- Reporting and dashboard work.
- Ongoing optimisation.
- Additional storage, API, user or automation costs.
- Exit and data-extraction effort.
Identify who will maintain stages, permissions, fields, automations and reports after launch. A platform without an accountable owner slowly becomes unreliable.
The connected-business-system service page explains how Acquisition Works maps commercial requirements across the website, CRM, follow-up and operational workflows before recommending implementation.
Decide from evidence, then configure in phases
Shortlist only products that pass the essential requirements. Score the remaining options, document assumptions and run a controlled proof of concept where the risk justifies it.
Implement the smallest complete journey first: capture a valid enquiry, create or update the correct record, assign an owner, schedule the next action, move through agreed stages, produce an outcome and hand the customer to delivery. Verify permissions, reporting, errors and recovery around that journey.
Add secondary automations and dashboards after the core records are trusted. This reduces implementation risk and gives the team a stable process to learn.
Diagnose the customer journey before buying the CRM
A CRM purchase should resolve a defined commercial constraint. If the website, enquiry handling, qualification, follow-up and ownership rules are disconnected, comparing products will not reveal which intervention should come first.
The £297 Acquisition Works Audit reviews the website-to-enquiry journey, follow-up, CRM and relevant workflows as one system. Within five working days, you receive prioritised actions and an implementation roadmap showing what to clarify, connect or improve before committing to software or a larger build.