Since the emergence of SAAS software, off-the-shelf CRMs cover the needs of most companies, and it's now rare to have to develop a new CRM from scratch.
Many organizations deduce from this that there is no need to draw up specifications: this is a mistake!
Whether you're planning to buy a turnkey solution or develop a unique CRM from scratch, the specifications stage is essential. The "CDC" guarantees the implementation of a CRM adapted to your company and its functional and economic challenges.
In this article:
This guide will help you create the document that best suits your situation:
The CRM specification lists all the requirements that will enable a company to integrate the CRM solution best suited to its business challenges. This preparatory work, focused on the organization's objectives and processes, enables it to choose the CRM solution best aligned with its sales and marketing operations, or (a rarer case) to launch consultations so that a service provider can develop new software.
Drawing on our many years of experience in CRM project management, we'll give you all the keys to writing a clear, effective and actionable document.
The first thing to understand about CRM specifications is that there is no single possible frame, nor is there a recommended length.
Our recommended plan consists of 7 to 8 sections, which we will explore in the second part of this guide:
Whatever the size of your company or the complexity of your CRM project, drawing up a set of specifications is essential, and brings you the following benefits:
💡 Ready-to-use doesn't mean generalist: most CRMs are designed to address one of these three needs:
What's more, some solutions are designed for very small businesses, others for groups and multinationals.
→ Methodically drawing up a specification will help answer all these questions.
Now you know all the (good) reasons to create a document describing your future customer relationship management software.
However, before we break down our CRM specifications template, let's have a quick look at a question that many of you are asking:
🤔 Do you have to come from IT to write a CRM specification?
Now we can move on to the content of your document!
General description: write succinctly, but in such a way as to provide an accurate picture of the company and its environment: business sector, products/services, organizational structure, history, locations, workforce, sales, types and number of customers, etc.
Describe the company's market strategy and positioning. Analyze customer acquisition and retention methods. The competitive context is very important.
This introduction also addresses sector-specific issues. Some industries have specific features that general-purpose solutions have difficulty adapting to. Retail is a case in point, with business CRMs designed for performance in supermarkets and convenience stores.
State of play: present the current state of customer relationship management: operation, solutions used, reporting methods, organization, communication, data sources, etc. An external service provider unfamiliar with your company should be able to understand the current situation after reading this section.
In particular, you describe the pain points in current workflows that are leading you to rethink your workflows.
CRM project objectives and challenges: these are the reasons why the company wants to implement a CRM system:
In agreement with decision-makers, you can add target KPIs.
Project team: indicatethe name of the project manager, as well as the parties involved and their areas of competence: sales, marketing, customer service, finance, administration, etc. Add contact details if necessary.
If applicable, describe how the project team operates, how roles are allocated and how decisions are made.
Now that the major objectives have been introduced, we need to translate them into processes, and then into functionalities.
This is the most challenging (and perhaps the most important) part of your CDC.
For each department involved in using CRM, you'll need to draw up a list of typical actions to be carried out by a user on a daily or occasional basis. These are sometimes referred to as use cases.
A use case is a scenario or situation that describes how a user interacts with a system, application or product to achieve a specific goal. It generally presents the different steps or actions the user takes to accomplish a task.
⚠️ It's important to differentiate between business processes (use cases) and functionalities (which come in the next section). At this stage, keep it generic.
🕵️ Let's take an example from social listening
During a workshop, a colleague tells you that he has stumbled across a LinkedIn comment that severely criticizes your company.
Instantly, the customer service manager reacts: "it's a real shame we can't automatically feed back this information to do something with it at our level."
You can create :
→ A use case: "Reacting quickly to brand quotes on social platforms".
→ A feature: "The system identifies brand quotes on social networks and sends alerts to the CRM or by email to xxx@entreprise.com".
So you don 't have to worry about technical feasibility; the CRMs (or partners) you're considering will have to come up with a suitable solution!
In practical terms, it's often best to start by drawing up a table listing the objectives for each department.
Here's an example to inspire you:
🙋 If you feel overwhelmed by the scale of the project, call in a CRM consultantconsultant, whose experience will facilitate the diagnostic phase and the structuring of functional requirements. This diagnostic phase is often considered as a project management assistance mission.
CUSTOMER PATH
In the example above (social listening), we can clearly see the strategic importance of mastering customer journeys in order to implement effective processes.
So it's a good idea to map your current acquisition channels and customer paths, as well as those you want to develop with the new CRM. Workshops on specifications will help you gain perspective on your customer acquisition and retention strategies.
Be creative!
Once your business processes seem complete, it's time to start describing the functionalities that flow from them, department by department. You can also group functionalities by module (calendar, billing, business, etc.).
You can list them in a table, specifying their level of importance (for example: optional / important / essential).
It's up to you to define the level of detail of these lists of functionalities. If the specifications lead to a consultation with external service providers, the depth of this section will facilitate the costing of the development.
It is also possible to score these features, i.e. assign them an importance score. This allows you to :
Finally, no one expects you to list all the functionalities - that's a matter for software engineering, which is not your job. On the other hand, as the project owner (or AMOA), it is imperative that you cover the use cases, otherwise the software delivered will be incomplete or operationally unsuitable.
Once CRM has been deployed, you can bring the CDC to life and launch new workshops to iterate new feature developments.
System architecture: are you opting for a cloud-based or on-premise CRM, and what about compatibility with existing systems?
Hosting and data security: specify your requirements in terms of encryption, access management, RGPD compliance, server location, availability rates etc.
Integration of existing data: type, format and sources of data to be retrieved to feed the new CRM. While SaaS software generally offers imports in Excel format, special cases may require different types of intervention to collect, cleanse or format data.
IT environment: Windows / Mac / Linux, browsers, preponderance of mobility in your processes (critical for sales reps and traveling teams).
Integrations: describe your information system. Map out all the internal and external applications with which CRM must interact, whether APIs exist or not: e-mail, calendar, office suite, e-commerce site, billing software, ERP, emailing, etc.
A member of the IT department can take on the task of mapping software applications and CRM-related data. The aim of this document is to describe interactions using bricks and arrows. This is what we call the company's IT architecture.
Diagram of data flow within the company
To find out more: Understanding the importance of CRM integrations
Time constraints: detail the deployment schedule and project phases:
If you're going to work on a specific development, detail the consultation schedule (launch of the call for tenders, study of bids, writing of the CDCF, then iterative development, etc.).
Budget: detail the projected costs for CRM acquisition, implementation, training and maintenance. Propose an investment budget for implementation, then an annual recurring budget including maintenance.
This section is aimed at companies who would like to be supported by an integrator offering an extended level of CRM services.
You can list the services required, such as consulting, training of functional and technical teams, data cleansing and migration.
If you are launching a tender to appoint an integrator, you must produce a table listing all the selection criteria, which must be rated/weighted according to importance (e.g. 0 to 5). This grid enables an objective comparison to be made between the offers received. It motivates respondents by guaranteeing an honest and objective evaluation process.
You can also add other selection criteria, such as customer references or past use cases.
Finally, this is where you detail your technical support requirements (turnaround time, flat-rate operation, response modes, etc.).
You can end your CDC with a glossary defining technical terms specific to your industry, organization or products and services.
Your goal is to produce a clear, precise and effective document that enables any stakeholder to understand all the issues defined above. Theoretically, the document would be sufficient for a third-party stakeholder to take over and pilot the project autonomously.
To produce a document that accurately and precisely answers all the central questions we've listed, we'll need to include a number of different stakeholders in the process: sales, marketers, IT, etc.
You want to benefit from collective intelligence and collect as many relevant comments and good ideas as possible, while avoiding spreading yourself too thinly and building a gas factory.
Bring together all involved (and knowledgeable) employees for themed workshops. Start by drawing up a schedule of meetings, listing the main themes that will be discussed, and the people who are expected to take part.
The subject and duration must be known in advance.
Announce a typical sequence:
If the subject is complex and the meeting leaves too many questions unanswered, plan a new one. In this case, get everyone thinking in the meantime, so that the next meeting can be used to make decisions.
If necessary, review your strategic timetable and keep stakeholders informed.
✍️ Anticipate note-taking. Who does it? Have you tested the AI tools that produce meeting summaries? If you're worried about missing out on important information, record workshops (video or voice).
Meetings end with the sharing of minutes. Opt for a simple bullet-point format organized under headings, and ending with validated decisions and outstanding questions.
Notion is a practical way of organizing your reference database. You can include workshop programs and reports, and all the resources you need to contribute.
If your organization is aiming for every member to be able to view the progress of the CDC CRM in real time, you can create this on Notion too. Otherwise, the online knowledge base is just intended to document exchanges, but the deliverable remains at your discretion.
For those of you who decide to create a CRM from scratch, the functional specifications will need to describe the main sections, how the elements interact with each other, and what will appear on each screen in the user journey!
The CDC of your "in-house" CRM should then include functional mock-ups, also known as wireframes.
Bear in mind that at this stage, there's absolutely no need to make full-scale models. In most cases, freehand drawings followed by scans will suffice. If you want something a little more polished, use an application designed for wireframes(Balsamiq is all the rage!).
⚠️ Above all, don't fall into the trap of trying to produce something beautiful. That's not your job, and it will inevitably lead to lengthy meetings, as everyone will want to give their opinion on aesthetics.
Writing the specifications also has the virtue of motivating your troops. Your employees become aware that you're working on a major project that will have a major impact on their daily lives.
The CRM officer - or CRM manager - can also interview employees to gather their expectations and better analyze existing operational flows.
As you leave the CRM workshops, spread the good news and get future users to project themselves into this new commercial era in the making! On the other hand, be sure to keep a tight lid on any difficulties that arise. A software project always comes with its share of challenges, but time and collaboration will see them through!
Once CRM has been deployed, it's important to promote its use. Teams need to be made aware of the importance of filling in the CRM correctly. It is also strongly recommended to schedule a CRM meeting every quarter or half-year with all those involved in the initial specifications.
This enables you to compare achievements with initial objectives, and to identify new needs linked to the evolution of your company or its market.
CRM specifications help formalize the company's needs, effectively guide the choice and implementation of the chosen solution, and promote its scalability over time.
Do you still have questions about CRM?
→ Ask us for an online demo!
