Shared portal vs. local needs
A local request can change forms, workflows or reports used by the whole group.
Executive summary
One portal. Shared guardrails. Local execution.
A shared HubSpot account can give a company group one view of contacts, companies, campaigns, leads, deals and revenue. The same setup also creates a structural risk: every field, workflow and permission decision can affect several businesses at once.
Core thesis
A group-wide CRM implementation is not primarily a software project. It is the introduction of a shared data, process and governance model that still leaves room for local brands, audiences and sales motions.
| Design decision | Recommended principle |
|---|---|
| Data model | Use shared standard objects and one governed property catalogue. |
| Assignment | Use Operating Company as the consistent cross-object assignment logic. |
| Qualification | Measure engagement centrally and commercial fit per Operating Company. |
| Handover | Create the HubSpot Lead object when a record is ready for active sales work. |
| Change | Route structural changes through a central decision and feedback process. |
Framework in one sentence
Standardise data, reporting, lifecycle definitions and governance centrally; keep ICP criteria, campaigns, brand execution and day-to-day lead handling locally adaptable.
01 · The group-wide CRM challenge
Why a shared rollout is fundamentally different
Multiple teams share one portal, but they rarely start with the same processes, data quality, brand structure or level of CRM maturity.
Common reporting vs. different motions
The same lifecycle must support long enterprise cycles and faster transactional motions.
Transparency vs. protection
Teams need collaboration and cross-sell visibility without accidental changes to another company’s records.
Speed vs. governance
Decentralised creation feels fast initially, but duplicates and inconsistent logic make the portal slower over time.
Leadership must answer five questions before configuration starts
What must be identical?
What may vary locally?
Which system is authoritative?
Who approves structural change?
What defines success?
The common failure pattern
Teams begin configuring forms, properties and workflows before agreeing on the data model and change process. The portal works technically, but nobody can explain which structure is authoritative or who owns it.
02 · Governance, not uniformity
Centralise the system of record—not every local motion
Standardise wherever data, reporting and cross-company collaboration are at stake. Stay flexible wherever audience, brand, language and sales motion genuinely differ.
Standardise centrally
- Data model and property governance
- Lifecycle stages and object definitions
- Consent and subscription logic
- Naming conventions and reporting foundations
- Lead and deal object logic
- Testing, documentation and change process
Keep locally flexible
- ICP criteria and fit scores
- Campaign content and brand assets
- Form, email and landing-page design
- Languages and local messaging
- Sales routing and day-to-day lead handling
- Channel mix and campaign cadence
Decision rule
A local exception is justified when it changes how a company goes to market. It is not justified when it merely creates another way to store the same fact.
03 · Governance operating model
Give every structural decision an owner
Governance becomes operational only when roles, decision rights and escalation paths are explicit.
| Role | Primary responsibility |
|---|---|
| Group CRM Owner | Architecture, standards, decision log and final approval for structural changes. |
| Marketing Operations | Campaign, automation, segmentation, scoring and reporting standards. |
| Operating Company Lead | Local requirements, adoption, campaign execution and data-quality feedback. |
| Sales Operations | Lead, deal, pipeline and sales-handover design. |
| Data Owner | Migration, duplicate rules, mappings, consent evidence and remediation. |
| System Administrator | Permissions, teams, technical settings and platform maintenance. |
A practical change process
SubmitState the business purpose, affected object and reporting impact.
ReuseCheck whether an existing property, workflow or template already covers the need.
AssessReview data, automation, permissions and reporting impact.
DecideApprove, reject or redesign the request through the named owner.
DocumentRecord the outcome and communicate the standard to every Operating Company.
Non-negotiable governance rules
New properties are centrally reviewed. Lifecycle stages are not changed locally. Workflows have an owner. Naming conventions are shared. Feedback enters one ticket or approval process instead of side conversations.
04 · Target architecture
Use one object model with a consistent assignment layer
Every Operating Company should work with the same core objects, while one governed assignment field connects local activity to the shared CRM architecture.
Operating CompaniesLocal brands, markets and offers
Shared data modelContacts, companies, campaigns and consent
Engagement scoreGroup-wide behavioural signals
Fit scoreOperating Company-specific ICP logic
Lead & dealOperational sales qualification
Operating Company as the assignment backbone
Apply one governed Operating Company property consistently across relevant objects. Use it for views, segmentation, workflows, campaign assignment, reporting, lead routing and migration mapping.
Core CRM objects
Contacts, companies, leads and deals share common definitions and associations.
Marketing objects
Campaigns, events, forms, segments and emails use a consistent operating structure.
Governance layer
Properties, ownership, permissions and change control make the architecture sustainable.
05 · Property governance
Stop duplicates before they become technical debt
Fields such as Company Size, Employee Range, Number of Employees and Organisation Size may describe the same concept while creating conflicting reporting logic.
| Required definition | Question to answer |
|---|---|
| Object | Does the value belong on the contact, company, lead, deal or another object? |
| Business purpose | Which decision, automation or report needs the field? |
| Internal name | Is the technical name stable and understandable? |
| Field type | Should the value be text, number, date, dropdown or multi-select? |
| Allowed values | Are labels and internal values standardised? |
| Source and owner | Who supplies the data and who maintains the definition? |
| Dependencies | Which workflows, forms, integrations and reports use it? |
Property request test
Create a new field only when the business concept is genuinely new, no governed property already covers it, and the owner can explain how the value will be populated and maintained.
06 · Migration, consent and historical data
Separate technical migration from marketing activation
A successful import is not the same as a compliant and usable marketing database. Contacts should not become marketable merely because their technical record exists in HubSpot.
Prepare
Inventory source systems, map fields, define duplicate rules and identify missing identifiers.
Validate
Run a test migration and verify ownership, associations, dates, consent and Operating Company assignment.
Activate
Assign subscriptions and activate marketing processes only after the underlying evidence is validated.
| Workstream | Minimum control |
|---|---|
| Data quality | Validate email addresses, company names, Operating Company assignment and duplicate logic. |
| Consent | Confirm evidence, lawful basis, subscription purpose and opt-out history before activation. |
| Subscriptions | Assign communication types only after the relevant purpose has been defined. |
| Suppression | Create lists for contacts that must not receive marketing communication. |
| Historical events | Create the event first, store start and end dates separately, then import one attendee file per event. |
Historical event rule
When legacy statuses do not map cleanly to Invited, Registered, Attended, Cancelled or No-show, document the mapping and data gaps. Do not manufacture precision the source system does not contain.
07 · Marketing asset architecture
Build reusable campaign systems, not isolated assets
Campaigns should become the organisational container for forms, landing pages, emails, segments, ads, social posts, events, workflows and download assets.
Naming
Combine Operating Company, language, channel, campaign type, topic and time period where relevant.
Templates
Duplicate governed templates instead of rebuilding every form, email or workflow from scratch.
Languages
Use dedicated language versions so labels, consent text, errors and confirmations remain clear.
Branding
Allow local logo, colour and content variations without changing the underlying global structure.
Campaign association
Connect every relevant asset so reporting and attribution remain coherent.
Ownership
Give each reusable automation and template an accountable owner and review date.
Example naming convention
OPCO-A | EN | Email | Lead Generation | CRM Leaders | 2026. Keep the convention consistent, but use understandable abbreviations before names become unusably long.
08 · Lifecycle and marketing-to-sales handover
Separate journey status from the operational sales queue
Lifecycle stage describes where a contact stands in the commercial journey. The Lead object determines when Sales actively works the record.
ContactCreated through form, import, event or integration
Engagement ScoreShared behavioural model
MQLMeaningful marketing engagement
Fit ScoreLocal ICP assessment
Lead ObjectActive sales work begins
SQLSales confirms commercial relevance
OpportunityConcrete deal is created
| Stage | Definition |
|---|---|
| Contact | A person created through a form, import, event, integration or manual entry. |
| MQL | A contact that has reached the agreed level of meaningful marketing engagement. |
| Fit Score | A local assessment of how well the contact and company match the Operating Company’s ICP. |
| Lead object | The operational sales-work record connecting the contact and company in the sales workspace. |
| SQL | A lead manually reviewed by Sales and confirmed as commercially relevant. |
| Opportunity | A concrete sales chance for which a deal is created and actively progressed. |
Important distinction
A contact can be an MQL without a Lead object having been created. Lifecycle stage describes journey status; the Lead object controls active sales work and its own pipeline.
09 · Engagement and fit scoring
Score behaviour centrally and commercial relevance locally
Actions such as form submissions, clicks, downloads and event attendance are comparable across the group. Commercial relevance depends on each Operating Company’s target market.
Shared model
Engagement Score
- Comparable across Operating Companies
- Measures behaviour and intent signals
- Lower maintenance and consistent thresholds
- Useful for MQL assignment
Local model
Fit Score
- Weighted for one Operating Company’s ICP
- Measures company and contact characteristics
- Requires local ownership and refinement
- Useful for prioritisation and Lead creation
Calibration loop
Start with a simple model, test it against real contacts, inspect false positives and false negatives, adjust the criteria, then review performance on a fixed cadence.
10 · Lead-handling models
Choose the handover model based on volume and data quality
Technical feasibility should not determine the process. The right model depends on data quality, the reliability of ICP criteria and the cost of sending poor-fit records to Sales.
Inbox review
A form notification goes to a shared inbox. Marketing or Sales reviews the record before creating a Lead object.
Best fit: Low volume or inconsistent data quality.Automated creation
HubSpot creates a Lead object when engagement and local fit conditions are met.
Best fit: Higher volume and validated ICP rules.Direct routing
High-intent forms such as demo, quote or callback requests route immediately.
Best fit: Clear hand-raiser intent with an agreed owner.
Automation gate
Validate the process manually before automating it. Automation does not improve a weak qualification rule—it only sends the wrong records to Sales faster.
11 · Reporting and attribution
Design reporting before the portal goes live
Group-wide reporting works only when objects, properties and campaign associations are consistent. Every dashboard should answer a business question and use documented filters.
Group-level measures
- New contacts, MQLs, Leads, SQLs and Opportunities
- Marketing-sourced and influenced pipeline
- Conversion rates across the lifecycle
- Lead response time and handover efficiency
- Deal and revenue attribution
Operating Company measures
- Campaign and form performance
- Content downloads and event attendance
- Email and subscription performance
- Source mix and audience engagement
- MQL-to-SQL conversion by local motion
Reporting contract
Every report needs an owner, a defined business question, a date range, documented filters and a clear source object. If teams cannot explain the logic, the metric is not governable.
12 · Permissions and data visibility
Do not confuse filtered views with access control
Views and filters improve everyday navigation, but they do not automatically prevent users from finding or editing records outside their normal workspace.
| Decision question | Governance response |
|---|---|
| Who may view records from another Operating Company? | Define the business reason and the record stages where transparency is needed. |
| Who may edit those records? | Restrict editing more tightly than viewing wherever the platform and ownership model allow it. |
| When does cross-company visibility become useful? | Consider wider access after a customer, opportunity or cross-sell trigger exists. |
| How are mistakes detected? | Use ownership, audit history, controlled views and clear escalation. |
| How are exceptions approved? | Document them centrally rather than granting ad-hoc access. |
Risk to manage
The concern is not only confidentiality. In a shared portal, a well-intentioned user can change another Operating Company’s lifecycle, owner, lead stage or deal data by mistake.
13 · Testing, enablement and rollout
A configured portal is not an implemented operating model
The MVP should be tested through real business scenarios before broad automation or rollout. Feedback must enter one central pipeline so local requests cannot silently change the group architecture.
| Test area | Evidence required |
|---|---|
| Forms and consent | Submission, validation, consent copy, confirmation and data storage work as intended. |
| Email and delivery | Notifications, personalisation, download links and subscription logic are correct. |
| Segmentation | Operating Company and consent filters include and exclude the expected records. |
| Handover | Lead creation, owner, notification, response and disqualification paths are clear. |
| Reporting | Campaign, form, lifecycle and attribution metrics reconcile with test activity. |
| Permissions | Users can perform their role without unintended changes to other teams’ data. |
Test
Run realistic scenarios using representative records and channels.
Enable
Train each role on the tasks they will actually perform.
Refine
Prioritise defects, merge duplicate requests and improve the shared model deliberately.
Definition of done
The implementation is complete only when teams can work independently inside the agreed guardrails, every critical process has test evidence, and a documented change process exists for what comes next.
14 · Reference roadmap
Move from alignment to controlled adoption
The exact duration depends on data volume, integrations, scope and decision speed. The sequence should remain stable: decisions before configuration, pilot evidence before automation.
Alignment completeScope, governance roles, success measures and escalation path approved.
Architecture completeObjects, properties, consent, lifecycle, Operating Company and permissions documented.
MVP completeCore forms, campaigns, workflows, scoring and dashboards ready for test.
Pilot completeEnd-to-end scenarios passed and defects prioritised.
Rollout approvedOwners trained, documentation published and support model active.
Common failure modes
| Failure mode | Countermeasure |
|---|---|
| Treating HubSpot as a configuration project | Start with operating-model decisions and accountable owners. |
| Allowing each Operating Company to create properties | Use one property catalogue and a central approval process. |
| Changing lifecycle definitions during local discussions | Maintain one shared glossary and formal decision log. |
| Importing before data and consent are ready | Separate migration, subscription assignment and activation. |
| Automating routing before manual validation | Pilot the process and measure false positives first. |
| Using views as a substitute for permissions | Design access, ownership and edit rights explicitly. |
| Building reporting after go-live | Define required KPIs while designing objects and campaigns. |
15 · CRM implementation readiness checklist
Can the group begin configuration safely?
Score each statement: 2 = complete, 1 = partly complete, 0 = not started. The result updates instantly.
01
The group has agreed the strategic outcomes and project scope.
02
A Group CRM Owner and decision forum are named.
03
Central and local decision areas are documented.
04
Core objects and lifecycle definitions are approved.
05
Operating Company assignment is defined across objects.
06
A governed property catalogue exists.
07
Migration mappings and duplicate rules are documented.
08
Consent, subscription and suppression rules are approved.
09
Marketing-to-Sales handover ownership is explicit.
10
Engagement and fit scoring are separated conceptually.
11
Permissions and cross-company visibility are decided.
12
Pilot tests, enablement and support processes are planned.
0 / 24
Align the operating model first
A score of 0–13 indicates that governance and architecture should be prioritised before configuration expands.
Conclusion
The objective is scalable coordination, not identical companies
A successful group-wide HubSpot implementation creates one reliable system of record and a shared language for marketing and sales. It does not force every Operating Company into the same campaign, brand or sales motion.
Shared foundations
Data, lifecycle, consent, reporting and governance remain group-wide.
Local relevance
ICP, fit, brand, campaign execution and routing remain adaptable.
Controlled evolution
Manual validation, documented ownership and structured feedback prevent technical debt.
Final takeaway
Governance gives local teams more freedom—not less—because they can execute quickly without rebuilding the underlying system or creating new technical debt.
