Over the years, we have heard various terms that characterize a set of documented CRM requirements.
Terms include a request for proposal, high-level requirements, blueprint, functional specification, specification plan, agile requirements, and more.
Labels aside, there are several levels of depth of CRM requirements. The deeper your team defines requirements as part of your CRM selection process, the more successful your CRM implementation will be.
1. Feature Requirements
A list of required system features has a format similar to the following, a format that can often be found in requests for proposals (RFPs). Feature requirements do not describe any specific behaviors.
They merely indicate whether the CRM system has some yet-to-be-specified degree of functionality in an area. Here’s an example of feature requirements.
The CRM system must support the following:
- Contact management
- Outlook integration
- Google Workspace integration
- Account management
- Opportunity Management
- Reports
- Dashboards
- Generative AI
- Case management
- Knowledge base
- Chat
- Field service
- Workflow
- Escalations
- Email marketing integration
While creating a list of required features is a good starting point, it does not give CRM vendors enough information to tailor a demonstration to your company’s business requirements. In addition, it does not offer service providers enough data to provide meaningful estimates.
2. Business Requirements
A high-level business requirements document analyzes current pain points and possible business solutions. It does not cover CRM product features per se. This document is usually derived from stakeholder and end-user interviews. The document can include problem/solution pairings and current state/desired future state pairings.
Ideally, the business requirements document should have an associated slide deck that can be used in a workshop to present and validate findings.
While business requirements are generally documented by someone who is a business analyst, some CRM experience can be helpful for the interview process and the assembling of interview information.
A general knowledge of what other companies have done to solve business issues and what’s realistic to expect from a CRM solution can help define business requirements.
3. Non-Functional Requirements
I have to admit that this requirements label is new to us. I discovered this label while reading Wikipedia’s definition of “functional requirements.” According to the Wikipedia article, “a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.”
If we apply this label and definition to CRM, non-functional requirements can include criteria/requirement pairings such as:
- Availability: 99.9% uptime
- Scalability: Easily scalable to over 5,000 users and over 1,000,000 records
- Backups: We should be able to download full database backups daily
- Disaster Recovery: Redundant data centers with less than one hour of failover time
- Location: Our information can only be in data centers within our country’s borders
- Cost: The system must cost no more than $X per month
There is value in separating non-functional requirements such as these from functional requirements.
“We enlisted CRM Switch to lead a critical CRM technology initiative that posed complex requirements and involved numerous stakeholders. From the outset, Daryn demonstrated the skill to connect with people at all levels of the organization, swiftly earning their respect and becoming an indispensable part of our team.
Their contributions have left a lasting impact on our company – we are about to re-engage them for services.”
Richard Wilhelm
Global Director IT, Performance Technologies
Modine Manufacturing Company
4. Functional Requirements
The functional requirements document takes the amount of detail to the next level.
Generally, functional requirements are expressed in the form “system must allow for doing this specific thing.”
- Why the requirement is needed (what the current problem is)
- A description of the required behavior
- Details of a use case
- Business results of addressing the requirement
We’ve developed a CRM functional requirements example document to get you jump-started.
5. System Design
Once again, citing a Wikipedia article, “the plan for implementing functional requirements is detailed in the system design.”
System design is, therefore, the process of defining and developing systems to satisfy specified requirements of the stakeholders and system users.
Also known as a blueprint or a specification, system design is the actual design of how the system should work. In the CRM world, this includes details like custom field names, data types, and picklist values. It provides workflow rules and data migration maps. Spreadsheets and flowcharting tools become a part of the document set.
It’s possible to combine several of the above levels. Functional requirements and system design can be part of the same document for smaller organizations.
