A useful CRM requirements document explains the customer workflow the system must support, who owns each handover, which information is needed and how the team will check that it works. It also sets the first-release scope and records unresolved decisions. A list of features such as dashboards, automation and email integration is not enough to brief an implementation team.

Start with one customer journey that currently creates repeated chasing or manual work. Turn that journey into requirements the people doing the work can recognise and test. You can expand the brief once the approach is understood.

Agree which problem the CRM is meant to solve

“We need a better CRM” leaves too much room for interpretation. Ask what a colleague cannot reliably do today.

Perhaps sales cannot see where an enquiry came from. Marketing cannot find out whether a quotation became an order. An account manager is absent and nobody knows which customers need a response. These are different problems, even if the same system could help with each one.

Describe the observed problem, its consequence and the evidence available. If nobody has measured the time spent chasing updates, leave that figure unknown. Do not turn an estimate into a promised saving.

Keep the desired result specific: a colleague can identify the next action and its owner without searching separate inboxes. That gives the team something to test.

Set a beginning and an end for the workflow

Choose a boundary such as “from a website enquiry arriving to an accountable person accepting the next action”. Decide separately whether quotation approval, delivery and aftercare belong in this release.

Review recent examples with the people involved, including one that needed a workaround. The existing process-mapping guide explains how to uncover the actual steps, waiting and handovers. The requirements brief takes the next step: specifying what the future system and working routine need to do.

Microsoft’s implementation guidance recommends deriving requirements from mapped business processes and testing the process as a whole. Although written for Dynamics 365, this is a useful starting point for a discussion with any CRM implementation partner.

Give each requirement enough detail to make a decision

LUKiN recommends a short record for each requirement. Use an identifier so it can be traced through the supplier’s proposal, configuration decisions and testing.

  • Observed problem: what happens now and where the evidence comes from.
  • Required behaviour: what a user needs to be able to do, in ordinary working language.
  • Owner and handover: who is accountable for the next action and how another person accepts responsibility.
  • Information: which fields are required, where they come from and who maintains them.
  • Exceptions: what happens when information is missing, a colleague is unavailable or the normal route does not apply.
  • Acceptance test: the example the team will use to demonstrate that the requirement is met.
  • Release decision: whether this is needed at launch, can wait or requires more investigation, with a reason.
  • Open dependency: the decision, integration or input needed before the work can be completed, with a named owner.

The record need not become a large specification. Someone unfamiliar with the discussions should still be able to understand what is required and which questions remain open.

Example: make an enquiry handover testable

This is an illustrative requirement, not a client result or a standard that every business must adopt.

CRM-01: responsibility for a new enquiry. The receiving team needs to see who is responsible for an incoming enquiry and what should happen next, including when the usual colleague is away.

The business owner and implementation partner could agree to demonstrate it using these checks:

  1. Create a test enquiry through the intended entry route. Confirm that its origin and received time remain visible.
  2. Allocate it to a responsible person. Check that colleagues with the appropriate access can see the next action.
  3. Reassign it during an absence. Confirm that the new owner and any outstanding action are clear.
  4. Submit an enquiry with missing information. Check that it enters an agreed review route rather than disappearing from the team’s view.
  5. Return to the original record. Confirm that its progress can be understood without relying on a private email exchange.

Agree the response expectations and escalation route with the team. “Automatically follow up” is still incomplete if nobody has decided when a response is due, who handles the reply or what happens if the automation fails.

Make data decisions before calling them integration tasks

For each information field, ask what action or decision it supports. “We might want it later” is a weak reason to make a field compulsory.

If enquiry source matters, agree the categories, who records it and what to do when the answer is unknown. Keep the original source distinct from later marketing interactions if the team needs both. Otherwise a report can answer a different question from the one leadership intended.

Identify which system supplies customer details and who resolves conflicting records. Describe what should happen with duplicates and failed transfers. An integration requirement needs a recovery process as well as a successful connection.

Record which roles need to view, change or export information. Have the appropriate technical and data-governance owners confirm the controls and retention requirements. Avoid filling gaps in that brief with assumptions about the software’s defaults.

Separate the first release from the longer wish list

A first release needs a coherent workflow. Prioritising individual features without checking the whole journey can leave a polished enquiry form connected to an unresolved sales handover.

For each proposed requirement, ask:

  • What would prevent the agreed workflow from operating if this were absent?
  • Is there an acceptable temporary method, with an owner?
  • Which other requirement or team does this depend on?
  • What evidence would justify bringing it into a later release?

Document what is deferred and explain the consequence. Use the project-prioritisation guide for the wider trade-offs if several initiatives need the same people. A smaller scope still needs time for testing and changes to everyday work.

Review the brief with the people who will use it

Walk through the proposed process with marketing, sales and whichever team receives the work next. Ask someone to play the absent colleague, the returning customer or the person correcting a record. Those situations expose decisions that a standard product demonstration can miss.

The GOV.UK Service Manual’s guidance on user needs emphasises observing real users and treating unsupported opinions as assumptions. It concerns government services, but the distinction is useful here: a manager’s feature request still needs to be checked against the work people actually do.

Ask the implementation partner to explain how each priority requirement will be met, what is included in the proposed scope and what remains a business decision. Keep those answers alongside the requirement identifiers. Review the whole workflow during acceptance, including the exceptions and any agreed temporary steps.

In the marketing workload and CRM-readiness case, a small team introduced shared task visibility and quarterly planning while documenting customer handovers ahead of a CRM rollout. The client team implemented the changes with LUKiN’s advisory support. The wider CRM implementation remained in progress under a different team.

That distinction matters when scoping support. Organising the team’s work and clarifying its requirements is a defined piece of work. Configuring, migrating and launching the CRM is another, with its own responsibilities and acceptance decisions.

If the difficulty is agreeing the process before briefing a supplier, explore process improvement consulting. If it is unclear whether the main problem is workload, ownership or the systems themselves, a focused Operational Performance Diagnostic can help establish the starting point.

Sources

The working record and example above are LUKiN’s practical recommendations. They are not a product-specific configuration specification.