CRM System

A CRM system is more than the CRM app your salespeople open in the morning. It is the whole arrangement: the modules you license, the way customer data is structured inside them, the rules about who can see and change what, and the connections to your email, invoicing, support and marketing tools. When people say “the CRM is not working”, the problem is usually in one of those layers, not in the screens.

If you are still at the stage of asking what a CRM is for, start with our explainer on what a CRM is. This piece assumes you know the basic idea and want to understand how a CRM system is built, so you can evaluate one properly and run it without surprises.

The parts of a CRM system

Most CRM systems, whatever the vendor, are assembled from the same building blocks. Vendors package and name them differently, and many sell them as separate products.

Sales module

This is the core for most companies. It covers leads, contacts, accounts, deals, pipeline stages, tasks and forecasting. Often called sales force automation, it is where salespeople log activity and where managers watch the pipeline.

Marketing module

Marketing features handle email campaigns, forms, landing pages, lead scoring and campaign attribution. The goal is to capture prospects, warm them up and pass them to sales at the right moment with their history attached.

Service module

Service features cover support tickets, case history, knowledge base articles and service levels. When service sits on the same customer record as sales, a support agent can see that a customer is mid-renewal before replying to an angry email, which changes how they reply.

Reporting and analytics

Every CRM system includes reports and dashboards. Some go further, with forecasting models, customer segmentation and predictive scores. The more advanced features almost always depend on data that is complete and consistent.

Administration layer

Underneath the visible modules sits the part your system owner will spend most time in: user management, roles and permissions, field definitions, validation rules, automation workflows, audit logs and data import and export tools. This layer is rarely shown in a demo, and it is where the long-term cost of a CRM system is decided.

Operational, analytical and collaborative CRM

CRM systems are traditionally grouped into three types. In reality most products combine all three, but the distinction is useful for working out what you actually need.

Operational CRM

An operational CRM supports the day-to-day work of dealing with customers: logging calls, moving deals, sending campaigns, answering tickets, automating follow-ups. Its value is efficiency. Most small and mid-sized companies need this first, because it replaces the spreadsheets and inboxes where the work currently happens.

Analytical CRM

An analytical CRM focuses on understanding the data the operational side collects: which customers are most profitable, which campaigns produce deals, where the pipeline leaks, which accounts are likely to churn. It may involve a separate data warehouse or business intelligence tool fed from the CRM. Analytics is only as good as the operational data beneath it, so it rarely makes sense to invest heavily here before the basic habits are in place.

Collaborative CRM

A collaborative CRM is about sharing customer information across teams and channels: sales, service, marketing, partners, and sometimes the customer through a portal. The aim is that every person who deals with a customer sees the same history. For companies where several departments touch the same accounts, this is where the real value lies, and it is also where permissions get complicated.

The CRM data model

The data model is the structure of records and relationships inside the system. It sounds technical, but it determines what your reports can say, so it deserves attention from whoever owns the CRM.

Core objects

Most CRM systems are built on a similar set of objects (the vendor may call them records, entities or modules):

• Leads: unqualified prospects, often from forms or lists, not yet linked to an account.
• Contacts: individual people you have a relationship with.
• Accounts or companies: the organizations those people belong to.
• Deals or opportunities: potential sales, each with a value, stage and expected close date.
• Activities: calls, emails, meetings, notes and tasks, each linked to the records above.
• Products and quotes: what you sell and the offers you send.
• Cases or tickets: support requests, if the service module is in use.

Relationships

The relationships between objects matter as much as the objects themselves. A contact belongs to one account, or to several. A deal has one account but may involve several contacts with different roles. An activity can be linked to a contact and a deal at the same time. If the model cannot represent how your business actually works (for example, a consultant who influences deals at several client companies), people will work around it, and the workarounds will break your reports.

Custom fields and custom objects

Every company adds fields: industry, region, contract renewal date, partner source. Many systems also allow custom objects for things the standard model does not cover, such as properties for a real estate firm or projects for an agency. Customization is useful but has a cost. Each custom field is something to maintain, document and migrate later. A good rule is to add a field only when someone has named the report that will use it.

Integrations

A CRM system that stands alone is a contact list with extra steps. Most of its value comes from what it is connected to.

Common integrations

• Email and calendar: so that messages and meetings are logged without manual entry.
• Telephony and video calls: so that call records attach to the right contact.
• Marketing tools: if marketing runs on a separate platform.
• Invoicing, accounting or ERP: so that a won deal becomes an order or invoice without retyping. See our guide to invoicing software for that side of the connection.
• Support desk: if service runs on a separate system.
• Identity and single sign-on: so that access follows your company’s user directory.

How integrations are built

Integrations come in three broad kinds. Native integrations are built and maintained by the CRM vendor. Marketplace integrations are built by third parties and listed in the vendor’s app store. Custom integrations use the CRM’s API, sometimes through a separate automation platform. Native integrations are usually the most reliable. Custom ones give the most control but need someone to maintain them when either system changes.

Before you buy, ask which direction data flows in each integration, how often it syncs, and what happens when the same record is changed in both places. Sync conflicts are one of the quiet causes of bad CRM data.

Deployment and security

Almost all CRM systems sold today are cloud software, which means the vendor hosts them. A few vendors still offer on-premise or private cloud versions for organizations with strict data requirements. For most companies, the questions that matter are where the data is stored, which security certifications the vendor holds, and whether the system supports single sign-on, two-factor authentication and field-level permissions.

Permissions deserve particular care. A CRM system often holds deal values, personal phone numbers and notes that were never meant to be widely shared. Decide early whether salespeople see only their own accounts or everyone’s, and who can export data in bulk.

Questions to ask before you buy

• Which modules do we need now, and which are we paying for in case we need them later?
• Can the standard data model represent our customers and deals without custom objects?
• Which integrations are native, which are third party, and which would we have to build?
• How are sync conflicts between the CRM and other systems handled?
• How granular are permissions: by team, by record, by field?
• Who on our side will administer the system, and what training does the vendor provide for that role?
• If the vendor’s explanation of the data model is hard to follow, will our team follow it any better?

Where it goes wrong

• The data model is designed around the demo rather than the business, and reports never quite match reality.
• Custom fields are added on request with no owner, until the record page is a wall of half-empty boxes.
• Integrations are switched on without agreeing which system is the master for each field, and data overwrites itself.
• Analytical ambitions arrive before operational discipline, so dashboards display incomplete data with great confidence.
• Permissions are left wide open at launch and are politically difficult to tighten later.

My recommendation

For a small or mid-sized company, build the operational layer first and keep the data model close to the vendor’s standard. Connect email and calendar on day one, add one integration to invoicing or accounting once the pipeline is reliable, and leave advanced analytics until you have at least two quarters of clean data. Before choosing a vendor, compare a few current CRM software examples, and for the wider picture of how this fits with your other business systems, see our overview of B2B SaaS.