Custom CRM vs HubSpot: Test One Customer With Two Live Jobs

When comparing custom CRM vs HubSpot, ask both suppliers to demonstrate one customer with two live jobs, different staff responsible for each and invoices in your accounting software. A tidy demonstration of one enquiry becoming one sale will not tell you whether staff can manage that customer’s actual work.

I would test a configured HubSpot setup before commissioning a custom CRM, but require it to keep each job’s dates, responsibilities and updates separate. If it fails, identify whether the cause is configuration, subscription access, an integration gap or a genuine mismatch with the work.

HubSpot offers more than one possible way to represent jobs. Its documentation describes Projects in the customer success workspace, while custom objects can have their own properties, pipelines and associations. Those options have different eligibility and design implications. The decision is which setup meets your requirements at an acceptable ongoing cost, not whether a demonstrator can create a field called “job”.

Prepare a demonstration brief with two concurrent jobs

Use a real customer example with identifying details removed, or use this illustrative scenario. A maintenance business has one customer, Oak House, with two active jobs: a boiler replacement and a ventilation installation. Each has a different coordinator, appointment date, stage and invoice reference. Both share the same customer contact.

During the demonstration, the customer changes their phone number, postpones only the boiler appointment and asks a billing question about the ventilation installation. The person answering the phone must find the right information without consulting a separate spreadsheet.

Before the session, specify:

• Customer information: the shared contact details and the system where corrections should be made.
• Job information: the reference, owner, stage, appointment date, next action and relevant notes for each job.
• Staff responsibilities: what the receptionist, job coordinators, accounts staff and manager must see or change.
• Accounting hand-off: where invoices originate, how staff identify the relevant job and which payment information they need.
• Operating conditions: your usual number of open jobs, frequency of changes and acceptable delay before updates appear elsewhere.

Ask for the demonstration in the proposed subscription and configuration, with ordinary staff accounts as well as an administrator account. This makes a HubSpot workflow evaluation much more useful than a tour of features available somewhere in the product range.

Require an explanation of what a job is in HubSpot

One customer should not need a duplicate contact record simply because they have two jobs. The proposed design needs to explain how shared customer information connects to distinct job records.

Deals: test the boundary between selling and delivery

If the proposal represents each job as a deal, ask the implementer to demonstrate both records associated with the customer. Then test what happens after the sale: where delivery dates, operational stages, notes and staff responsibilities live, and how sales reporting remains meaningful.

This may be a sensible configuration for your work. The warning sign is staff having to reinterpret sales fields, overwrite information from another job or maintain a separate operational spreadsheet to know what happens next.

Projects: verify the actual account and workspace

HubSpot’s customer success workspace documentation describes Projects for project-management information and processes, with pipeline views, filters and associated records. It also describes different object options depending on when the account was created.

Ask the supplier to show the option available in your account, the subscription required to use the proposed workspace and how staff would work in it. A reference to “Projects” in a proposal is not enough to establish the complete design.

Custom objects: establish why standard records are insufficient

A custom object is a separate type of record defined for the business, such as a job with its own fields and relationships. HubSpot documents support for properties, pipelines, associations, workflows and reports for custom objects. Availability is tied to specified Enterprise subscriptions, with subscription-dependent limits.

HubSpot also advises checking whether a standard object is sufficient before creating one. Ask what a custom Job object solves, which reports and automations it supports, and what subscription commitment it introduces. More flexibility is useful only if it resolves a requirement you actually have.

Run the same acceptance test in both options

An acceptance test states what staff must be able to do and what counts as success. Give the following script to the HubSpot implementer and any custom CRM supplier.

• Create both jobs. Associate them with the same customer, assign different coordinators and enter separate dates and stages. Staff must be able to identify both jobs from the customer record.
• Change shared information. Update the customer’s phone number. Show where it must be edited and how staff working on either job see the corrected value.
• Change one job. Postpone the boiler appointment and change its stage. The ventilation job’s date, stage and next action must remain unchanged.
• Record an update. Log a call about ventilation billing. Show how the user attaches it to the right job and how another member of staff finds it later.
• Trigger the next action. Change a job’s stage and demonstrate any promised task, notification or follow-up. Repeat the action to check whether it creates unwanted duplicates.
• Use each staff role. Have the receptionist find both jobs, each coordinator manage their assigned work and accounts staff find billing details. Test any restriction on viewing or editing information rather than assuming an owner field provides access control.
• Produce the working report. Show upcoming appointments and overdue actions by coordinator. Staff should not need an export to reconstruct which job each row concerns.

Ask the people who will use the system to perform these steps themselves. A supplier navigating quickly through an administrator account does not demonstrate that a receptionist can reliably attach a note to the right job.

For a custom CRM, require the same behaviour in the specification and acceptance criteria. A screen sketch showing two job cards does not establish permissions, reporting, automation or reliable updates.

Test accounting at job level, not just customer level

An integration can link the correct customer while leaving staff unable to distinguish that customer’s two invoices. Use sample invoices for both jobs and follow them through the proposed connection.

For QuickBooks Online, HubSpot’s integration documentation describes syncing contacts/customers, invoices and products in one or both directions, with field mappings and a selected conflict-resolution source. It states that HubSpot changes are detected within a few minutes and QuickBooks Online changes every 30 minutes, with on-demand sync also available. Do not design a phone-handling process that silently assumes every accounting change appears immediately.

The same documentation says invoices synced from QuickBooks Online are associated with the contact’s primary company where one exists. That customer-level association does not, by itself, prove that the invoice is attached to the correct job.

Ask the implementer to show:

• Where the job reference is stored and whether it transfers with the invoice.
• Which system owns customer details, invoice values and payment status.
• What happens when a shared field is changed in both systems.
• How an incorrect association is corrected without creating another invoice.
• Who notices a failed sync, who fixes it and how they check that retrying has not duplicated data.

The QuickBooks Online integration listing describes sync-health reports and alerts for failed records. It also lists Operations Hub Starter or above as a requirement for custom invoice, contact or product field mappings. Have the proposal name the subscription that supplies those mappings in your account.

If you use different accounting software, require the same demonstration for that connector. For a bespoke connection, require the developer to specify supported records, access permissions, transfer timing, failure handling and ongoing monitoring. “API integration included” is not an adequate description of that work.

Record the result in a comparison worksheet

Use one worksheet for both proposals. Create a row for every requirement, such as “change one appointment without changing the other” or “identify the job belonging to this invoice”. For each row, record:

• Acceptance result: passed, failed or not demonstrated, with the observed behaviour.
• HubSpot implementation: the object, configuration, workflow or connector that meets it.
• Required access: the Hub, subscription tier, seats, permissions and relevant limits.
• Additional work: setup, data migration, integration, training and reporting.
• Custom equivalent: the records, screens, rules, permissions and connection the developer must deliver.
• Ongoing ownership: who administers changes, monitors failures and provides support.
• Cost: recurring subscriptions and support, plus implementation and future change costs, quoted separately.

For any bespoke connector, add a documentation check for the required API access, permissions and usage limits under the proposed account. For automations, require the supplier to name the subscription entitlement and demonstrate the intended trigger and action. Do not accept a generic assurance that HubSpot “has workflows”.

This prevents an uneven comparison between a fully priced HubSpot implementation and a custom build estimate that covers only the visible screens. Equally, it exposes a HubSpot proposal that excludes the integration or administration needed to make the demonstration work in practice.

Choose based on the requirement that remains unresolved

In the illustrative maintenance business, suppose HubSpot keeps both jobs distinct, gives coordinators usable daily views and connects invoices in a way accounts staff can reconcile. If it passes those tests on an acceptable subscription with manageable administration, there is no demonstrated need to rebuild the whole CRM.

Now suppose each job requires a scheduling and approval process that the proposed setup can support only through repeated duplicate entry and a separate spreadsheet. First ask whether a different configuration or integration removes that work. If it cannot, that specific requirement supports evaluating a connected internal tool or custom software, rather than treating every CRM function as something to replace.

A custom CRM may represent the customer, jobs and billing references more directly. It also needs someone to maintain access controls, integrations, backups, hosting and future changes. Ask who owns those responsibilities and what support is included before treating flexibility as a decisive advantage.

For the wider ownership and purchasing decision, see Custom CRM vs Off-the-Shelf CRM: Buy, Configure or Build? Here, the decision rule is narrower: choose the smallest maintainable setup that passes your actual customer-work test. Commission custom development when you can name the important requirement that sensible HubSpot configuration and integration still leave unresolved.