How to Prepare Terms of Reference for a CRM/ERP Project?

Many companies start implementing a CRM or ERP system with enthusiasm, but they soon face the same problems: deadlines keep shifting, the budget grows, and the final result turns out to be far from expectations. The reason is almost always the same – the lack of a well-prepared Terms of Reference (ToR). Without a ToR, developers work “by guesswork,” the client loses control over the process, and the system itself stops matching actual business processes. As a result, the project turns into endless rework and a source of expenses instead of a growth tool.

A properly prepared Terms of Reference helps avoid this. It turns abstract wishes into a clear plan: it defines business goals, describes functionality, and sets boundaries for budget and timelines. Essentially, the ToR becomes the project’s roadmap, ensuring that the final CRM or ERP truly addresses the business needs. In this article, we will go step by step through the process of preparing a Terms of Reference so that your project is manageable, transparent, and successful.

A Terms of Reference (ToR) is a document that formalizes the client’s requirements for the future system and records the agreements between the client and the contractor. In IT projects, it plays the role of a “roadmap”: it outlines business goals, functional and non-functional requirements, user scenarios, as well as constraints regarding deadlines and budget.

In essence, the ToR is a common language through which business and developers interact. The Terms of Reference is a tool that helps transform ideas and abstract expectations into a concrete action plan that is clear to all project participants.

Why a Project Without a ToR is Doomed to Fail

The absence of a clearly formulated Terms of Reference leads to common problems:

• Missed deadlines. The development team constantly has to clarify tasks and rework functionality.
• Budget overruns. Due to revisions and changes, the project costs significantly more than initially planned.
• Failure to meet expectations. The final CRM or ERP system may fail to cover key business processes and therefore will not deliver the expected results.

In other words, without a ToR the project moves chaotically: the client and the contractor have different ideas about the final outcome, which inevitably leads to conflicts, wasted time, and wasted money.

Next, let’s look step by step at how to prepare Terms of Reference for a CRM/ERP system.

Business Process Analysis

Before describing the future system, it is important to understand how the company operates today. At the first stage of preparing Terms of Reference for ERP or CRM, key business processes are documented: sales, procurement, warehouse management, accounting, and customer interactions. The analysis helps identify “bottlenecks” – routine operations, duplicated actions, data loss – and to define the problems that the CRM or ERP must solve.

Defining Goals and Success Metrics

The ToR should answer the question: why is the system being implemented? Goals may vary: increasing sales transparency, reducing costs, speeding up document flow, or improving customer service. Each goal must be supported by measurable metrics: order processing time, number of deals per manager, speed of request resolution. This makes it possible to objectively evaluate the project’s effectiveness after launch.

Identifying Users and Roles

A CRM/ERP system is a tool used by different categories of employees: sales managers, accountants, department heads, and top management. It is important to define their roles and access rights in advance: who creates documents, who approves them, who only has access to reports. Clear role separation not only improves usability but also ensures data security.

General Section

At the beginning of ToR preparation for a CRM, the key inputs are defined: the project purpose, terminology, scope of use, and possible limitations. This serves as a “framework” that sets the direction for the entire development. Here, the document describes which business tasks the system should address, which standards and regulations are considered, as well as technical and organizational constraints (for example, using a specific technology stack or integrating only with the existing infrastructure).
When we prepare Terms of Reference (for example, for developing a CRM system), we aim to explain the structure as fully as possible and show how all functional requirements are derived.

Functional Requirements for CRM/ERP

This is the core of the ToR, where the modules and their functionality are described in detail. Examples include:

• Sales and Clients – deal tracking, pipeline management, communication history.
• Warehouse and Logistics – product movement, stock levels, invoice generation.
• Finance – invoices, acts, payments, debt management.
• Analytics – KPI reports, forecasting, dashboards for executives.
• Integrations – connections with ERP, websites, and marketing tools.

Each module must be described as specifically as possible so that developers clearly understand which scenarios need to be implemented.

Non-Functional Requirements

Beyond functionality, it is important to define quality requirements for the system:

• Security – access control, personal data protection.
• Scalability – ability to add new users and modules without reworking the system.
• Performance – response time, operation under load, stability with a large volume of transactions.

UX/UI and Usability

For successful implementation, it’s not enough to simply build the functions – they must also be convenient to use. A ToR for CRM or ERP typically includes interface prototypes and user scenarios. This helps visualize the future system and avoid misunderstandings during development.

Integrations with External Services

CRM or ERP systems rarely exist in isolation. The ToR should specify all required integrations, such as:

• with telephony (IP-telephony, call tracking),
• with accounting systems (e.g., 1C),
• with marketplaces and eCommerce platforms,
• with payment services,
• with messengers and chatbots.

As a rule, such integrations are implemented through APIs (REST, GraphQL, SOAP) – the main channel for data exchange between systems. This defines exactly which data can be transferred, in what format, and according to which rules, ensuring predictability and compatibility across services. The more detailed the integration points are described, the easier it is for developers to build a unified digital environment without “lost” data or broken processes.

Prototyping (Moqups and Alternatives)

A purely textual description of functions is often interpreted differently. To avoid misunderstandings, prototypes of interfaces created in tools like Moqups, Figma, or Balsamiq are added to the ToR. A prototype shows how system screens will look, which controls are available, and how the user moves through a scenario. At this stage, making changes is the easiest: adjustments to a prototype cost far less than reworking finished code.

Function Checklist

To structure requirements, a complete list of CRM/ERP features is created. All items are compiled into a table: which functions are mandatory, which are “desirable,” and which can be implemented in later phases. Such a checklist helps set priorities, align expectations with the business, and later use it as a development control tool.

Video Explanation of the ToR

A good practice is to supplement the document with a video presentation. A short clip demonstrating the prototype and analyst’s commentary makes communication between client and team easier, and also helps onboard new project participants faster. A video captures the overall context and reduces the risk that critical details will be understood differently.

Process Automation

The ToR should describe how key operations will be automated:

• deal stages and transitions between them,
• sales pipeline management,
• setup of bots and automatic notifications,
• scenarios for handling orders or requests.

This makes it possible to test the system’s logic in advance and ensure usability for end users.

UML Diagrams and Database Structure

When developing complex systems, it is important to fix the architecture of the future CRM/ERP. UML class, use case, and sequence diagrams help visualize relationships between objects and processes. The database structure defines key entities, their fields, and relationships. This level of detail reduces the risk of errors during development and simplifies scaling in the future.

When implementing off-the-shelf solutions, the focus is not on designing architecture but on building integration schemes and customizing them to fit the company’s business processes.

The Client’s Role

At this stage, the client’s key task is to carefully review the document. It is necessary to ensure that all business processes are described correctly, the functionality matches actual tasks, and formulations eliminate ambiguity. Attention should be paid to details: user roles, automation rules, integration scenarios. The more thoroughly the client checks the ToR now, the fewer conflicts and revisions there will be later.

The Developer’s Role

The contractor’s team analyzes the document from their perspective and makes clarifications. Developers evaluate the technical feasibility of requirements, propose alternative solutions to optimize costs or timelines, and point out possible risks. In addition, specialists may supplement the ToR with architectural diagrams, suggest tools, or ready-made integrations that speed up development.

Final Approval

Once all comments and revisions are agreed upon, the document is approved by both parties. The final version of the ToR becomes the working foundation of the project: it is used for budget calculations, timeline planning, and project evaluation. It is important to note that the ToR may also serve as a legal document, but only if it is approved by both parties and formalized as an annex to the contract.

Lack of Specificity

One of the main issues is overly general statements like “the system should be convenient” or “CRM should speed up sales.” Such requirements cannot be objectively verified and cannot be implemented unambiguously. As a result, developers interpret them in their own way, and the client ends up with something different from what was expected. To avoid this, every requirement must be specific and measurable: for example, “page load time should not exceed 2 seconds” or “notifications about a new request must reach the manager within 30 seconds.”

Ignoring Non-Functional Requirements

Often, a ToR describes functionality in detail but neglects parameters such as performance, security, scalability, and fault tolerance. This leads to situations where the system technically works but begins to “lag” as the number of users grows, or creates risks of data leaks. Non-functional requirements directly impact stability and the long-term cost of maintenance, so they must be defined from the very beginning.

Lack of Visualization

Even the most detailed text-based ToR doesn’t always provide full clarity. Without interface prototypes, business process diagrams, or UML diagrams, the client and developers may imagine the final result differently. This results in multiple revisions at later stages, when changes become costly. Visualization is a simple tool that helps align expectations early and “see” the future system before coding begins.

A well-prepared ToR ensures process transparency, makes deadlines and budgets predictable, and guarantees that the final system will truly solve the company’s business challenges.

When the document clearly defines goals, functional requirements, user roles, prototypes, and usage scenarios, both client and contractor share a common language and a unified reference point. This reduces the risk of errors, speeds up implementation, and increases the chances that employees will adopt and actively use the system.

Our team helps prepare and align ToRs, including prototypes, checklists, and visualization. If you need Terms of Reference development, our team is ready to assist.