How to Choose a CRM: A Technical Evaluation Framework

Most CRM implementations fail because companies evaluate features in isolation rather than how the system will integrate with their actual workflows. The gap between a polished vendor demo and daily operational reality becomes obvious only after purchase - when it's expensive to reverse course.

Choosing the right CRM requires evaluating technical fit, integration requirements, and business trade-offs most buyers overlook. Off-the-shelf platforms work well when core needs align with standard functionality. Custom builds make sense when workflow complexity or scaling requirements exceed what packaged solutions handle efficiently. This guide walks through a framework for matching CRM architecture to operational needs - from API capabilities and data model flexibility to total cost of ownership - so teams can make defensible decisions before signing contracts.

Map your actual data model first

First: write down the data being stored in the new CRM. Since every sales person has a pipeline, pipeline demos are fairly standard. Custom objects, the relationships between them (cardinality), and the hierarchical relationships (i.e. that one object is "nested" inside of another) are what will determine which CRM is right for the business.

Salesforce is great for storing normal sales-type information i.e. contacts, leads, accounts, etc. for basic workflow. But as the business model becomes more complex then Salesforce starts to break.

Salesforce has a data model that is essentially a relational database managed by Salesforce, all managed through a user interface. In Salesforce teams can create Custom Objects, junction tables, roll-up summary fields, etc. HubSpot's data model is much simpler. As teams move up to the add-on called Operations Hub (part of the CRM product) they start to realize that things that are included out of the box in Salesforce Professional-tier plans cost extra in HubSpot's Operations Hub. Pipedrive has a data model suited for companies with linear sales pipelines, and it cannot be adapted to be suitable for more complex businesses.

Teams that have mapped out the proper data structures for their businesses before spending time poring over CRM demos never have to regret their platform choice.

Most CRM systems start with the standard data such as contacts, companies and deals. But in addition to this standard data there is a lot of other data that a business stores in its CRM system. This other data is called 'custom objects'. For a project-based sales organization this custom object could be Projects, storing the stages of a project's lifecycle, the budget assigned to the project, and the team members working on the project. For a subscription-based sales organization, the custom object for storing data could be Subscriptions, containing information on renewal dates, plan details and the upgrade history. For a manufacturing or field service organization this custom object could be Equipment or Assets.

Note that all CRMs allow custom objects to be created. The distinction lies in paid plans where unlimited objects can be created and in the core capabilities of the object. So each object can have its own page layouts, workflow steps, security settings, reporting etc. With this in mind, Salesforce supports a wide array of data structures and is by far the most versatile CRM for businesses that have very complex business processes that need to be mapped to data structures in the CRM. HubSpot and Pipedrive on the other hand do not support custom objects natively. HubSpot's custom objects are created in bulk as part of Operations Hub which is an additional cost on top of the CRM subscription. Pipedrive does not support custom objects at all so businesses would need to adapt their processes to work within the native objects and data structures that Pipedrive supports. Therefore businesses will for the most part be locked into the process and data structure of the platform until an alternative is found.

This is more important than many teams realize when choosing a CRM.

Audit your required integrations and data flows

Most teams start by mapping out all the different tools in their tech stack in a spreadsheet and then look for CRM integrations for each of the different tools one by one. Backwards.

Begin at the CRM data that flows out to the other systems where 'account' information and 'product' information are stored. Make a list of systems in the order in which the data flows out of the CRM and then follow the information as it goes through each system in which it 'touches' the CRM along the way. After outlining the systems through which data flows then and only then can potential CRMs be compared with the tech stack.

• Accounting: Various accounting systems such as QuickBooks, Xero, NetSuite. Typically CRM data is written to the accounting system when an invoice is generated within the CRM.
• Marketing automation: Most marketing automation systems are hosted outside of the CRM that holds customer information. Thus the key data points to sync would include leads, campaign information, email information, etc.
• Support desk: Tools like Zendesk or Intercom. These systems would typically need to be 2-way with the CRM. Sales teams would want to see the ticket history of a customer. Support teams would want to see the full account context when viewing a ticket.
• E-commerce: Various e-commerce platforms exist including Shopify, WooCommerce and more. Order data is pushed from the e-commerce platform to the CRM via hourly batch syncs.
• ERP or fulfillment systems: bi-directional (order status/inventory availability)
• Custom internal tools: APIs, legacy databases, homegrown systems built years ago that can't be replaced

Finally, for each data flow, determine whether that data flow is one-way or two-way, in real time or by batch, and what fields are being synchronized and what is triggering the process to start syncing.

Most native integrations will have very limiting constraints on them that are only discovered once it is too late. For example, custom field support varies greatly between platforms. Some platforms will not support certain custom field types within native integrations. When records are deleted in one system, what happens to the records in the other system (hard delete, soft delete, no action)? Many native integrations have a fixed sync frequency and do not allow the user to change this to meet their business needs.

There are also restrictions on how native integrations can be used to sync data between platforms. For example, while native integrations between platforms may support the syncing of all standard fields, there are often restrictions on the syncing of custom fields. While Pipedrive's native integration with QuickBooks Online supports the syncing of all custom fields from Pipedrive to QuickBooks Online, only a subset of custom fields can be synced from QuickBooks Online to Pipedrive. Other native integrations, such as HubSpot's integration with Salesforce, do not support the syncing of custom fields at all. In addition, while native integrations between platforms may support the syncing of all custom objects, this may require the use of a platform's Operations product (which costs extra). For example, while all custom objects from Salesforce can be synced to HubSpot using the native integration between the two platforms, the use of HubSpot's Operations product is required to sync custom objects from HubSpot to Salesforce. Finally, there are huge variations in how deleted records from one system are handled in other systems. Some systems hard delete records from other systems, while others soft delete records from other systems (meaning that the deleted records are still visible in the other system but with a deleted flag set). Still other systems do nothing at all when a record is deleted in one system.

For each of the integrations above, ask these important questions to see if that integration will be right for the business.

• Does it support custom fields or just standard objects?
• How does the system handle deletion of records in other systems (e.g. Hard delete, Soft delete, No sync)

Evaluate automation capabilities against your process complexity

The first mistake teams make with a new CRM is testing whether the CRM can send an email whenever a deal changes to a new stage, only to realize after 6 months that the CRM doesn't support the conditional routing they were envisioning.

To determine whether a CRM will support automation needs, map out the business's most complicated process. Yes, it is likely that this process won't be used right away, but rather it will serve as a great resource down the line for additional development beyond the simple 3-step process that was put in place to enable the automated sending of emails for the sales development team. The question that must be asked is: can the automation engine support the most complicated process that the business needs to automate on a daily basis? The process will involve multi-step approvals with real-time validation of data that is specific to the process and that meets the criteria of a number of custom rules that are required to be in place in order to ensure that the process is running smoothly. In addition to the above, the process will require the support of many levels of branching logic that will be required in order to support the complex business process that the business follows on a daily basis.

However, the technical architecture for the automation of processes in CRM systems must also be examined. Automation of processes in CRM systems is a standard feature and is offered by all providers.

Flow Builder for Salesforce has the ability to have very complex conditional logic. It can have multiple levels of depth and still work fine. Other automation tools such as HubSpot Workflows have the ability to handle more basic automation of if/then type processes but can start to break down when there is branching. This type of workflow is much better suited for very basic processes that don't need a lot of complex steps and can be managed by having separate workflows for each section of the process with other workflows that enroll to previous ones to continue the process like a relay race. Pipedrive is more suitable for automating simple sales sequences and isn't quite up to the task of full business process automation.

While there are no limits on the number of automations, Salesforce's Flow Builder currently has an automation element limit per flow. This restricts how complex of a process can truly be automated within the platform. Typically, this results in having to rebuild process logic within another automation in order to hit the limits of the automation. Furthermore, HubSpot's Workflows have enrollment limits for large numbers of records as well as time outs for long running operations with large datasets of records. Both platforms will also throttle the amount of records that can enroll into a workflow on a trial account per hour. None of this shows up until a full production automation has been built out.

Then test error handling. For example what happens to the process automation when a step in the automation fails (e.g. API call times out, required field is missing, external system returns error). Does the tool reverse any changes that were made, does it log the error, are there automatic retries of the operation that failed.

Most don't handle failures well. Teams are left to clean up the mess of errant data in the middle of the night.

Test reporting and data extraction requirements

Four simple words that summarize where many CRM evaluations go wrong: Cross-Object Reporting. Teams might test out the user interface to see whether it looks and feels 'right'. And they might test out the various integrations that are supported (or not supported). They may well even create a few basic workflows whilst there. But after that, it is the business queries that start to reveal a CRM up for what it is: i.e. a single object platform in which various objects are implemented (most commonly: accounts, contacts, activities and deals). It is typical business queries that reveal just how restricted a CRM actually is. Four simple words that can easily turn into a project: "Show me all the closed deals for this quarter. By industry. With the number of marketing touches that an account received before it closed as the deal was won". That report involves 4 objects: deals, accounts, contacts, activities. The fact that most CRMs would be unable to complete such a report (in a single report) in a few minutes is why the four words are so telling.

For cross-object reporting, most CRM reports are able to handle reports with a few objects: Deals, Accounts, Contacts and Activities. Reporting with more objects than this typically turns into a project.

Once teams get past simple reports that cover a single object in Salesforce's report builder, multi-object reports such as those that include deals, activities, accounts and contacts can be created. These reports can be formed using Joined reports and cross-filters. Within report builder, fields from the multiple objects can be placed into bucketed fields, report fields and the reports created from the joined data. For example, if a sales team wanted to report the number of marketing touches all accounts in a list of closed deals for the quarter by industry then Accounts, Activities, Deals and Contacts could all be joined together and the appropriate fields brought into report fields in the report builder interface. Creating reports that are more complex than simple reports covering a single object within report builder is very challenging and generally requires the expertise of a professional consultant in addition to the typical functionality available from most user interface elements within other applications that are used for creating reports. Report builder in Salesforce is a 'plug-and-play' tool for creating simple reports covering single objects however creating reports covering multiple objects in a straightforward manner can require significant sophistication.

Custom reporting within HubSpot is available for users on the Professional tier and above. Reporting with joined objects (i.e. deals and accounts) is okay for a few objects, but once activities or custom objects are brought in, the reports hit a ceiling. Pipedrive's reporting is mostly limited to single objects, therefore teams would generally have reports related to deals and normal sales pipeline reports, but for cross-object analysis between deals and accounts for example, exporting the data and doing that sort of analysis in Google Sheets or MS Excel is typically required.

The ultimate test for a CRM's reporting features is to test building a report for a multi-object scenario. In a trial, try to build a report that would answer a typical business-oriented question. If the process constantly requires exporting data to Google Sheets, then the CRM's reporting will not be enough.

Eventually, all of the data from custom objects and fields within a CRM will need to be exported. This will allow that data to be used in Business Intelligence (BI) tools or a data warehouse. The process for exporting data from custom objects varies significantly between CRM vendors.

Salesforce also provides native support for connectors that allow for data import to BI tools such as Tableau, Power BI and many other Business Intelligence platforms.

Calculate total cost including hidden expenses

All prices listed on a vendor's website are typically only a fraction of the real cost of the software to a team. To develop a solid plan for the expected total cost of ownership for a chosen CRM, use the following formula: Base subscription + integration middleware + custom development + admin overhead + data migration costs. Often, a team's initial budget is increased as they discover all the costs that were not included in the initial estimate.

Here's how to break down the total cost of ownership for a CRM.

Core subscription at 3-year headcount

Start with the core CRM subscription price for the projected number of users for the 3-year period. For example, Salesforce's Pro Suite is $100 per user/month (2026). A typical sales team would be 25 people, growing to 50 in 3 years. Thus the 3-year cost would be $30,000 per year in year 1, and $60,000 per year in year 3. HubSpot offers usage-based and seat-based plans for various hubs - see HubSpot for current pricing.

Required add-ons and platform limitations

The features locked into the various tiers of a CRM are often the key selling points for the particular package. But as teams progress through the tiers, it becomes apparent that many of the most advanced features are locked behind even higher price points. Sometimes these features are even sold as separate products.

Additional costs also exist for add-ons, advanced API access, custom development, and more. Salesforce's base package does not have advanced API access for example. In HubSpot for example, custom objects are restricted to Operations Hub which is an additional cost. Zapier and Make are two applications that can automate the integrations of applications. These workflow platforms offer free tiers and usage-based paid plans - see Zapier and Make. There will also be additional costs to integrate with other applications such as accounting, support desk, and data warehouse applications. The CRM application will not have native integration with these types of applications.

Integration and middleware costs

Most CRMs are unable to integrate easily with existing accounting packages, support desks and data warehouses.

Zapier and Make for example price by operations, i.e. by the number of times a task is performed. This can be in terms of monthly pricing (so charged on an annual basis) or in terms of a set number of total operations (tasks) allowed. The volume of workflows therefore needs to be taken into account and allowed for in the budget. Integration middleware will add recurring costs to the CRM budget. Then either Zapier can automate this, or custom API integrations can be developed as covered in the development costs below.

Match CRM architecture to your business complexity

Choosing the right CRM for a business is crucial and depends on three key factors: The complexity of the relationships in the data, the number of integrations/automations set up, and whether there are in-house technical resources to set up, customize and integrate the CRM.

So to summarize: simple data models with a few integration points and basic automation functions could be addressed by simple sales applications like Pipedrive or HubSpot Starter/Professional for small to medium sized companies with simple sales processes.

At moderate complexity there might be a few custom objects like for example Tasks and Activities. Also here there might be a few integrations with other products (5-10 or so) and automations that involve several steps in the form of workflows that get triggered off by changes to the data. Here for most teams HubSpot Professional or even Enterprise would be the sweet spot. HubSpot has great tools that allow users to set up complex workflows without needing to write code.

Next up for complexity are high complexity organizations. These would typically be organizations with: Many custom objects, complex many-to-many relationships between objects, 10+ integrated systems, advanced automation logic required to manage workflows. As a general rule, high complexity organizations have people on staff or a contractor that the organization can call upon to develop custom functionality on their behalf. That being said, a great choice for high complexity organizations is Salesforce. Salesforce's Starter Suite is $25 per user/month (2026) and is a very stripped down offering that most organizations would not find suitable for production use. In such cases, the organization would typically move to one of the higher-tier offerings such as Enterprise at $175 per user/month (2026) or higher per user.

The biggest challenge for small businesses choosing a CRM system is deciding between Salesforce and HubSpot.

The HubSpot "ceiling" that most small and medium businesses are unaware of is the limit of the data model that can be created within the association feature, as well as the limit of the workflow builder to create automation processes. Therefore, HubSpot would likely not be the best choice for organizations that require custom objects on contacts, accounts, etc. that cannot be related out via the association feature, as well as organizations that have process automation that cannot be automated beyond a certain point within the workflow builder.

Beyond generic CRM solutions, many industries are served by industry-specific CRM solutions, meaning a CRM for a specific branch of business (e.g. for real estate, for financial services, for non-profits). In such industries there is often a market leader that is used by a large market share of customers. This can be highly interesting to companies from said industries, because they profit from a huge and active community of users that also works in their field of business. This community not only uses the core functions of said CRM, but often also develops additional features in the form of add-ons, that already have been fine-tuned by the community for the specific branch of business and thus can be used "out of the box" and integrated via a large number of already existing connections to other tools that are also used by said community.

Do not pick a CRM based on how peers use it. Map out the business's data model requirements, the number of integrations needed to automate, and then compare that to the architecture of each of the major CRM solutions on the market. Pick the solution that handles the most complex process at hand without requiring custom development - even if it costs more per seat.

Frequently Asked Questions

What are the 4 types of CRM?

CRM systems are commonly organized into operational, analytical, collaborative and strategic categories, though different frameworks group them in different ways depending on industry focus and use case.

Which CRM is best for beginners?

HubSpot's free version of the CRM is 100% free and very easy to use.

How much does CRM implementation actually cost?

Typically the cost of the CRM itself is only part of the total investment. Many companies are surprised by the amount of work required to integrate their CRM system with the other systems that a team uses on a daily basis (e.g. a company's website, marketing automation system, billing system, etc.).

Can I switch CRMs later if I choose wrong?

Yes, but it's painful. Exporting data from a CRM is generally pretty straightforward and is typically delivered in the form of clean CSV files.

What's the difference between cloud CRM and on-premise CRM?

Cloud-based CRMs run on servers provided by the CRM vendor (e.g. Salesforce, HubSpot, Pipedrive etc.). This type of CRM is hosted and primarily accessed by users such as salespeople and marketing managers via a web browser.

Should I hire a consultant or implement the CRM myself?

It will typically be suitable for a small team with simple contact management and deal tracking functionality on a starter plan, and can be set up by the end user with guidance from the onboarding documentation. However, as complexity increases with previous system migration, lead routing complexity, API integrations, custom development etc., it's highly recommended to bring in a consultant.

Gable Innovation is a technology consultancy that helps growing businesses evaluate, implement and get the most from CRM systems like Salesforce and HubSpot. Book a free 30 minutes with us at gableinnovation.com to compare vendors or get a second opinion on your short list or just get some guidance on choosing the right CRM for your business.