CRM requirements gathering should describe how work happens, where it varies and what a successful outcome looks like. Before asking suppliers for demonstrations or estimates, document one important workflow from trigger to outcome, including its exception paths, data, users, integrations and acceptance criteria.
That short brief gives suppliers something meaningful to respond to. It also helps your team decide whether an off-the-shelf CRM can be configured to fit, a semi-bespoke system would close the important gaps, or a bespoke CRM is justified.
Vivato builds bespoke and semi-bespoke CRM systems for UK organisations. The most revealing requirements are rarely broad requests such as “automate follow-ups”. They are the details around who can do what, which conditions change the route and what happens when the normal process breaks down.
What is CRM requirements gathering?
CRM requirements gathering is the process of defining what a CRM must achieve, how users and systems will interact with it, and how the organisation will decide whether it works. It covers business outcomes, workflows, data, permissions, integrations, reporting and non-functional needs such as security, performance and accessibility.
Requirements gathering is not the same as writing a feature wish list. “Dashboard”, “email integration” and “automation” name capabilities, but they do not explain the business behaviour required. A supplier cannot reliably estimate or demonstrate fit without that context.
If you are still establishing whether change is necessary, start with the signs that your business has outgrown its CRM. Once the case for change is clear, requirements gathering turns the problem into a comparable buying brief.
Why should you map exceptions before features?
The standard route shows what most CRM products can do. Exception paths reveal where your organisation's real complexity lives.
A normal sales process might be: qualify an enquiry, create an opportunity, issue a proposal and record the result. The useful questions sit underneath it:
- What happens when one enquiry relates to several sites or business units?
- Can a proposal proceed when mandatory information is missing?
- Who approves a non-standard discount, and what evidence must they see?
- What happens when a customer pauses, changes legal entity or disputes a term?
- Which event restarts a service-level timer?
- Can two teams own different parts of the same relationship?
These variations affect data structures, permissions, notifications, audit history and reporting. Discovering them during implementation can change the proposed solution. Discovering them before selection lets every supplier respond to the same problem.
Use the following distinction when reviewing your notes:
| Requirement type | Weak description | Decision-ready description |
|---|---|---|
| Business outcome | Improve follow-up | Reduce unowned qualified enquiries and show their age by team |
| Workflow | Automate approvals | Route discounts above an agreed threshold to a named role and record the decision |
| Exception | Managers can override | Permit an override only with a reason, timestamp and retained audit entry |
| Reporting | Better dashboards | Show conversion and elapsed time by source, team and agreed stage definition |
| Integration | Connect accounts | Define which customer and invoice fields move, in which direction, and what happens after an error |
What should a practical CRM requirements brief contain?
A useful first brief does not need to specify the whole system. Start with one high-value or high-friction workflow and record seven connected elements.
1. State the business problem and desired outcome
Describe the present problem without prescribing software. Include who experiences it, how it affects work and which observable measure should improve.
For example: “Qualified enquiries wait in a shared inbox because ownership is unclear. The new process must assign an owner, make unaccepted work visible and allow managers to see elapsed time by team.”
This is more useful than “We need lead routing” because it explains the outcome and the evidence required.
2. Define the start and end of the workflow
Name the event that starts the process and the state that marks a completed outcome. Avoid beginning with “a user opens the CRM”. The real trigger may be a web enquiry, imported order, signed agreement, payment failure or change made in another system.
Agree definitions for terms such as lead, qualified enquiry, opportunity, active customer and closed case. If departments use the same word differently, record the difference rather than hiding it.
3. Record the normal path and every material exception
Map actions, decisions, handovers and waiting states. For each decision, ask:
- What information is used?
- Who or what makes the decision?
- What are the possible routes?
- Can somebody override it?
- What must be recorded?
- What happens when no action is taken?
4. Identify users, roles and access boundaries
List roles rather than individual employees. Specify which roles can view, create, edit, approve, export or delete each important type of record. Include temporary cover, external users and privileged administrators.
The National Cyber Security Centre describes least privilege as limiting the access or functionality available to different users. In practical CRM terms, access rules belong in the requirement, not in a security review after configuration.
5. Map data to a purpose
For every important field or document, record its source, purpose, owner, validation rule, sensitivity and retention need. Do not copy every field from the old CRM simply because it exists.
The Information Commissioner's Office says data protection by design and by default begins at the planning stage and continues throughout the lifecycle. Its guidance also links default design to purpose limitation and data minimisation. A CRM brief should therefore ask what personal information is necessary, who needs access and how long it is needed.
Where planned processing may create high risk for people, involve your data protection lead and assess whether a data protection impact assessment is required.
6. Describe integrations as data journeys
“Integrate with finance” is not enough. Name the source and destination, record ownership, direction of travel, frequency or trigger, matching rule and failure route. Explain what users should see when a record fails to synchronise and who resolves it.
7. Add acceptance criteria and baseline measures
Acceptance criteria turn an intention into a test. They should describe an input or starting condition, the action or event and the expected result.
For example:
Given a qualified enquiry with no assigned owner, when the team acceptance period expires, then the CRM should alert the sales manager, retain the original queue and timestamp, and show the enquiry in the overdue-work report.
Also record the current baseline where it can be measured responsibly: elapsed time, re-keying effort, incomplete records, avoidable handovers or unresolved items. The aim is to compare future performance with the starting point, not to invent a return-on-investment figure before evidence exists.
Vivato's project scoping service turns goals, constraints and dependencies into an agreed scope. For cross-functional or uncertain processes, discovery workshops can help surface the differences between how a process is described and how it operates.
How do requirements help you choose between CRM options?
Requirements provide a common test for configuration, semi-bespoke development and a bespoke build. The right choice depends on the importance of each difference, not the number of requested features.
An off-the-shelf CRM is often appropriate when the core workflow is conventional, the organisation can adopt the product's terminology and controls, and standard integrations cover the necessary data journeys. Configuration may be quicker and keeps more responsibility with an established product vendor.
A semi-bespoke approach can suit organisations that need tailored modules, interfaces, workflows or integrations around a reusable foundation. Buyers should check what is standard, what is custom and how updates will work.
A bespoke CRM becomes a stronger candidate when important workflows, relationships, permissions or integrations cannot be represented cleanly without repeated workarounds. Bespoke development also brings responsibilities: discovery, prioritisation, testing, support and future change all need active ownership.
Do not label every exception as a must-have. Classify it by frequency, operational impact, risk, value and whether the process itself could change. Some rare variations are better handled with a controlled manual route. Others carry enough commercial or governance significance to shape the system.
What should you ask CRM suppliers to demonstrate?
Give each supplier the same short scenario and ask them to show how their proposed approach handles it. Useful questions include:
- Which requirements are standard, configured, customised or newly developed?
- How does the system handle the named exception and preserve an audit trail?
- What assumptions does the estimate make about data, users and integrations?
- Which requirement creates the greatest uncertainty or technical risk?
- How will acceptance criteria be tested, and who signs them off?
- What happens when an integration is unavailable or returns conflicting data?
- How are changes assessed after scope has been agreed?
- What documentation, training and support are included after launch?
A demonstration built around your workflow is more informative than a tour of every feature. Before development, the agreed material can be developed into a detailed, testable specification. Vivato's specification development service covers system behaviour, integrations, data flows and success measures.
Frequently asked questions
Who should be involved in CRM requirements gathering?
Include the project sponsor, process owners, representative end users, IT or data colleagues and people responsible for security, privacy or compliance. Add finance or customer-service stakeholders when the workflow crosses their responsibilities. One senior voice is not a substitute for the people who perform and govern the work.
Do we need a complete specification before contacting a CRM developer?
No. A concise brief covering the problem, one representative workflow, exceptions, users, data, integrations and success criteria is enough for an initial conversation. Discovery and specification work can then resolve uncertainties before a reliable delivery commitment is made.
Should requirements describe the current process or the future process?
Document both, but keep them separate. The current-state map exposes workarounds, dependencies and baseline measures. The future-state requirement describes the outcome and controls you want. Copying the current process uncritically can reproduce its inefficiencies in a new system.
Start with one workflow, not the whole CRM
Good CRM requirements gathering creates shared understanding before it creates a long document. Choose one commercially important or operationally difficult workflow. Map its trigger, normal route, exceptions, data, permissions, integrations and evidence of success. Then use that record to challenge assumptions and compare options.
Vivato can help UK organisations turn complex CRM workflows into a clear scope and testable specification. If your team is considering an off-the-shelf, semi-bespoke or bespoke CRM, a low-pressure first step is to bring one difficult workflow to an initial conversation.
