SME Marketing Automation Onboarding Scope in 2026

Most SME marketing automation onboarding engagements go wrong for the same reason: the scope was never properly defined before the work started.

The kickoff happens. Decisions that should've been made in week one get made in week five. Integrations that were assumed to be straightforward turn out to require custom development. Training happens after go-live rather than before it. And by the time the engagement wraps up, the business has a configured portal and a team that's not quite sure what to do with it.

Good scoping prevents all of that. This guide maps out exactly what a well-scoped SME marketing automation onboarding looks like in 2026 -the discovery outputs you need before building starts, the data model and integration plan, the training structure, and the acceptance criteria that tell you when the engagement is actually done.

What Scoping is Not

Before getting into what the scope should include, it's worth being clear about what scoping isn't.

Scoping isn't a timeline. A timeline tells you when things will happen. A scope tells you what will happen, who's responsible for it, and what done looks like.

Scoping isn't a features list. "HubSpot Marketing Hub Professional" isn't a scope. It's a product. The scope describes what you'll configure within that product, for what purpose, and to what standard.

Scoping isn't a discovery session. Discovery is an input to the scope. What comes out of discovery - the decisions made, the architecture agreed, the requirements documented - is what the scope is built on.

When a prospective onboarding partner gives you a timeline and a features list and calls it a scope, ask them for the rest.

Phase One: Discovery Outputs

Discovery is the phase that determines whether everything else goes smoothly or not. The deliverables from a properly run discovery phase are specific and should be produced in writing before any configuration begins.

The current state assessment

A documented snapshot of where the business is now: which tools are currently in use and what they do, how leads currently enter the system and what happens to them, how the sales team manages their pipeline, where customer data currently lives, and which processes are manual that should be automated.

This isn't a casual conversation. It's a structured review that should involve marketing, sales, and whoever is responsible for customer service or account management. Each function has different requirements from the CRM and they should all be surfaced in discovery rather than discovered mid-implementation.

The agreed data model

Before any configuration starts, the following should be documented and signed off:

Object structure. Which HubSpot objects will be used - Contacts, Companies, Deals, Tickets - and how they relate to each other. If custom objects are required (Enterprise plans only), they should be identified and their relationship to standard objects mapped.

Lifecycle stage definitions. What does a Lead, MQL, SQL, and Opportunity mean for your specific business? What are the objective criteria for moving a contact between stages? These definitions need to be agreed between marketing and sales - not decided by the onboarding partner -because they drive everything downstream.

Pipeline stage design. What are the deal stages in your pipeline, what's the entry criterion for each, and what data should be captured at each stage? On HubSpot Professional and Enterprise, required properties enforce data capture at stage gates - these should be identified in discovery, not after the pipeline is built.

Custom properties required. Which contact, company, and deal properties need to be created that don't exist in HubSpot's default set? Identify the property type (dropdown, single-line text, date, number) and the values where applicable.

The integration map

Every external system that needs to connect to HubSpot should be identified in discovery and assessed as either a native HubSpot marketplace integration or a custom integration requirement.

The integration map should include: the name of each system, the direction of the data flow (HubSpot to external, external to HubSpot, or bidirectional), the specific data that needs to sync, and the trigger for the sync (real-time on event, scheduled batch, or manual).

Systems to assess in discovery for a typical ANZ SME:

• Email and calendar (Gmail or Outlook - foundational, always included)
• LinkedIn, Google Ads, Meta Ads (if running paid media)
• Accounting software (Xero, MYOB, QuickBooks - common in the ANZ market)
• Customer support or ticketing tools (Zendesk, Intercom, Freshdesk)
• Video conferencing (Zoom, Google Meet, Microsoft Teams for meeting scheduling integration)
• Industry-specific tools (any proprietary or sector-specific software)

Custom integrations that aren't available as native HubSpot marketplace connectors should be explicitly out of scope unless a custom development budget and timeline is agreed separately.

Phase Two: Build Scope

With the discovery outputs agreed, the build scope defines exactly what will be configured and to what standard.

CRM configuration

The build scope for CRM configuration should specify:

• Number of pipelines and deal stages per pipeline
• Required properties configured at each deal stage
• Contact and company properties to be created (list each one)
• Lifecycle stage automation rules and the workflow logic implementing them
• Lead routing rules for form submissions
• User accounts, permission sets, and team structures

Workflow automation

The specific workflows to be built should be listed by name with their trigger, the actions they perform, and the contacts or deals they apply to. A scope that says "set up workflows for lead nurturing" isn't a scope. It's an intention. The scope should say: "Build a five-step nurture workflow triggered by a specific form submission, enrolling contacts in the Lead lifecycle stage, sending emails at days 1, 3, 7, 14, and 21, and unenroling when a deal is created."

The number of workflows in scope should be defined. Out-of-scope workflow requests should follow a defined change management process.

Data migration

The data migration scope should specify: the source system or systems, the objects to be migrated (contacts, companies, deals, activities), the date range of historical data to include, and the field mapping from source to HubSpot.

It should also define who's responsible for each step: who cleans and prepares the source data, who builds the import file, who runs the test import and validates the results, and who signs off that the migration is complete and accurate.

Integrations

Each integration in scope should be listed with: the HubSpot feature and the external system, the direction and type of data sync, the implementation approach (native connector or custom), and the testing criteria that confirm it is working correctly.

Phase Three: Training Scope

Training is where most SME onboarding scopes are weakest. A single "platform overview" session isn't a training programme. It's an introduction. The training scope for a team of fifteen to fifty people should cover three distinct layers.

Role-specific training sessions

Separate sessions for each function that uses HubSpot, focused on the specific tasks that role performs:

Sales: managing deals through the pipeline, logging calls and activity, using sequences, scheduling meetings via the HubSpot tool, and using the mobile app.

Marketing: building and testing workflows before activating, creating active and static lists, publishing content and associating it with campaigns, reading campaign attribution reports.

Service (if applicable): managing tickets in the conversations inbox, setting and meeting SLAs, using the knowledge base, logging customer interactions.

Leadership/business owners: reading the pipeline view and forecast tool, interpreting key dashboards, and using the custom report builder for basic queries.

Each session should be 60 to 90 minutes, role-specific, conducted against your actual HubSpot portal (not a demo account), and recorded for future reference.

Documentation handover

The training scope should include a documentation deliverable that covers your specific setup, not HubSpot's generic documentation. This means: what your pipeline stages mean and their entry criteria, what each active workflow does, which properties are required and why, and how each integration is configured.

This document is the onboarding resource for new team members who join after go-live. Without it, that knowledge lives in the onboarding partner's notes and the memory of the team member who was most engaged during training.

Post-launch check-in

A structured check-in at 30 to 60 days post-launch should be scoped as a deliverable, not offered as a courtesy. By that point the team will have encountered real friction, workflows that don't quite match the process, reports that don't answer the right question, a feature the training didn't cover. Catching these early prevents them from becoming embedded problems.

Roles and Responsibilities Matrix

A common source of onboarding failure is ambiguity about who is responsible for what. The scope document should include a RACI matrix (Responsible, Accountable, Consulted, Informed) for each major deliverable. At minimum, the following responsibilities need to be explicitly assigned:

Ambiguity in this matrix is where delays happen. If the client assumes the partner is cleaning the data and the partner assumes the client is providing clean data, the migration is delayed the moment they compare expectations.

Acceptance Criteria

The scope should define what "done" looks like for each phase, so there's no ambiguity about when the engagement is complete.

Discovery complete when: The current state assessment is documented and approved, the data model is agreed and documented, the integration map is completed and signed off.

Build complete when: All configured items (pipeline, properties, workflows, integrations) have been tested against defined test cases and approved by the client.

Migration complete when: The data has been imported, associations have been validated, the post-migration checklist has been completed and signed off, and the contact and deal counts match the agreed source.

Training complete when: Each role-specific session has been delivered and recorded, the documentation handover has been delivered, and the 30-day check-in has been scheduled.

Engagement complete when: All acceptance criteria above have been met and a final handover meeting has been held.

Wrapping Up

A partner who can hand you a scope document that covers all of the above - discovery outputs, build specification, migration plan, training structure, RACI matrix, and acceptance criteria - before the engagement starts is a partner who has done this before.

A partner who presents a timeline and a price and calls it a scope is one who'll figure out the rest as they go. That works fine sometimes. It doesn't work fine when your data is involved, your team's time is committed, and your business is running on a CRM that needs to be right.

We scope every engagement to this standard. If you want to see what that looks like for your business, give us a nudge.

Love a good HubSpot hack? Subscribe to our YouTube channel for deep-dives and HubSpot tutorials. Follow us on Facebook to stay in the loop with the latest HubSpot updates. 

Catch you in the next one!