Begin with observable problems
Speak to sales, customer service, administration and the person who will maintain the system. Each role should bring a concrete case: an enquiry without an owner, a proposal with an unclear status or a customer whose latest agreement exists only in a personal inbox.
Describe the current workflow and its consequences first. Then describe the desired situation. “Better visibility” becomes a requirement such as: a colleague covering an opportunity can find the latest confirmed agreement, open questions and the person responsible for the next step.
Name a business owner for each problem. That person decides whether the proposed behaviour meets the need. The project lead coordinates the requirements; they do not need to answer every business question alone.
If you intend to measure an improvement, record the starting position before implementation. One measure could be the number of open opportunities without a next action. Define the method and target within your business instead of placing an unsupported improvement claim in the specification.
Separate organisations, people and opportunities
The data model describes the types of information that exist and how they relate. This is particularly important in a CRM: an organisation can have several contacts and several parallel projects. A person may change company or role over time.
Use a real example from your business, anonymised where necessary. Test the relationships between organisation, contact, opportunity, activity and document. Establish whether an activity belongs to the wider customer relationship or to one specific proposal.
- Organisation
- Example business · the shared reference for contacts and opportunities.
- Contacts
- Person A coordinates the work; person B decides on the budget.
- Opportunity
- New service package · its own scope, status and next action.
- Activity and document
- A follow-up question and proposal version belong to this opportunity.
Record which relationships are mandatory and which are optional. An initial contact may not yet have a known company. An approved opportunity may require an unambiguous organisation reference. Apply these rules at the appropriate process stage.
For existing data, check whether the required relationships can be exported at all. Preparing a CRM data migration reveals which identifiers, histories and associations need to be preserved.
Make each requirement testable
A requirement should describe one coherent need. Give it a stable identifier and record the role, trigger, desired behaviour and business purpose. Add an acceptance criterion that can be demonstrated or tested.
Alongside the normal case, the criterion often needs a failure case. What happens when required information is missing or someone does not have the necessary permission? A success message alone does not test these boundaries.
- CRM-07 · Starting point
- Open opportunities need a visible next action.
- Required behaviour
- Sales can move an opportunity to “Proposal under review” only when a next action and an owner have been entered.
- Positive test
- With both values present, the stage change succeeds; the information remains visible in the overview.
- Negative test
- Without an owner, the previous stage remains; the missing information is identified.
Then prioritise. A must-have blocks approval when it is not met. A should-have is important but may allow an explicitly accepted temporary solution. A could-have can improve the selection without displacing a suitable core workflow. Use these definitions consistently throughout the catalogue.
Not every convenience is a must-have. For disputed items, ask which specific task cannot be completed without the function. Record the decision and reasoning instead of importing contradictory priorities from different departments unchanged.
Describe data sources, access and operations
Functional requirements state what the application must do. The specification also needs constraints for access, migration, integrations and support. Make these concrete enough for providers to identify open questions.
| Area | Clarify in the specification | Possible evidence |
|---|---|---|
| Access | Which role may read, edit, export or assign records? | Test with separate user roles |
| History | Which business changes must remain traceable? | Example change with the required display |
| Integrations | Which system owns each field, and in which direction do updates flow? | Example transfer including a failure case |
| Migration | Which objects, attachments and relationships are in scope? | Sample export and test import |
| Operations | Who owns access, backups, recovery, updates and support? | Documented responsibilities and agreed services |
| Exit | Which data and relationships can be exported, and in which format? | Readable sample export |
Record known working conditions: mobile use, cover during absence, several teams or limited connectivity. When response times or data volumes affect the decision, specify a test scenario and an agreed target. A general requirement to “be fast” cannot be compared consistently.
Define privacy and security requirements with the responsible people in your organisation. The table does not replace an assessment of the specific processing purpose and intended solution. A location or a single security feature does not answer those questions by itself.
Complete the template and compare vendor responses
The CRM requirements CSV template contains example requirements and blank rows. An editable Markdown template provides space for context, scope and decisions. Both are available without a form; the examples are starting points rather than a complete specification for your business.
Start with one customer process. Add its requirements, assign priorities and identify who will approve them. Remove sample rows that do not apply. A requirement remains open until its meaning and acceptance criteria are clear.
Ask providers to answer each item with an implementation type: already available, configurable, additional development or not supported. Have them identify dependencies, one-off work and recurring costs separately. A broad “possible” does not show what will actually be delivered.
Take shortlisted options through the same demonstration scenarios. Record observed behaviour and outstanding evidence beside the provider response. Check must-have requirements first; a large number of optional functions does not automatically compensate for an unresolved core problem.
When requirements change, retain their identifiers and change history. This makes it clear why a proposal differs from an earlier version. You can then assess whether a standard product is sufficient or whether custom CRM software makes sense for particular workflows.