Prepared for Cadence

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.

Seat distribution (current vs recommended)

Change summary

5 potential seat change(s) (5 downgrade, 0 upgrade); 9 unchanged.

Action items

Seats to downgrade (5 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.

Recommendations

Per-user activity (90-day window for contacts & calls)

Access drift

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

Super Admins

Health score

75/100 (hygiene pillars) 10 Red12 Amber

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

Top findings

• Red contacts: 23,800 (49.4%) stale (>180d)
• Red deals: 402 (45.7%) open, past close date (of 880 open)
• 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
• Red companies: 160 (2.5%) owned by deactivated users

Data quality

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

contacts — 48,200 records

62 of 78 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 880 open deals are past their own close date. 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.

31 of 39 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

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.

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 emails use 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.

Agent-readiness: workflow collision surface

6 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.

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.