If you are currently trying to separate your business requirements from your functional requirements on a CRM project, you are in exactly the right place. The distinction between business requirements vs functional requirements becomes most visible on CRM implementations, not because the projects are complicated, but because the two types collide so often and so publicly. Sales managers want an outcome. IT wants a specification. And the BA is in the middle trying to make both things true at the same time. This article shows you how to do that, using a real project, with the friction left in.
Before I get into the worked example, a quick framing note. A business requirement describes what the organisation needs to achieve, written in language a non-technical stakeholder would recognise as their own. A functional requirement describes what the system must do to deliver that outcome. If you want the conceptual underpinning in more depth, the article on business vs functional requirements: key differences and practical examples covers that well. What I want to do here is show you what this separation looks like under real project conditions.
The Project: A Professional Services Organisation Replacing Spreadsheets
The project I am drawing on involved Organisation B, a mid-sized professional services firm that had grown its sales team from six people to twenty-two over three years. The contact management spreadsheet they had relied on was collapsing. Duplicate records were everywhere, pipeline visibility was non-existent, and managers had no reliable way to see what their team was actually doing day to day. A budget had been approved for a commercial off-the-shelf CRM platform, and I was brought in to define requirements ahead of vendor selection.
The first thing I did was run workshops with the sales director, three regional managers, and a cross-section of frontline sales staff. My goal in those first sessions was simple: capture what the organisation needed to achieve, not what the system should do. Those are different conversations, and conflating them early is one of the most common mistakes I see on CRM projects.
Business Requirements: What the Organisation Actually Needed
After the initial workshops, four core business requirements were clear. Here is how I expressed them in the requirements document:
- BR01: Pipeline visibility. The organisation must have a single consolidated view of all active sales opportunities so that managers can forecast revenue accurately and identify at-risk deals before they are lost.
- BR02: Elimination of duplicate records. The organisation must maintain a single accurate record for each client and prospect so that staff are not working from conflicting information.
- BR03: Activity tracking across the sales team. Managers must be able to see the activity history for each team member, including calls, emails, and meetings, so that performance can be assessed and coaching conversations are grounded in real data.
- BR04: Faster onboarding of new sales staff. New team members must be able to access complete client history and current opportunity status within their first week so that ramp-up time is reduced and client relationships are not disrupted during handovers.
Notice what these do not contain. No field names, no user roles, no system behaviour. They describe outcomes the business needs, written in language the sales director used in the workshops.
Functional Requirements Derived from Those Business Needs
Once the business requirements were agreed and signed off, I moved into the second pass: translating each one into functional requirements. These are the statements that describe what the CRM system must be capable of doing.
| Business Requirement | Functional Requirement |
|---|---|
| BR01: Pipeline visibility | FR01: The system shall provide a pipeline view filterable by stage, owner, region, and expected close date.
FR02: The system shall allow managers to view the combined pipeline value for their direct reports. |
| BR02: No duplicate records | FR03: The system shall detect potential duplicate contacts based on name, email address, and phone number during record creation and prompt the user to merge or proceed.
FR04: The system shall provide an administrator function to identify and merge duplicate records in bulk. |
| BR03: Activity tracking | FR05: The system shall log all outbound calls, emails sent from within the platform, and meeting records against the relevant contact and opportunity.
FR06: Managers shall be able to access an activity summary report for each team member showing volume and type of activity by date range. |
| BR04: Faster onboarding | FR07: The system shall maintain a complete chronological history of all interactions, notes, and documents for each contact and opportunity, visible to all users with appropriate access.
FR08: When a sales opportunity is reassigned, the new owner shall receive an automated notification including a link to the full opportunity record. |
Where the Friction Hit: The Sales Manager Who Wanted Features, Not Outcomes
About halfway through the requirements workshops, the regional sales manager for the southern territory started pushing back on the process. He had been through a CRM rollout at a previous employer and was convinced the right approach was to write requirements as a feature list: lead scoring, email integration, mobile app, territory management. Every time I tried to anchor a conversation in business outcomes, he redirected it toward the solution.
“We need lead scoring” became his answer to almost every question I asked about what the business actually needed. When I asked why lead scoring was important, he said it was industry standard. I pushed harder. What eventually came out was that his team was wasting time chasing contacts who had shown very little genuine interest, while warmer prospects were going cold. That underlying problem became BR05: the organisation must be able to prioritise sales effort by directing time toward prospects with the highest likelihood of conversion.
Lead scoring was one possible functional response to that requirement. But so was a simple qualification status field, or a manual rating system. By capturing the business requirement first, we kept the vendor options open rather than locking the project into a specific feature before we had even seen a demonstration. The sales manager was not pleased initially. He felt the process was slowing things down. But when we reached vendor evaluation, having a clearly articulated BR05 turned out to be exactly what we needed. One vendor offered AI-driven lead scoring. Another offered a configurable rating field at a lower licence cost. Because we had a clear business requirement, we could assess both options against the same need rather than getting drawn into feature comparisons. You can read more about structuring that kind of evaluation in the article on solution assessment criteria.
Common Mistakes I See on CRM Requirements Projects
- Writing functional requirements before business requirements are agreed. The team starts discussing fields and workflows before anyone has confirmed what outcome the system is meant to deliver, which means there is nothing to trace requirements back to when the solution changes.
- Letting vendor demos drive the requirements. CRM vendors give impressive demonstrations, and stakeholders fall in love with features they had not asked for. A clear set of agreed business requirements gives you something to point to when that happens.
- Writing business requirements that are actually functional requirements in disguise. “The system must send an automated welcome email when a new lead is created” is a functional requirement. The business requirement underneath it is that every new prospect must receive timely and consistent initial outreach. That distinction matters when the solution design changes later.
- Skipping traceability entirely. On one CRM project I worked on, functional requirements were handed to the development team with no link back to the business requirements they came from. Halfway through the build, a senior stakeholder challenged the scope of the email notification functionality. Because there was no traceability, nobody could quickly demonstrate why that requirement existed. Two weeks of work stalled while people searched through workshop notes. A requirements traceability matrix would have resolved that in minutes.
A Three-Pass Structure for CRM Requirements
The approach I now use on every CRM engagement is to work in three deliberate passes. It takes more discipline upfront, but it pays back significantly during vendor evaluation and scope management.
Pass One: Business Requirements Only
Run workshops focused entirely on outcomes. Do not let the conversation stray into system features. Ask what problem is being solved, who is affected, and what success looks like in measurable terms. If a stakeholder mentions a feature, note it and ask what business problem that feature is intended to solve. Keep redirecting until you have the underlying need.
Pass Two: Functional Requirements Derived from Business Requirements
Take each agreed business requirement and work through what the system must be capable of doing to satisfy it. Write these in a consistent format tied to a specific actor: “The system shall allow [role] to [do something] so that [outcome].” Every functional requirement should have a clear parent. If it does not, it either belongs to a business requirement you have not captured yet, or it is scope creep.
Pass Three: Review and Validate
Check that every functional requirement has a parent business requirement. Check that every business requirement has at least one functional requirement addressing it. If either condition is not met, something has been missed or something has drifted in without justification. This structure also makes scope conversations straightforward. When a stakeholder asks whether you can add a customer portal, you simply ask: which business requirement does that address? If the answer is none, it is a new scope item, not a refinement of existing requirements. The business requirements vs functional requirements article has further worked examples if you want to see this pattern applied across different project types.
The reason this process works on CRM projects specifically is that CRM platforms are feature-rich by design, and vendors are motivated to show you everything they can do. Without a grounded set of business requirements to return to, it is very easy for a project to accumulate functional requirements that have no real organisational need behind them, which leads to over-engineered solutions, bloated licences, and stakeholders who cannot explain six months later why certain things were built. Getting the business requirement right first is not a bureaucratic step. It is the thing that keeps the whole project honest.
Frequently asked questions
What is the difference between business requirements and functional requirements in a CRM project?
A business requirement describes what the organisation needs to achieve, such as better pipeline visibility or faster onboarding of new staff. A functional requirement describes what the CRM system must do to deliver that outcome, such as a filterable pipeline view or an automated reassignment notification. Business requirements come first, and functional requirements are derived from them.
Can you give me an example of a business requirement for a CRM?
A typical CRM business requirement might read: the organisation must maintain a single accurate record for each client and prospect so that staff are not working from conflicting information. It is outcome-focused, contains no system-specific language, and is written in terms a non-technical stakeholder would recognise. The system detail comes later, in the functional requirements.
Can you give me an example of a functional requirement for a CRM?
A CRM functional requirement might read: the system shall detect potential duplicate contacts based on name, email address, and phone number during record creation and prompt the user to merge or proceed. This specifies exactly what the system must do and is directly traceable to the business requirement for accurate, deduplicated contact records.
Why do business requirements need to be written before functional requirements?
Business requirements establish what outcome is needed before anyone decides how to achieve it. Without them, functional requirements get written around assumed solutions, which makes it difficult to evaluate vendors fairly, manage scope, or trace decisions back to genuine organisational needs. When requirements are challenged later in the project, having the business requirement as an anchor resolves disputes quickly.
How do I stop stakeholders from jumping straight to features when defining CRM requirements?
Ask why the feature matters and keep redirecting the conversation to outcomes until you have the underlying need captured. When a stakeholder says they need lead scoring, ask what business problem that solves, and keep pushing until they describe the outcome in their own terms. Only then turn it into a functional requirement.
Try Ash, Your Virtual BA
If you are mid-way through a CRM requirements engagement and trying to draft your business requirements, translate them into functional requirements, or check whether your existing requirements hold up under scrutiny, Ash can work through that with you directly. Ash is a virtual BA assistant that understands the difference between business and functional requirements, can generate draft requirement statements based on what you tell it about your project, and will flag gaps before they become delivery problems. Try Ash Virtual BA and see how quickly you can move from stakeholder notes to a requirements set that actually holds together.
Further reading
- Beyond Functionality: The Critical Role of Non-Functional Requirements | Exclusive Articles for IIBA Members
- Effective requirements management
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.