From duplicate Contacts to a scalable Deal-based CRM
A growing service business was managing customer information and individual service plans through HubSpot Contact records. As clients began purchasing multiple services, the structure created duplicate profiles, fragmented histories and increasingly complex reporting.
I redesigned the CRM around a clearer model:
One customer = one Contact.
One service or plan = one Deal.
The project included CRM architecture, duplicate cleanup, historical data migration, custom Deal properties and cards, workflow redevelopment, reporting rebuilds and team training.
CRM Architecture · Data Migration · Automation · Reporting · Data Quality
The existing HubSpot setup had evolved around Contact records.
Sales information and ongoing Client Success information were largely stored against the Contact. This worked when a customer had one straightforward service, but it became increasingly difficult when clients purchased multiple plans.
A single customer could have a Virtual Assistant plan, a Marketing Manager plan, additional team members, different start dates, different package values, upgrades, downgrades or individual services that ended while others remained active.
To separate these services, multiple Contact profiles could be created for the same real person. In some cases, email variations such as aliases were used simply to create another HubSpot profile for the same customer.
Over time, this contributed to:
- Duplicate customer records
- Fragmented communication histories
- Information spread across multiple profiles
- Email bounce and deliverability issues
- Confusion around the correct customer record
- More complicated workflows
- Repeated manual administration
- Reporting that became harder to manage
- Difficulty distinguishing between a lost service and a lost customer
The problem wasn't one faulty workflow.
The CRM structure itself needed to change.
I redesigned the CRM around a simple operating principle:
One customer = one Contact
One commercial service = one Deal
The Contact became the central customer record, while each individual service was represented by its own Deal.
A customer could therefore have:
Deal 1 - Virtual Assistant - Active
Deal 2 - Marketing Manager - Active
Deal 3 - Additional VA - Closed
If one service ended, that Deal could close independently while the customer's other services remained active.
This allowed HubSpot to reflect the way the business actually sold and delivered its services.
1. Sales process
Moved the commercial Sales process into Deals so that each opportunity and service could be managed independently.
Deal-level information included ownership, service type, contracted hours, commercial value, consultation information, proposal status and pipeline stage.
2. Deal architecture
Created and reorganised the properties required to manage each service throughout its lifecycle, including:
- Product or service
- Hours
- Package value
- Rates and currency
- Contract information
- Assigned delivery team
- Onboarding
- Add-ons
- Upgrades
- Downgrades
- Service changes
- Closure
3. Record experience
Rebuilt HubSpot cards and sections so Sales and Client Success could quickly see and maintain the information relevant to the individual service.
Legacy Contact-side fields and cards were retired where appropriate to prevent teams from continuing to use both systems.
4. Duplicate cleanup
Reviewed duplicate customer records and consolidated them where appropriate so that customer history could live against one central Contact.
Instead of:
Contact + Contact +1 + Contact +2
the model became:
One Contact → Multiple Deals
5. Historical migration
Migrated existing and historical client plans into the revised Deal structure rather than applying the new model only to future sales.
This included creating the required Deals, mapping existing commercial information into the new properties and associating each service with the correct customer.
6. Reporting & automation
Rebuilt workflows, notifications, reports and dashboards around Deal-level information.
This meant that operational updates could relate to the correct service and reporting could distinguish between the customer and the individual revenue-generating plans they purchased.
One Update. Multiple Automated Actions
Once the Deal structure was in place, HubSpot could become the operational source of truth rather than simply another place where information had to be re-entered.
A single Deal update could drive the next actions across the business.
For example, a Client Success Manager updating a plan change could support:
- Internal team notifications
- Onboarding or handover actions
- Operational updates
- Revenue and churn reporting
- Dashboard changes
- More consistent follow-up
The principle was simple:
Enter the information once. Use it everywhere.
This reduced the need for teams to repeatedly update HubSpot, send separate emails, leave manual notes and re-enter the same information into reporting sheets.
Supporting the Full Customer Lifecycle
The redesigned structure continued beyond the initial sale.
Each individual service could move through:
Sale → Onboarding → Delivery → Account Management → Re-onboarding → Upgrade / Downgrade → Closure
while the Contact remained the central customer record.
This was particularly important when a client had several services.
If one plan was downgraded or cancelled, the change could be recorded against the correct Deal without incorrectly treating the whole customer as lost.
Team Training & Adoption
The implementation did not end with the technical build.
I presented the new flow to the teams and trained users on:
- When to create a Deal
- Where Sales information belonged
- Where Client Success information should be updated
- How multiple client plans should be managed
- How upgrades and downgrades should be recorded
- How property updates affected workflows and reporting
- Which parts of the previous Contact-based process should no longer be used
I also created supporting process and handover guides so that the new structure could continue to be used consistently.
The redesigned CRM more accurately reflected how the business actually operated.
Before
Multiple services could require multiple customer profiles.
This contributed to:
Duplicate records → fragmented histories → email workarounds → complicated reporting → repeated administration
After
One Contact represented the customer.
Each service had its own Deal with its own:
Service · Value · Hours · Start Date · Assigned Team · Status · Upgrades · Downgrades
The new structure created a stronger foundation for:
- Cleaner CRM data
- Consolidated customer histories
- Better handling of clients with multiple services
- More accurate plan-level reporting
- Improved upgrade, downgrade and churn tracking
- Better Sales-to-Client-Success continuity
- More reliable workflow automation
- Less repeated data entry
- Better internal visibility
- More scalable CRM processes
I led the HubSpot process redesign and implementation, translating operational requirements from Sales and Client Success into a more scalable CRM model.
CRM architecture · Deal and property design · Record customisation · Historical migration · Duplicate cleanup · Workflow redesign · Reporting rebuilds · Process documentation · User training