CRM requirements template: what to write before you buy or build a CRM

A good CRM requirements document is about fifteen pages long and describes how your business actually sells: who uses the system, what stages a deal goes through, which data moves between which tools, and what is essential versus what can wait. Written well, the same document lets you compare off-the-shelf CRMs and get a quote for a custom build, which is exactly what you need to choose between them.

Most CRM requirements templates you will find are published by CRM vendors or software comparison sites. They list catalogue features (pipeline, email sync, dashboards) and steer you towards a product. This template starts from the other end: your sales process, your data, your systems. It ends with a simple grid to tell whether your needs call for configuration or for development.

What the document is for

Write it for three readers at once:

• vendors and developers, who must be able to price the same scope, so their answers can be compared line by line;
• your own company: leadership wants forecasting, reps want fast data entry, finance wants the signed proposal. The document settles those trade-offs before the project, not halfway through;
• your future self on acceptance day: every requirement should be something you can check when the system is delivered.

If a paragraph serves none of these readers, cut it. For the general method behind any requirements document (sections, priorities, testable wording), see our guide on writing a software requirements document. This article covers what is specific to a CRM.

The template in 11 sections

The sections below cover the places where CRM requirements usually go wrong.

Goals you can measure

"Improve customer relationships" cannot be tested. Write goals like these instead:

• follow up every meeting within two business days, for every deal;
• stop retyping won deals into the ERP or invoicing system;
• know the renewal rate of annual contracts each month, without a spreadsheet in between;
• show reps the full account history before a visit: orders, overdue invoices, open support tickets.

Three to five goals are enough. Each should let you say, six months after launch, whether the project worked.

Map the sales process you actually run

This is the section that decides everything, and the one vendor templates reduce to "customisable pipeline". Describe:

• the stages, and the event that moves a deal from one to the next (a meeting held, a quote sent, a purchase order received);
• the exceptions: lost deals that come back, several quotes per deal, partial orders, contract amendments;
• outside parties: channel partners, resellers, consultants or specifiers who influence deals without buying;
• recurring revenue: renewals, maintenance, subscriptions, where most of the value comes after the first sale;
• tenders and RFPs, if you answer them: lots, deadlines, required documents, outcome.

A diagram with five to ten boxes and a page of real, anonymised examples does the job. If your process fits "lead, meeting, proposal, close", an off-the-shelf CRM will handle it well. If it involves channel partners, specifiers or complex renewals, that is a first sign a custom build may pay off, as we explain in custom CRM development: when it makes sense.

Data: list it, and decide who owns it

For each object the CRM handles, name the system of record:

Add duplicate rules (two accounts with the same company registration number are the same account) and keep mandatory fields to the bare minimum. Every unnecessary required field is one more reason for a rep not to log anything.

Prioritise honestly, and write testable requirements

Sort each feature into must have, should have, could have and won't have (the MoSCoW method). The last group matters most: it stops one bidder from pricing what you do not want and another from silently leaving it out.

Then rewrite each requirement so it can be checked:

Integrations, one flow at a time

One line per flow, with direction, frequency and trigger:

• email and calendar: which provider, which accounts, one-way or two-way;
• quoting: does the quote start in the CRM or come back to it?
• ERP or invoicing: orders, invoices, overdue payments, payment terms;
• website forms and other lead sources;
• telephony, if calls must be logged;
• marketing tools: lists, unsubscribes, campaigns.

For each system, state whether it offers a documented API or only file exports. That single detail often moves a project from configuration to development. We cover the technical side in CRM and ERP integration, and the difference between the two tools in ERP vs CRM.

Data migration

State where the data lives today (an old CRM, spreadsheets, address books, the ERP), how much there is and what state it is in: estimated duplicates, free-text fields used for something else, inconsistent deal stages. Ask every bidder to price a test migration that reps check against their own accounts before the final switch. A CRM that launches with wrong data loses the team's trust within a week. Our guide to legacy data migration explains how to plan it.

Privacy and outreach rules belong in the requirements

A CRM is a database of personal data, and the rules depend on where your contacts are. A few examples:

• in the European Union, the GDPR applies to contact data, and national e-privacy rules govern marketing emails, often with different rules for business and consumer recipients;
• in the United States, the CAN-SPAM Act requires, among other things, a working opt-out in every commercial email and that opt-outs be honoured promptly;
• some countries, such as Canada, require prior consent even for many business-to-business emails.

Translate this into requirements: record the source and legal basis of each contact, keep an opt-out status that every send respects, and apply retention periods automatically. Add permissions per role (can a rep see colleagues' deals?), audit logs for exports and the hosting location. Our GDPR checklist for business applications covers the details, and a lawyer should confirm the rules for each market you sell into.

What you expect from the answers

Impose a response format, or the proposals will not be comparable:

• for each requirement, standard, configuration or custom development, with the cost of each;
• total cost over three to five years: licences or subscription, implementation partner, hosting, maintenance, new features;
• exit terms: full data export, format, timing and, for a custom build, rights to the code, defined case by case in the contract;
• a timeline with a first usable version early on.

Our guide on how to compare software development quotes helps you read what comes back.

Configure, extend or build: a grid for the answers

Once the proposals are in, look at your must-have requirements:

For budgets on the custom side, see how much a custom CRM costs.

Common mistakes

• Copying a vendor's feature list. The document then describes an existing product, and every answer looks the same.
• Leaving field reps out. They do the data entry; a tool they avoid stays empty.
• No system of record. Two tools editing the same customer will eventually disagree.
• Underestimating migration. Cleaning data often takes longer than configuring the tool.
• Everything is a must have. Without priorities, estimates inflate and the first version ships late.
• Writing the solution. "A green button top right" closes options; describe the need and let bidders propose.

Checklist before you send it

1. The sales process is mapped, with at least three real exceptions.
2. Every data object has a system of record.
3. Every requirement is prioritised and testable.
4. Every integration flow has a direction, a frequency and a trigger.
5. Data volumes and quality are described.
6. Privacy rules (source, opt-out, retention) are written down.
7. The response format is imposed.
8. Three salespeople have read and corrected the document.

See the CRM before you choose

A requirements document is still text, and every reader pictures something different. The surest way to check it says the right thing is to put it next to real screens. For the part of your CRM that is specific to you (the field visit screen, renewal tracking, a partner portal), we build a free prototype and present it on a video call within 5 business days, from your document or from a simple conversation. Here is how seeing your software before you pay for it works.