11 Things to Demand Before an Onboarding Partner Builds a Single Workflow

Here's the thing about marketing automation onboarding: everyone offers it, very few define it.

You'll find a lot of proposals that include "HubSpot setup," "workflow automation," and "team training" as line items. What you won't find is a clear description of what each of those things actually means: what gets built, what gets tested, what gets handed over, and what "done" looks like across every team the rollout touches.

That ambiguity exists for a reason. It protects the provider. Vague scope is harder to dispute when it's only partially delivered.

This list is the antidote. These are the eleven specific things every ops leader running a multi-team CRM build should require from an onboarding partner before the engagement starts, in writing, in the scope document, with acceptance criteria attached.

1. A Signed-Off Architecture Document Before Any Build Starts

Not a kickoff deck with a project timeline. An architecture document. A written description of your specific HubSpot setup that has been reviewed and approved by every team it affects before a single workflow is activated.

This document should describe your pipeline stages and entry criteria, your lifecycle stage definitions, the properties being created or customised, and the automation logic being built and why. It's the blueprint. Building without it is like a builder skipping the plans and hoping for the best.

It should also settle ownership. A contractor keeps copyright in code it's commissioned to build unless the contract says otherwise (IP Australia), so the architecture document and every workflow built from it should carry an explicit clause assigning that logic and code to you, not just licensing it.

If a partner wants to start configuring before this document, and that clause, exist, that's your first red flag.

2. A Pipeline Design That Reflects Your Sales Process

Not HubSpot's defaults. Yours, across every team that sells.

HubSpot ships with seven default deal stages. They're a placeholder, not a sales methodology. An onboarding partner worth hiring asks how each team actually closes deals before touching the pipeline settings.

On Professional and Enterprise plans, required properties can be set at each deal stage, meaning reps can't advance a deal without entering specific data at that milestone. This should be configured as part of the pipeline build, not left as something the team will "get around to later."

3. A Field Mapping and Data Migration Plan

If you've got existing customer data anywhere, spreadsheets, a legacy CRM, a collection of inboxes and good intentions across several teams, you need a documented plan for how it arrives in HubSpot correctly.

The field mapping plan should show exactly where each piece of data ends up in HubSpot's object structure: which fields map to Contact properties, which map to Company properties, and which map to Deal properties. It should include a deduplication pass before the import runs, a test import on a sample dataset, and a validation checklist to confirm the data arrived correctly before the full migration goes live.

"We'll help you do an import" isn't a migration plan.

4. Core Workflow Automation Built and Tested Before Go-Live

The workflows that matter most are not complicated, but they need to actually exist:

• Lifecycle stage progressions triggered by contact behaviour.
• Lead routing from form submissions to the right person, on the right team.
• Deal stage task creation for sales reps at key pipeline milestones.
• Internal notifications for high-intent activity (form submissions, pricing page visits, proposal email opens).

These are table stakes. An onboarding that doesn't include them hasn't automated anything, it's configured a database.

Each workflow should be tested against real contact records, not test data, before go-live, with documented test cases showing what the trigger was and what action fired.

5. Email and Calendar Integration for Every Team Member

HubSpot's Gmail and Outlook integrations allow reps to log emails, track opens and clicks, access contact records, and enrol contacts in sequences without leaving their inbox. The scheduling tool auto-logs meeting activity against the contact and deal record when used.

These connections should be set up and tested for every team member who'll use them before go-live, not left as homework. An onboarding that hands over a configured portal where half the team still doesn't have their email connected has left the job half done.

6. A Connected Form and Tracking Setup

Every key form on your website should be doing three things: creating a contact in HubSpot, setting the correct lifecycle stage, and triggering appropriate follow-up automation.

The HubSpot tracking code on your website connects browsing behaviour to contact records. It's what enables lead source attribution and feeds the data that makes your marketing reporting reliable. It should be installed and verified before go-live, not discovered as missing three months later when someone asks why all their leads show as "Direct Traffic."

7. Integration Scoping Completed Before the Build Starts

Every external system connecting to HubSpot, accounting software, email platforms, ad accounts, support tools, industry-specific software, should be assessed and categorised in scoping, not mid-project.

The requirement here is an integration map that names each system, the direction of the data flow, the implementation approach (native HubSpot marketplace connector or custom), and the testing criteria that confirm it's working correctly.

HubSpot's App Marketplace has over 1,700 integrations. Most are native and straightforward to connect. Some are not. Discovering that your specific accounting software requires custom development in week four of a six-week engagement is a scope management failure, not bad luck.

8. Role-Specific Training for Each Function That Uses HubSpot

One team session covering everything produces a team that knows HubSpot exists and is confident in nothing. Role-specific training, sales, marketing and service each getting a focused session on the tasks their role actually performs, produces adoption.

Sales need: deal management, call logging, sequence enrolment, scheduling tool, mobile app. Marketing need: workflow building and testing, list creation, campaign attribution reporting. Service (if applicable) need: ticket management, conversations inbox, SLA configuration.

Every session should be conducted against your actual portal, not a demo account, and recorded for team members who join after go-live.

9. Setup Documentation Specific to Your Portal

At handover, you should receive a document describing your specific HubSpot setup, not a link to HubSpot's own knowledge base.

This means: what each pipeline stage means and its entry criteria, what each active workflow does and when it triggers, which properties are required and why, and how each integration is configured. It's the internal reference your team uses when someone asks "why is this workflow firing?" six months from now, and the handover document when you bring in a new partner.

If documentation isn't listed as a requirement in the scope with a description of what it covers, ask why.

10. Custom Reporting Built Around Your Actual Commercial Questions

Pre-built HubSpot dashboards cover the basics. They don't answer the specific questions your leadership asks: which channel is generating the best customers, where deals are stalling, what next quarter looks like.

The reporting requirement should include a set of custom reports built in HubSpot's report builder, built around your pipeline, your attribution model, and the decisions your team makes week to week. On Professional and Enterprise plans, this includes cross-object reports combining deal data, contact data, and campaign attribution on one dashboard.

Dashboards built to look impressive during the handover meeting and never opened again aren't a reporting outcome. They're a screenshot.

11. A Structured Post-Go-Live Check-In

The questions, issues and gaps that matter most appear after go-live, not during the build. A workflow that doesn't behave as expected in production. A report that isn't answering the right question. A team member who wasn't in the training session.

A structured check-in at 30 to 60 days post-launch should be in the scope as a defined requirement, not offered as a courtesy. By that point, teams will have encountered real friction. Catching it early prevents it from becoming an embedded problem that justifies writing off the CRM entirely.

If the engagement ends at go-live and there's no follow-up scheduled, the scope was designed for completion, not success.

Why This List Exists

Every item on this list represents something that's either routinely underdone, vaguely described, or missing entirely in standard onboarding engagements. Most buyers don't know to ask for them. Most providers don't offer them unless pressed.

That's the gap this list is designed to close. Take it into every onboarding conversation. Ask for each of these eleven things to be defined in writing. Compare the answers across every provider on your shortlist. If you haven't already, our guide to mapping your sales process before onboarding starts is worth doing first, and our note on how to choose a CRM setup service covers the selection process this list feeds into.

Neighbourhood delivers all eleven as standard, as part of our RevOps and HubSpot work. If you want to see what that looks like for your business, let's chat.

Want to connect with fellow HubSpot pros? Join our HubSpot User Group for exclusive events. Follow us on Instagram to stay in the loop with the latest HubSpot updates. Subscribe to our YouTube channel for more quick guides and tips.