Requirements gathering is the single most leveraged activity in a custom CRM project. Every hour invested here saves many more hours of rework, re-scoping, and retrofit later. Get it right and the rest of the build becomes an execution problem. Get it wrong and no amount of elegant code, modern framework, or delivery methodology will rescue the outcome.
This guide is written for UK business owners, operations directors, and technical leads at SMEs of 20 to 150 employees who are starting a bespoke CRM project, or who are evaluating whether a custom build is the right answer at all. It explains what requirements gathering actually is, why UK projects fail when the discovery phase is rushed, who should be in the room, how to structure a nine-step practitioner process, and which regulatory obligations must be captured before a single line of code is written. It also links to a downloadable CRM requirements template you can take straight into your first stakeholder workshop.
Last updated: April 2026. Sources include ISO/IEC/IEEE 29148, ISO/IEC 25010:2023, the BCS Practitioner Certificate in Requirements Engineering, IIBA's BABOK v3, the Project Management Institute's Pulse of the Profession 2024, the Standish Group CHAOS 2020 report, Boehm (1981) and NASA cost-of-defect research, and primary UK regulatory sources including the FCA, ICO, SRA, NHS Digital, and legislation.gov.uk.
What is CRM requirements gathering?
CRM requirements gathering is the structured process of identifying, documenting, validating, and prioritising the functional behaviours, non-functional qualities, regulatory obligations, and integration constraints that a CRM system must satisfy for a specific business. It produces a written specification that the build team, the business, and the compliance function can all sign against before design or development begins.
The international standard for this work is ISO/IEC/IEEE 29148:2018, which defines requirements engineering as "an interdisciplinary function that mediates between the domains of the acquirer and supplier or developer to establish and maintain the requirements to be met by the system." The UK professional equivalent is the BCS Practitioner Certificate in Requirements Engineering, which defines it as "the process of identifying, documenting, as well as managing the needs and constraints of stakeholders for a system or product."
In plain English, it is the discipline of working out what the CRM actually has to do, for whom, under what constraints, before building it.
Why most UK CRM projects fail at the requirements stage
The data is uncomfortable. The Project Management Institute's Pulse of the Profession 2024 found that 47% of unsuccessful projects fail to meet their goals due to inaccurate requirements management. The final Standish Group CHAOS Report 2020 found that only 31% of IT projects succeeded outright, with 50% challenged and 19% outright failures, and that the single most reliable predictor of success across every edition since 1994 has been meaningful user involvement.
Most striking of all is the Boehm cost curve. Barry Boehm's original 1981 research, replicated by NASA and by Capers Jones through 2012, established that a defect introduced at the requirements stage is roughly 100 to 200 times more expensive to fix after the system is in production than it is to fix during requirements gathering itself. The absolute figures have aged, but every subsequent replication has confirmed the direction. Requirements defects are by a wide margin the most expensive kind of defect to let through.
The pattern in UK CRM projects specifically is consistent with those numbers. Projects run into trouble when:
- The sponsor assumes the incumbent CRM vendor's standard workflow is "near enough" and skips the discovery phase to save weeks
- Sales, marketing, operations, and compliance each describe their own needs in isolation and no one reconciles them
- Non-functional requirements (performance, security, accessibility, auditability) are treated as a sprint 12 problem rather than a sprint zero input
- UK regulatory obligations are captured as a policy paragraph rather than as structured data fields and workflow states
- Requirements are written in ambiguous language ("the system should be user-friendly", "reporting must be fast") with no measurable fit criteria
None of these failures are caused by bad engineering. They are caused by the business not yet knowing what it is buying when the build begins.
Who should be involved in CRM requirements gathering
A CRM touches more of a business than almost any other internal system. Gathering its requirements from one department alone is the most common single mistake in the discipline. The minimum stakeholder map for a UK SME CRM project looks like this:
- Executive sponsor: accountable for budget, scope decisions, and escalations. Usually the managing director, COO, or commercial director.
- Process owners: the people who own the sales, marketing, service, and operations workflows the CRM will support. Each should nominate a single named representative.
- End users: a representative sample from each role that will use the system day to day, including the ones who complain loudest about the current system.
- IT and data lead: responsible for integrations, hosting, data model, and the firm's wider architecture.
- Compliance officer or DPO: in any regulated sector (financial services, legal, healthcare, recruitment), and in any business handling personal data at scale, the data protection officer is a mandatory participant.
- Finance representative: required whenever the CRM touches pipeline forecasting, billing, commissions, or management reporting.
- External advisers where relevant: for example, a bespoke CRM development partner acting as facilitator, or sector-specific legal counsel in an FCA or SRA-regulated firm.
The IIBA BABOK v3 formally separates elicitation techniques suited to consensus-building (workshops, focus groups) from those suited to individual discovery (interviews, observation). Both are needed. Workshops surface disagreement; 1:1 interviews surface the things people will not say in front of their manager.
How to gather CRM requirements in nine practical steps
The process below is distilled from ISO/IEC/IEEE 29148, the BCS requirements engineering syllabus, BABOK v3, and BespokeCRMs's own discovery work with UK SMEs in regulated sectors. It is deliberately practitioner-focused, not theoretical.
Step 1. Audit the current workflow, end to end
Before talking about the future system, map how work actually gets done today. Walk the process from the first customer touchpoint to invoice reconciliation. Note every system, spreadsheet, shared inbox, and sticky note in play. Capture the workarounds, because workarounds are requirements in disguise.
Step 2. Map the customer lifecycle against business outcomes
Pin the customer journey to a wall. Mark each stage with the business outcome it produces (lead qualified, opportunity created, proposal sent, contract signed, service delivered, renewal won). The CRM exists to support these outcomes, not to replicate department silos.
Step 3. Run structured stakeholder interviews
Conduct 45 to 60 minute 1:1 interviews with every process owner and a representative sample of end users. Use open questions first ("walk me through a typical week"), then probing questions ("what would you change if you could"), then the 5 whys technique to trace stated requirements back to the business need they serve. Sakichi Toyoda's original 5 whys method predates root cause analysis and is still the most effective way to separate genuine requirements from preference.
Step 4. Shadow end users in context
Interview data is necessary but not sufficient. Contextual inquiry, developed by Hugh Beyer and Karen Holtzblatt, puts the analyst next to the user for a whole task, observing without interrupting, then running a 60 to 90 minute interpretation session afterwards. This surfaces habitual, invisible behaviours that users genuinely cannot describe from memory.
Step 5. Document data sources and quality
A CRM project is also a data project. Inventory every existing source of customer data, contact data, product data, and transaction data. Record volume, format, ownership, quality level, and whether the source will be migrated, integrated, or retired. Missing this step is how CRM projects discover in month five that two million legacy records need cleansing before go-live.
Step 6. Define the integration surface
Every modern CRM lives inside an ecosystem. Document each upstream and downstream system the CRM must connect to: telephony, email, finance, ERP, marketing automation, e-signature, document management, accounting, payment providers, and sector-specific tools. For each, capture direction (read, write, both), sync method (real-time, batch, event-driven), and data contract. This is often the single largest technical risk in a bespoke build.
Step 7. Capture regulatory and non-functional requirements
Functional requirements describe what the system must do. Non-functional requirements describe how well it must do it, and regulatory obligations sit squarely in this category. Use ISO/IEC 25010:2023 as the taxonomy. The standard defines nine quality characteristics: functional suitability, reliability, performance efficiency, interaction capability, security, compatibility, flexibility, maintainability, and safety. Every non-functional requirement should map to one of these nine and include a measurable fit criterion. More on UK regulatory obligations in the next section.
Step 8. Prioritise with MoSCoW against a fixed timebox
MoSCoW prioritisation was created by Dai Clegg at Oracle UK in 1994 and formalised in the DSDM Agile framework now maintained by the Agile Business Consortium. It separates requirements into Must have, Should have, Could have, and Won't have this time. Critically, it only works when paired with a fixed timebox and a total cost ceiling. Without those, every requirement drifts upward into the Must column. A useful rule of thumb is to keep Must below 60% of total effort.
Step 9. Validate with a throwaway prototype or walkthrough
The cheapest requirements defect is the one caught before build. Wireframe the top three workflows, walk them through with stakeholders, and iterate the requirements document before any production code is written. The Jeff Patton user story mapping method explicitly treats this as "building shared understanding", not gathering written requirements. A prototype surfaces in ten minutes the misalignment a 40-page document would hide for three months.
Functional versus non-functional requirements
Most CRM requirements documents are heavy on functional detail and dangerously light on non-functional detail. Both categories are required, and ISO/IEC 25010:2023 gives a defensible structure for the non-functional side.
| Dimension | Functional requirements | Non-functional requirements |
|---|---|---|
| What they describe | What the system does | How well it does it |
| Written as | Features, user stories, business rules | Measurable quality attributes with fit criteria |
| Example | "The system shall create a new opportunity when a qualified lead is converted" | "Lead conversion shall complete in under 2 seconds at the 95th percentile under 50 concurrent users" |
| Standard taxonomy | Job-to-be-done, user story, use case | ISO 25010: reliability, performance, security, interaction capability, compatibility, flexibility, maintainability, safety |
| Ownership at capture | Process owners and end users | IT, security, compliance, DPO |
| When they bite if missed | Immediately (feature gap visible on day one) | Months after launch (performance degrades, audit fails, incident response breaks down) |
| Typical CRM examples | Pipeline stages, lead scoring, email templates, reporting fields | 99.9% business-hours availability, UK data residency, WCAG 2.2 AA accessibility, 7-year audit retention |
A reliable signal that a CRM requirements document is incomplete is the absence of fit criteria for non-functional requirements. "The system shall be user-friendly" is not a requirement; it is an aspiration. "The primary pipeline view shall load within 1.5 seconds for 95% of page loads during business hours with 100 concurrent users" is a requirement that can be tested, accepted, or rejected.
Writing user stories and acceptance criteria
Once requirements are captured, they should be expressed in a format the build team can implement and the business can accept. The standard format for functional requirements is the user story, typically written as "as a [role], I want to [action], so that [outcome]", paired with explicit Given-When-Then acceptance criteria. The Jeff Patton user story mapping technique is the most widely used method for arranging stories into a coherent backbone and release slices.
A well-formed CRM user story example:
As an operations manager at a UK recruitment agency, I want the CRM to flag candidate right-to-work documents that expire within 30 days, so that placements are not made against expired documentation in breach of the Conduct of Employment Agencies Regulations 2003.
Acceptance criteria:
- Given a candidate record with a right-to-work expiry date within the next 30 days,
- When the user opens the candidate dashboard,
- Then a visible warning indicator appears against the record, and
- When a placement is created against that candidate,
- Then the system blocks submission and surfaces the exact expiry date and regulatory reference.
This level of specificity is the goal. Every ambiguous word removed at the requirements stage is a defect that never makes it into production.
UK regulatory requirements to capture before the first sprint
This is the section that most generic requirements templates miss entirely, and the one that is most likely to derail a UK CRM project if left until the end. The following obligations are specific to the UK and must be captured as structured requirements, not footnotes.
UK GDPR and the Data Protection Act 2018
Article 5 of the UK GDPR sets out seven data protection principles, including data minimisation, purpose limitation, storage limitation, and accountability. Each of these translates into concrete CRM design decisions: field-level purpose tagging, lawful basis stored as structured metadata, retention schedules attached to record types, and automated deletion or pseudonymisation at the end of the retention period. Article 25 requires data protection by design and by default, which the ICO's data protection by design guidance is explicit about: the controls must be built in from the start, not bolted on later. Article 30 requires organisations to maintain a Record of Processing Activities, which any bespoke CRM should be able to export on demand.
Financial services: FCA Consumer Duty and SYSC
For FCA-regulated firms, the Consumer Duty (PS22/9) has been in force for open products since 31 July 2023 and for closed products since 31 July 2024. Firms must evidence outcomes for customers, including vulnerability monitoring, price and value, and consumer understanding. The CRM must capture these as structured fields and produce management information for the annual governing body report. SYSC record-keeping requires records to be accessible for at least five years, with some obligations extending to seven. Our CRM for UK financial advisers guide covers the Consumer Duty specification in detail.
Legal: SRA Standards and Regulations 2019
Solicitors regulated by the Solicitors Regulation Authority operate under the SRA Standards and Regulations 2019. Conflict-of-interest checking must happen before matter acceptance. Access controls must preserve client confidentiality (Rule 6). Accounts Rules require records to be retained for at least 6 years and reconciliations at least every 5 weeks. All of these become requirements the CRM must support directly, not workarounds.
Healthcare: NHS Data Security and Protection Toolkit
NHS-connected CRMs must meet the Data Security and Protection Toolkit (DSPT) requirements, including mandatory role-based access control, removal of access when no longer needed, comprehensive audit trails, and independent audit for Category 1 and Category 2 organisations.
Recruitment: Conduct of Employment Agencies Regulations 2003
Recruitment CRMs are governed by the Conduct of Employment Agencies and Employment Businesses Regulations 2003, which specify mandatory candidate and client record fields, retention of at least 12 months, and criminal liability for failures. See our CRM for UK recruitment agencies guide for the full requirements translation.
Accessibility: WCAG 2.2 AA and EN 301 549
Any CRM used by employees in roles subject to the Equality Act 2010 should meet WCAG 2.2 AA, which became the current standard in October 2023 and is incorporated into the European harmonised standard EN 301 549. This is a non-functional requirement with a measurable fit criterion.
Every one of these obligations must be captured as structured requirements in the specification before the build starts. Regulatory context is general guidance; always consult qualified legal or compliance advice specific to your sector before making binding design decisions.
What a CRM requirements document should contain
A defensible CRM requirements document has eleven sections at minimum. Each should be present and signed by the executive sponsor before design or build begins.
- Business context and objectives: why the CRM is being built, what business outcomes it supports, how success will be measured.
- Stakeholder map: named individuals by role, decision-making authority, availability for reviews.
- Current state: workflow maps, system inventory, data sources, pain points.
- Customer lifecycle: the journey the CRM must support, mapped to outcomes.
- Functional requirements: user stories with Given-When-Then acceptance criteria, organised by workflow and prioritised with MoSCoW.
- Non-functional requirements: mapped to ISO/IEC 25010:2023 categories with measurable fit criteria.
- Regulatory obligations: structured requirements for every applicable UK regulation, with primary source references.
- Integration surface: upstream and downstream systems, data contracts, sync methods.
- Data migration plan: sources, volumes, mapping, quality, cutover approach.
- Constraints and assumptions: budget ceiling, fixed timebox, technology constraints, dependencies.
- Glossary: agreed definitions for every business-specific term ("lead", "opportunity", "customer", "active client").
Starting from a blank page is slow and error-prone. A practitioner template with the structure above, pre-populated UK regulatory annexes, and MoSCoW prioritisation columns is the fastest way to run a first discovery workshop. Our free CRM requirements template is built around exactly this structure and is free to download.
Common CRM requirements-gathering mistakes and how to avoid them
Five mistakes account for most failed discovery phases.
Gold plating. The build team adds unapproved extras that seemed like a good idea. Fix: every change to scope passes through the MoSCoW list and the executive sponsor.
Scope creep. Stakeholders request additions after the requirements are baselined. Fix: explicit change-control process, a Won't Have column that is enforced, and a fixed timebox with a total cost ceiling.
Skipping non-functional requirements. Performance, accessibility, retention, and availability are deferred to sprint 12 and never arrive. Fix: ISO 25010 checklist in every requirements document, signed by IT and compliance.
Not involving end users. The system is designed for the org chart, not for the people who will use it. Fix: at least one 1:1 interview and one shadowing session per distinct user role, before any requirements are written.
Ambiguous weasel words. "User-friendly", "fast", "robust", "scalable" make the document feel complete but cannot be tested, accepted, or rejected. Fix: replace every instance with a measurable fit criterion before sign-off.
From requirements to build: what happens next
A well-written requirements document is not the end of discovery. It is the input to a structured design and build phase, and it is the artefact the business uses to hold the delivery team accountable. At BespokeCRMs, the discovery workshop that produces this document is a paid engagement (typically £2,500 to £4,000 depending on scope) and sits between initial conversation and any commitment to build. The deliverable is the document itself, which belongs to the client regardless of whether they choose BespokeCRMs for the build.
For the broader delivery process, see our bespoke CRM development process guide, which covers what happens from requirements sign-off to production launch. For the wider build-or-buy conversation, the definitive UK build or buy guide walks through the economics. If your existing CRM is already showing strain, the 7 signs your business has outgrown its off-the-shelf CRM is a useful self-assessment before you commit to a discovery workshop.
Frequently asked questions
What is CRM requirements gathering?
CRM requirements gathering is the structured process of identifying, documenting, validating, and prioritising everything a CRM system must do, how well it must do it, and which regulatory obligations it must meet, before design or build begins. It combines stakeholder interviews, process observation, data audit, integration mapping, and regulatory analysis into a single signed specification. Done well, it removes almost all of the expensive rework that causes CRM projects to overrun.
How long does CRM requirements gathering take for a UK SME?
For a UK SME of 20 to 150 employees, a properly scoped discovery phase typically runs 4 to 8 weeks. That includes 1 to 2 weeks of stakeholder interviews and observation, 1 to 2 weeks of data and integration audit, 1 to 2 weeks of workshop facilitation and prototyping, and 1 week for documentation and sign-off. Projects that compress this phase below 3 weeks almost always discover the missing requirements later, at a much higher cost.
Who should be involved in CRM requirements gathering?
At minimum: an executive sponsor, process owners for each workflow the CRM supports, a representative sample of end users, an IT and data lead, a compliance officer or DPO in any regulated sector, a finance representative, and external facilitation where useful. A single department view is the most common cause of misaligned CRM requirements.
What should a CRM requirements document include?
Eleven sections: business context, stakeholder map, current state, customer lifecycle, functional requirements, non-functional requirements mapped to ISO/IEC 25010:2023, regulatory obligations, integration surface, data migration plan, constraints and assumptions, and glossary. Every requirement should have either an acceptance criterion or a measurable fit criterion.
What is the difference between functional and non-functional CRM requirements?
Functional requirements describe what the CRM does (creates a lead, moves an opportunity, generates a report). Non-functional requirements describe how well it does it (page load time, availability, accessibility, security, retention). Non-functional requirements are usually where UK regulatory obligations live, and they are by far the most commonly missed category in first-draft CRM requirements documents.
How do you prioritise CRM requirements?
Use MoSCoW (Must have, Should have, Could have, Won't have this time) paired with a fixed timebox and a total cost ceiling. MoSCoW only works with those two constraints; without them every requirement drifts into the Must column. A workable rule of thumb is to keep Must below 60% of total effort, reserving headroom for discovery during the build.
How much does a CRM requirements gathering workshop cost in the UK?
A structured discovery workshop for a UK SME typically costs £2,500 to £4,000 depending on scope, number of stakeholders, and sector regulatory complexity. The output is a written requirements document the business owns and can take to any development partner. See our bespoke CRM cost guide for the wider pricing picture.
Is CRM requirements gathering the same as a feasibility study?
No. Feasibility studies ask whether a CRM project should happen at all, against a business case. Requirements gathering assumes the decision to proceed has already been taken and captures what the system must do. In practice, a short feasibility assessment is often embedded in the opening of the discovery workshop, but they are different deliverables with different audiences.
Starting your CRM requirements work
The economic case for investing in requirements gathering is clearer than any other activity in a CRM project. The PMI data says nearly half of failed projects trace their failure here. The Boehm cost curve says fixing requirements defects after launch is up to 200 times more expensive than fixing them during discovery. The Standish CHAOS data says user involvement is the single most reliable predictor of project success. None of this is controversial, and yet the phase is still the first thing compressed when budgets tighten.
BespokeCRMs runs structured CRM discovery workshops for UK SMEs in financial services, legal, healthcare, recruitment, property, and other regulated sectors. The output is a written requirements document, owned by you, that meets the structure described in this article. You can take it to any development partner afterwards.
To start, download our free CRM requirements template and use it to structure your first stakeholder workshop. When you are ready for a facilitated discovery engagement, book a discovery call with our team or request a CRM consultation workshop. We will send a short pre-call questionnaire so the conversation focuses on your specific workflow, regulatory priorities, and delivery timeline.
The information in this article is general guidance on UK regulation and requirements engineering practice. It is not a substitute for qualified legal, compliance, or business analysis advice specific to your firm's circumstances. Consult appropriate qualified professionals before making decisions with regulatory or contractual implications.