CRM requirements: write your own rules, not a vendor’s feature list

Sooner or later someone asks you for the requirements: a vendor before the demo, a board before it approves the spend, a studio before it quotes. CRM requirements are the written list of what your sales process needs a CRM to hold and to enforce. They describe your business, which is why a list copied from the internet rarely fits it.

Most checklists online come from CRM vendors and selection sites, often behind a download form. They list features to look for in a boxed product: contact management, dashboards, forecasting, automation, a mobile app. That describes the product rather than the way you sell, so this article lists your rules instead.

What follows is how to write those rules down, a checklist that tests a boxed CRM on your own awkward deals, and a one-page document a studio can price. It comes from a studio that builds a custom CRM when the way a company sells stops matching the box, and that tells most companies to buy a boxed CRM instead; we say so on the first call.

CRM requirements start with the sales process, not a feature list

Most requirements gathering begins with features, because features are easy to list. Start instead with one page that shows how a deal moves through your company, drawn the way your team talks about it.

Stages. Name each stage a deal passes through, from first contact to paid and delivered. Use the words your salespeople use, not the ones in a vendor’s demo.

Transitions. For each stage, write where a deal may go next and what must be true before it does. A deal that can jump from first call to won without a quote shows a rule nobody has written yet.

Who may move a deal. Write who may move a deal forward, who may move it back and who may close it. These permissions are often the first thing a boxed product gets wrong, so they belong near the top of the page.

Show the drawing to your sales lead and ask whether it is right. Sometimes it starts an argument instead, and that is useful too: a process people disagree about cannot be written down as a requirement, so agree on it before you ask anyone for a price.

Write the pricing and approval rules as arithmetic

Start with how a price is built, because this is where most companies outgrow a boxed CRM. If a quote takes an hour, something in the price depends on a factor your current tool cannot compute, and that factor is the first rule to write down.

Write each discount as a calculation, not a sentence. “Good customers get a better price” is a sentence; the volume, the category and the customer type that change the price, and by how much, are arithmetic. List every factor your business genuinely uses, and only those.

Then write the conditions and approvals the same way. They tend to sound like this: free delivery above a set order value, a second discount only with the sales director’s sign-off, nothing ships before the deposit arrives. If such rules exist only as habits today, the page is where they are written down for the first time.

The reason to write them down is that a product full of fields is not a requirement. A discount field records a number someone typed; the requirement is the rule that decides what the number should be.

Finally, turn every rule into a case. Take a real deal and write down its inputs and the answer your best salesperson would give by hand. A rule you cannot turn into a case is not finished, and the set of cases becomes the test any system has to pass, boxed or built.

Who sees what, and who does the typing

Write down who sees whose deals, who sees margin and who may reassign a deal to someone else. It is usually more subtle than “the manager sees everything”.

Then list everyone who should work in the system, not only the salespeople: the people who pack, install, deliver or invoice after the sale. Count them, because a product priced per seat will tempt you to leave some of them out, and every person left out is a part of the order the system never hears about.

Last, name the people who do the typing, and roughly how many records they enter on a busy day. A system that slows them down will be avoided, whatever the rules say.

Turn that into a number: how long one record may take on a busy afternoon. A demo shows the first entry of the day, when everyone is fresh; the requirement is about the last ones, when nobody is.

The history you bring and the one integration you need

Your history takes one line of the page, but a precise one. Say where it lives (a spreadsheet, an old CRM, or both at once), roughly how much of it there is and what state it is in.

Then name who decides between duplicates. When the same customer turns up under three names, someone on your side has to choose the right one; whoever moves the data should not be guessing.

For integrations, choose one: the system you cannot work without, whether that is accounting, telephony or the mailbox. The rest wait for a second phase on purpose.

The reason is not technical. Every connection depends on another company’s documentation and timetable, so each one added at the start is one more thing that can hold the whole project up.

A CRM requirements checklist that tests a boxed CRM

With the rules on paper, you can test a boxed product properly. Open a trial and answer eight questions with a plain yes or no.

• Do your stages and transitions fit without workarounds, with only the right people able to move a deal?
• Can your pricing and discount rules be expressed in its settings, so that a quote matches the one your best salesperson would make by hand?
• Do roles and visibility work the way you wrote them: whose deals, whose margin, who may reassign?
• Does your one integration work in the trial itself?
• Did a sample of your history move in with a reconciliation you could check, rather than a promise that it worked?
• Can everyone who needs access have it, without per-seat pricing deciding who is worth a licence?
• Can a record be entered on a busy afternoon within the time your page allows?
• How many custom fields did the trial need? A handful is normal; if you stopped counting, the product does not hold your process.

Run the checklist on three awkward deals from last quarter, not on the vendor’s demo. A demo shows the deals the product was designed for; your awkward deals show the ones it was not.

A one-page CRM requirements document

This is a CRM requirements template to copy, not a file to download. Put it on one page, one line per item, in your own words.

• The company and the sales team: what you sell, to whom, and who sells it.
• The pipeline: stages, transitions and who may move a deal where.
• The rules: pricing, discounts and approvals written as arithmetic, each with a real case and its correct answer.
• Roles and visibility: which deals each person may see and change, who may see the margin, and who may hand a deal to a colleague.
• Who types, and how often: the people entering records and roughly how many on a busy day.
• The history: where it lives, roughly how much, what state it is in, and who decides between duplicates.
• The one integration: the system you cannot work without.
• What waits on purpose: whatever you can live without for the first months of use. Listing it stops anyone pricing it, and keeps the first version small.
• What a box would force you to give up: one line, and the one that tells a studio what the build is for.

Give the same page to every vendor and studio you talk to, and their answers become comparable. The page covers the CRM alone; the wider brief around any project is covered in the guide to the software requirements document.

What the finished page decides: the box or a build

If the checklist passes in a box, buy the box. Most companies find that it does, and a product they can start using next week costs less than anything built for them.

We do not set up boxed CRMs. That work belongs to the product’s own integrators, who do it every day, and the page you wrote is exactly what they need.

The case for building rests on the no answers. It holds when the page shows rules the box cannot express, people the box would price out of the system, or a way of selling your customers choose you for, and when someone on your side has time to answer questions while the work goes on.

Two reasons are bad ones. A company that has never used a CRM does not know its requirements yet, and a boxed product is the cheapest way to learn them. And a page that describes a well-known product with your logo on it asks for a copy of someone else’s work, not for a CRM of your own.

If the page says build

The cases you wrote under each rule become the test the finished system has to pass, so the page does double duty: it is the brief for an estimate and, later, the check on the result.

What a first version holds, what it costs, how long it takes and how it is paid for are set out on the custom CRM page, so this article does not repeat them. The page you wrote does not fix the price in advance; it makes the estimate specific to your business rather than to an average one.

The next step: send the page

Fill in the page and run the checklist on a trial. If the box passes, buy it and hand the page to whoever sets it up.

If it fails on the rules, the pricing or the access, send the page to us. A basic estimate comes back within 12 hours, with the scope it covers and the list of things we assumed. How we build a custom CRM, stage by stage, is on the service page.