Prepared for Cadence

Health score

74/100 (hygiene pillars) 11 Red12 Amber

• Data Quality: 58/100
• Access Drift: 90/100

Top findings

• Red tickets: 1,240 (62.6%) no owner
• Red contacts: 23,800 (49.4%) stale (>180d)
• Red deals: 402 (49.1%) open, past close date (of 819 open with a close date)
• Red companies: 2,900 (45.3%) stale (>180d)
• Red companies: 1,100 (17.2%) missing name
• Red companies: 1,100 (17.2%) missing domain
• Red contacts: 7,400 (15.4%) missing email
• Red contacts: 7,400 (15.4%) missing lifecyclestage
• Red deals: 95 (3.0%) owned by deactivated users
• Red contacts: 1,240 (2.6%) owned by deactivated users

Automation health: notifications with no recipient

Automation health: owner rotation that can assign nobody

Automation health: workflows reading fields that are always empty

Access drift

Governance hygiene over the portal's users. Severity: Good Watch Act

Super Admins

Data quality

Per-object hygiene signals (read-only counts). Severity: Good Watch Act

contacts — 48,200 records

66 of 82 custom properties on contacts carry no description. Nothing is wrong with the data; the portal's own vocabulary is simply unexplained, which is what makes a field nobody recognises survive for years. This counts the property description the editor shows; the data-entry instructions box beside it is not exposed by the API, and nothing here can be written back.

companies — 6,400 records

35 of 44 custom properties on companies carry no description. Nothing is wrong with the data; the portal's own vocabulary is simply unexplained, which is what makes a field nobody recognises survive for years. This counts the property description the editor shows; the data-entry instructions box beside it is not exposed by the API, and nothing here can be written back.

deals — 3,120 records

At least 402 of the 819 open deals that carry a close date are past it. A further 61 carry no close date at all, so they cannot be counted either way and the figure is a floor rather than a total.

This counts how long a deal has sat in its current stage, and nothing else: a deal here may well have been worked recently. Activity dates are too sparsely filled across portals to qualify it without understating.

33 of 41 custom properties on deals carry no description. Nothing is wrong with the data; the portal's own vocabulary is simply unexplained, which is what makes a field nobody recognises survive for years. This counts the property description the editor shows; the data-entry instructions box beside it is not exposed by the API, and nothing here can be written back.

tickets — 1,980 records

The no-owner count above is at least partly by design: 1 enabled workflow blanks the owner on tickets (Ticket queue: release owner overnight). Records cleared this way are counted here, because they genuinely have no owner and every owner-addressed notification and rotation on them still fails. Confirm the intent before reading this row as neglect.

14 of 18 custom properties on tickets carry no description. Nothing is wrong with the data; the portal's own vocabulary is simply unexplained, which is what makes a field nobody recognises survive for years. This counts the property description the editor shows; the data-entry instructions box beside it is not exposed by the API, and nothing here can be written back.

Duplicate detection is left to HubSpot's native Data Quality tools (Breeze); this section complements them with portable, scored signals that need no Data Hub.

Agent-readiness: workflow collision surface

7 properties are already written by enabled workflows. Before an AI agent is pointed at one of these fields, know that a workflow already sets it on a trigger — an agent and a workflow writing the same property is a collision to resolve first. Read-only: this names the overlap, it does not recommend changing any workflow.

Records enrolled counts records entering those workflows in the window, not property writes: one enrolment may write the field once, several times or not at all. Read it as how hard the automation around a field is running, which is what separates a field many workflows could write from one they actually do.

At least one workflow writes lifecyclestage on an associated record, not on the object the workflow enrols. The collision to resolve is on that associated object.

Agent-readiness: automated write access (blast radius)

3 automated actors already write to this portal without a human in the loop. An AI agent joins these, not an empty portal — know what already acts before adding another. Read-only: this inventories what writes, it does not judge or change any integration.

Seat distribution (current vs recommended)

Change summary

4 potential seat change(s) (4 downgrade, 0 upgrade); 10 unchanged.

Marketing-contact bloat

Marketable contacts that never engage still consume the marketing-contacts tier. Read-only counts; engagement = marketing-email opens or clicks (last 180d).

• Marketable contacts: 22,966
• Idle / never-engaged: 10,371 (45%) — 3,500 never engaged + 6,871 last engaged >180d ago

Marketing-contacts add-on cost (source: HubSpot list (Enterprise marketing contacts, estimate)): current EUR 800/month; after trimming the idle slice EUR 400/month.

Potential saving: EUR 4,800/year (EUR 400/month) if the idle slice is trimmed below the next tier boundary — a renewal-negotiation starting point, not a quote.

Hub-tier fit

Which Enterprise and Data Hub features this portal demonstrably uses, from data the scan already reads. Two limits frame it. Portal-wide Enterprise features come with any Enterprise hub, so dropping the last Enterprise hub loses them all, not only that hub's own. And the most common reasons to hold each product leave no trace in a public API. So this table says what was found, never that a tier is unneeded.

• Workflows: 13 in the portal, enabled and not. Professional allows 300, Enterprise 1,000.
• Marketing contacts: 22,966 marketable. Marketing Hub Enterprise includes 10,000, Professional 2,000; at today's volume Professional would add EUR 1,250/month in contact blocks (EUR list).

Not measurable here, so verify before changing tier. Marketing Hub Enterprise: multi-touch revenue attribution, customer journey analytics, adaptive testing, lookalike lists, email approvals, predictive lead scoring, partitioned assets, hierarchical teams (the teams endpoint lists members, not parents), custom behavioral events and business units (scopes not requested). Data Hub: data sync, datasets used anywhere but workflow enrolment, dedupe and the Data Quality Command Center, Snowflake data share.

Action items

Seats to downgrade (4 user(s))

Currently on a paid seat that exceeds measured activity. Downgrade frees the seat cost without affecting their work.

Orphan sequences to transfer or archive (3 sequence(s), 1 ex-owner(s))

Owned by deactivated or deleted users. They remain visible to active Sales Hub users but have no live owner. Transfer to a current user or archive.

Seat recommendations

Appendix: per-user activity (90-day window for contacts & calls)

Custom-object coverage

Marketing email language tagging

HubSpot matches a subscription type's translation on the **exact** language code an email declares, with no fallback from `nl-nl` to `nl`. One language declared under two codes therefore splits the audience across two translation sets, and a code with no translation defined renders its subscription name, preference centre and unsubscribe text in the portal default instead.

nl is declared under 2 codes — 6 emails, 31,700 sends

1 emails declare no language at all (1,200 sends) — they fall back to the portal default whatever the copy is written in.

“Klantnieuwsbrief” is sent in nl-nl but translated into nl — 3 emails, 6,500 sends. Same language, different code, and HubSpot matches the code exactly: those sends fall back to the subscription's default text and the translation is never used.

Fix by standardising on one code per language, or by defining the subscription-type translation for every code in use.

1 of these email uses smart content (1,800 sends), varying SUBJECT. HubSpot names the smart fields but exposes neither their rules nor their variations, so HubScan cannot read what they swap in. Worth knowing: a smart rule can serve a different language, while the preference centre and unsubscribe text still follow the email's single declared language code — so those readers get one language in the body and another in the footer. Check those emails by hand.

Caveats