A consultancy connected its projects, clients, and invoices in one CRM for the first time

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

This consultancy delivers digital-transformation programmes for mid-market clients — discovery, implementation, and managed delivery run by a delivery team that lives in its project-management tool, and an operations lead who owns client data with real care. Commercial life happens elsewhere: client records sit in a CRM nobody enjoys, projects in the PM tool, invoices in accounting software. Engagements run for months and renew annually, so a client relationship stretches across renewals, team changes, and years of delivered work that no single system can currently show.

What it was costing

Clients lived in the CRM, projects in a PM tool, invoices in accounting software. The renewal question — which clients were due, who owned them, what was delivered last year — took a researcher and a day. Churned clients were discovered when invoices bounced.

What they could see

• Answering which clients renew this quarter and what was delivered to them takes an operations person most of a working day.
• Churned clients have been discovered when their renewal invoice bounced — the first signal arrived from accounting, not from delivery or account management.
• Account managers preparing client reviews ask delivery leads to reconstruct timelines from the PM tool by hand.
• Client records in the CRM and project records in the PM tool disagree about who the client even is, because both were entered by hand.

The constraints we worked inside

• The PM tool stayed — teams live in it; the CRM had to reference projects, not swallow them.
• Finance data was sensitive; invoice visibility needed role boundaries the CRM had to enforce.
• The operations lead owned the data and had zero tolerance for duplicate client records.

What had been tried before

The operations lead built a monthly export-and-merge workbook joining the CRM, the PM tool, and the accounting system.

The join was correct on the day it was run and wrong the day after; renewals kept surprising people because the workbook always looked backward.

An integration-platform subscription was bought to sync clients and projects between the CRM and the PM tool.

Syncs failed silently whenever a record was renamed, and the failures created exactly the duplicate clients the operations lead had feared.

Delivery leads were asked to paste a project link and a status line into each client record quarterly.

Compliance was voluntary and uneven — some clients had rich context, some a bare URL, and nothing distinguished diligence from optimism.

What we proposed

The design links the three systems instead of merging them: custom objects in the CRM represent each engagement, connected to client records on one side and to live PM-tool projects and invoicing records on the other. The account timeline then shows the whole relationship — conversations, delivered projects, invoice status — without asking delivery teams to leave the tool where they actually work. Engagements carry end dates, and anything ending within ninety days surfaces on a renewal radar with delivery context attached. Import and integrations run through dedupe matching first, because the operations lead's standard was explicit: not one duplicate client record, ever.

Just as important is what we ruled out, and why:

• Moving project tracking into the CRM — Delivery teams live in the PM tool and would treat a CRM-based tracker as reporting theatre; the data would go stale within weeks.
• A data-warehouse reporting layer — It could answer the renewal question but not where account managers work, and the firm had nobody to maintain a warehouse.
• A custom internal portal — A hand-built portal needs ongoing development the consultancy cannot justify for an internal tool; configured integration beats bespoke software here.

How the work ran

Delivered by the systems pod — engineer + automation specialist over 9 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

HubSpot CRM

The relationship system of record had to sit where renewals, contacts, and commercial context already converge; it was the natural spine for the account view.

Custom objects

Engagements are relationships with dates and deliverables, not notes; modelling them as objects is what makes a renewal radar possible at all.

PM-tool integration

Delivery teams keep their tool and their habits; the CRM references live projects rather than demanding copies that rot.

Role-based visibility

Invoice detail is finance's business; consultants need delivery context without exposure to commercial terms their roles should not see.

Dedupe routines

The operations lead's zero-tolerance standard made matching on import non-negotiable, with a review queue for the near-matches automation cannot settle.

What went wrong

How we worked together

Cadence

A Wednesday working session with the operations lead through the build, a fortnightly demo to account managers, and a permissions review with finance at each visibility change.

Client side

The operations lead owned the data model with an effective veto; a delivery lead advised on what the PM-tool link needed to show.

Decisions

Schema disputes were settled by the operations lead against her dedupe standard; permission questions went to finance and were answered in writing.

They provided

PM-tool admin access, structured exports from the accounting system, and the sample client list used to tune the dedupe matcher before real imports.

What changed

The headline: time to answer 'what did we deliver this client this year, and when do they renew?' — 1 day → 10 min, read from Ops time study before/after. A second check: renewals entered the 90-day radar (2 were previously missed entirely) at 100%.

Client reviews start from the timeline instead of an archaeology exercise, and account managers ask delivery questions in the meeting rather than by email beforehand. The operations lead stopped living in fear of duplicates because the queue shows her what it is unsure about. Renewals arrive as conversations with ninety days of runway instead of invoices that bounce — the firm learned about a churned client from its own radar, once, and never again from accounting.

The result was read from Ops time study before/after against the pre-engagement baseline over the stated window, with a guardrail check on renewals entered the 90-day radar (2 were previously missed entirely). Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The full object-schema documentation — engagements, links, and the lifecycle fields the radar depends on.
• The nightly reconciliation job with its failure alerting, owned by the operations lead.
• A dedupe review queue with a written SOP for near-match decisions.
• The permissions matrix, signed off by finance, showing who sees what and why.
• A renewal-radar dashboard with the 90-day rule configurable by the ops team.