HubSpot implementation: a practical UK buyer guide

HubSpot implementation is the work of configuring the CRM around your business, preparing and moving agreed data, connecting other systems and making the result usable for your team. A buyer needs a defined scope and evidence that records, access, automation and reporting work before approving launch and accepting the handover.

HubSpot implementation can be difficult to buy because two proposals may use the same words for different work. One includes advice; another includes a migration; neither makes clear who checks the finished result. Meanwhile, your team still has customers to serve and information arriving in the old system.

That uncertainty can surface late, when records have moved but relationships are missing, or staff discover that an essential task sits outside the agreed scope. Fixing the misunderstanding then can disrupt both the project and the working day.

This guide helps UK businesses turn those uncertainties into a practical brief. It follows the decisions from scope and data structure through testing, cutover and handover. Product guidance was checked on 30 September 2026 and HubSpot's onboarding fees, delivery periods and data hosting rules were rechecked on 11 October 2026; confirm the capabilities and prices in your own account and order form before committing to a design.

The short version:

• Onboarding is not the same as implementation. HubSpot's own onboarding is remote guidance from a specialist; hands-on configuration, migration and integration work may sit with your team or a partner.
• Budget for the required onboarding fee. HubSpot's catalogue lists a one-time fee for Sales Hub Professional, Marketing Hub Professional and the Enterprise tiers, separate from any partner's implementation price.
• Design the records before moving data. Agree objects, relationships and field meanings, then reconcile the migration against the source rather than counting uploads.
• Name the system that wins for every synced field. Test updates, deletions and failures, not only the first successful sync.
• Accept evidence, not features. Approve launch when real users complete real tasks, reports reconcile with a hand-checked sample and a recovery plan exists.
• Keep ownership in the business. Your organisation should hold Super Admin access, the operating records and the knowledge to run the account after the supplier leaves.

Define the HubSpot implementation you are buying

Start with a description of what your team must be able to do when the project is finished. A software account is easy to recognise. A useful implementation is harder to define because it includes business decisions, working records and the habits of the people using it. Put those elements into the brief before asking suppliers for a price.

You may already have a list of frustrations: enquiries disappear into individual inboxes, a director rebuilds the forecast every Friday, or staff cannot tell which company a contact represents. Keep those examples. They give the project a more useful starting point than a request to configure everything available in the subscription.

Describe a working day after launch

Choose a role and describe an ordinary task from beginning to end. An adviser receives a website enquiry, checks the customer's existing relationship, records the requirement and agrees a next action. A manager then finds the open opportunity without asking the adviser for a separate update. Those are behaviours that a demonstration can prove.

Write each requirement as an observable result. For example, an accepted enquiry appears in a named owner's working view with its service requirement and next action. Avoid requirements such as improving visibility unless you explain what must become visible, to whom and for which decision. Otherwise, a supplier can deliver a dashboard while your original problem remains.

Separate operational acceptance from commercial ambition. You may hope that better handling produces more customers, but the initial implementation can prove that records arrive, permissions work and users can complete agreed tasks. A functioning system provides a basis for judging later outcomes. It cannot guarantee that customers accept your offer or that sales increase.

Include one exception beside each ordinary task. What happens if the enquiry belongs to an existing customer, the owner is away or the service requirement is unclear? Exceptions reveal work that a tidy demonstration can hide. They also help a supplier estimate the scope without assuming every record will arrive complete and take the same route.

Distinguish guidance from delivery

The words onboarding, implementation and migration appear in proposals with different meanings. Read the actual deliverables beneath them. One engagement may provide advice while your staff perform the configuration. Another may include hands-on setup but exclude data preparation. Neither arrangement is inherently wrong, provided the responsibilities match your capacity and expectations.

HubSpot's onboarding services provide an official starting point for understanding its available assistance. Compare that description with the written proposal you receive. Ask who performs each task, who approves the business decision behind it and what evidence confirms completion. A service name cannot answer those questions on its own.

Know what HubSpot's own onboarding includes

Many buyers first meet the word onboarding as a line on their HubSpot order. The HubSpot Product and Services Catalog describes hub onboarding as access to a customer onboarding specialist, or equivalent HubSpot expert, who assists with setup and implementation. It is delivered remotely through phone or video calls and email, within a fixed delivery period from purchase. That is useful guidance, but it does not say a specialist will build your pipelines, clean your data or connect your finance system for you.

The catalogue quotes US dollar list prices. UK orders are usually priced in sterling and bundles, promotions or partner arrangements can change the figure, so take the amount from your own quote. Notice the delivery period too. A Sales Hub Professional onboarding plan runs for 60 days from purchase, so schedule your data decisions and internal availability before the clock starts rather than after it has mostly expired.

When a HubSpot Solutions Partner is also implementing, ask whether its work replaces, complements or duplicates HubSpot's onboarding, and get the answer written into the order. Then map each task to one owner: HubSpot's specialist advises, the partner configures and migrates, and your team approves decisions and tests the result. Gaps usually appear where two parties each assumed the other was building something.

Migration deserves an explicit line in the scope. Moving a contact list is different from transferring associated companies, open opportunities, notes and historic activities. Similarly, connecting an application can mean enabling an existing connector or designing a custom exchange. Ask the supplier to describe the actual records and behaviour included, rather than relying on either broad label.

Training is another common source of misunderstanding. A general product introduction may help users find menus, but it does not establish that they can handle your enquiry process. Specify the roles to be trained and the tasks each will practise. Request a handover that reflects the completed configuration, with any limitations clearly recorded.

Build a scope that can be checked

Create a deliverables register with a business purpose, an owner, an acceptance check and an exclusion for each substantial item. It need not be elaborate. Its job is to prevent an assumption becoming an unpriced obligation. Use it during supplier discussions and keep the agreed version available to the people delivering the project.

Keep a first release small enough to explain. A team replacing a shared spreadsheet might begin with one service and one sales process. That boundary should still include a complete route through capture, handling and reporting. A smaller working release is different from a collection of unfinished features spread across every department.

Document what is deferred and why. Perhaps a second business unit uses a different sales process, or an accounting integration needs access that is not yet available. Give deferred work a decision point instead of quietly assuming it will appear later. This lets the business assess the first commitment without buying an undefined future programme.

Compare the full commitment

Separate implementation fees, software subscriptions, migration work, external connectors and continuing support. Ask which costs change with users, records or additional requirements. Confirm how variations are approved. A lower setup figure may leave substantial work with your staff, while a larger proposal may include work you already have the capacity to perform.

Put each proposal into the same table before comparing totals. Ask for the subscription and onboarding figures separately from the implementation fee, and for the assumptions behind any estimate, such as the number of pipelines or source records. Two quotes that look far apart often describe different scopes rather than different prices.

Avoid treating an estimated project duration as a guaranteed business result. Ask which inputs the estimate assumes and what happens if access, source data or internal decisions arrive late. A useful plan shows dependencies and acceptance points. It allows the team to explain a change in timing without disguising incomplete work as successful delivery.

GRO's HubSpot implementation service describes configuration, migration checks, role-specific training and administrator handover. Your proposal should identify the particular parts commissioned for your business. Finish the buying discussion with an agreed scope that an operational colleague can explain, not just a collection of features that sounded useful during a presentation.

Decide what to keep from your existing setup

A new implementation does not always require a new account. Existing records, forms and integrations may still be useful even when the team dislikes the current setup. Review them before making a replacement decision. The important question is which changes will support the agreed process while preserving information the business still needs.

An untidy account can make starting again feel attractive. That instinct is understandable when staff see duplicate fields, abandoned pipelines and reports nobody trusts. However, visible clutter is only part of the picture. Some apparently unused settings may still support a live form or connection, so removal needs evidence rather than a spring-cleaning impulse.

Inventory the account by dependency

Ask the implementation team to list the operational components and what depends on them. For a property, that might include a form, an integration, a workflow and a report. For a pipeline, it might include open deals and rules that respond to stage changes. Record the purpose and owner alongside the setting.

Start with things that affect customers or live work. An active enquiry form deserves attention before an old internal dashboard. Identify the routes by which information enters and leaves the account, including manual imports. A spreadsheet uploaded every Monday can be an important dependency even though it does not appear as a permanent integration.

Ask staff where they go when HubSpot does not answer a question. Their alternative spreadsheets and inbox searches often reveal missing context. Record those workarounds without assuming all of them should become CRM features. Some belong in a different operational system, with HubSpot holding a reference or status rather than a complete duplicate.

Distinguish configuration that is unnecessary from configuration whose purpose has been forgotten. The second needs investigation. If nobody can identify a dependent process, document the checks performed before proposing retirement. Keep a change record so a later problem can be traced to the decision rather than reconstructed from scattered memories.

Examine records, not only settings

Review a representative set of records with the people who use them. Include an active opportunity, an existing customer, an unsuccessful enquiry and a record with incomplete information. Ask what each person needs to find and what currently makes that difficult. These examples turn a general complaint about poor data into a specific improvement requirement.

Check whether the same labels mean different things across teams. One team may use qualified to mean contact details confirmed, while another uses it for a budgeted project accepted by sales. Combining their records in a single report creates ambiguity. Agree whether the definitions should become consistent or remain separate with explicit reporting boundaries.

Historic data may not support the new definitions. Preserve that limitation rather than retrospectively assigning stages from guesswork. You can retain useful old records and still begin a new measurement period from a clearly stated date. A trustworthy starting point is more valuable than a long trend whose earlier values were reconstructed without evidence.

Record which information is authoritative. A customer address maintained in an invoicing system may differ from a site address supplied for a quotation. Those are potentially different facts, not automatically a conflict. Naming the meaning of each field can resolve a problem that would otherwise be mistaken for poor integration quality.

Choose repair, restructuring or replacement

Repair may suit an account whose basic record structure works but whose ownership, layouts or operating instructions are unclear. Restructuring may be needed where different processes have been squeezed into unsuitable fields or stages. Replacement is a wider decision because it can affect account identity, subscriptions, connections and access to history.

Ask for the reasoning behind the proposed route. It should explain what will be preserved, what will change and what cannot be carried forward. A supplier should be able to identify the trade-offs without implying that every inherited setting is wrong. Equally, preserving history should not become an excuse to retain a process nobody can operate.

Compare disruption as well as build effort. A modest configuration change can still interrupt staff if it alters the fields they use every day. A larger change may be manageable when introduced to one team with clear preparation. The useful comparison concerns the effect on real work, not simply the number of settings changed.

For an account already handling enquiries, agree where staff work during the project. Identify who may edit shared settings and how urgent requests are handled. Without that arrangement, a well-intentioned administrator can change a property while the implementation team is testing a dependent workflow, making both the build and its evidence unreliable.

Keep evidence of the starting point

Preserve the approved information needed to understand the current arrangement. That can include configuration notes, authorised exports and a record of open exceptions. Decide who may access these materials and how long they need to be retained. A project folder should not become an uncontrolled collection of customer data copied for convenience.

Confirm what a backup or export actually contains before relying on it. A list of contacts does not necessarily preserve associations, activity history or account configuration. The NCSC's guidance on backing up critical data is a useful starting point for a recovery discussion, but the implementation needs a specific, tested recovery method for its own changes.

Ask what can be reversed and what requires a separate recovery process. A renamed view and a merged record have different consequences. Agree a stopping point before higher-impact changes, and make sure the responsible person understands what approval covers. A general instruction to tidy the CRM should not silently authorise irreversible decisions about useful history.

Finish the review with a short decision document. It should identify the chosen approach, retained components, proposed retirements, unresolved questions and the effect on current users. This gives the next stage a dependable baseline. It also prevents the project from repeatedly reopening the same architectural decision whenever someone discovers another old field.

Match subscriptions and access to real roles

Describe what each role must do before deciding which access it needs. An account administrator, an adviser and a director reviewing a report have different responsibilities. Matching access to those tasks makes the proposed setup easier to explain and helps expose licence assumptions before they become part of the implementation price.

Software purchasing can become confusing when a demonstration moves between features without showing their requirements. Ask the supplier to connect every essential capability to the proposed account and the people who will use it. The resulting list should distinguish a required launch capability from a possible later improvement.

Separate three different questions

First, establish whether the subscription includes the capability. Second, establish whether the user needs a particular seat to access it. Third, decide what that user is permitted to do with the records or tool. These questions are related, but an answer to one does not automatically settle the others.

HubSpot's seat documentation, checked on 30 September 2026, distinguishes tool access through seats from actions controlled by permissions. Treat the documentation and the actual account as the authority for feature availability. Do not assume an old proposal, screenshot or remembered product tier describes your current entitlement.

Build a requirement list using tasks rather than job titles alone. Two sales managers may need different access because one edits account settings while the other only reviews a team's opportunities. Several job titles may perform the same task. The implementation should reflect those responsibilities rather than replicate an organisation chart without examining the work.

Avoid giving broad administrative access merely because a user encounters an error. Identify whether the problem is a missing capability, a permission or a configuration issue. Resolve the actual cause and repeat the task. A temporary permission change also needs an owner and an end point, otherwise it can become the permanent arrangement by accident.

Test visibility with ordinary accounts

A demonstration performed as an administrator cannot prove that a salesperson has the right experience. Ask representative users to complete the agreed tasks through their own authorised access. They should be able to find the necessary record, make the permitted update and see the next action without asking the builder to intervene.

Test what should remain unavailable as well. A role may need to progress opportunities without editing the wider process. Another may need a report without unrestricted export capability. Record these boundaries in plain language and confirm the actual behaviour. Permissions are useful only when they match the responsibility the business intended to delegate.

Consider handovers between teams. If an opportunity changes owner, check whether the receiving person can see the relevant history and whether the previous owner retains appropriate access. A record can be assigned correctly while still being difficult to use. Those are different checks and both belong in the acceptance plan.

Include absence and staff changes. Someone needs authority to redistribute work when an owner leaves, while access that is no longer required needs review. Define who makes that decision and who performs the account change. The procedure should be usable by the business after the external implementation team has finished.

Make commercial assumptions visible

Ask for software costs to be separated from the implementation fee and continuing support. Identify which proposed users need which access and the basis on which the supplier estimated that requirement. Check the actual commercial terms before purchase. This guide does not provide current subscription prices or recommend a tier without knowing the account.

Include external applications where the process depends on them. A booking tool, integration service or reporting connection can create a continuing cost even if the initial setup is included. Record who contracts with the provider and who manages renewal. An apparently complete implementation can still fail operationally when nobody owns a subscription it relies on.

When a feature requires a larger commitment, ask what simpler alternative exists. A manual review view may be sufficient for a small queue. It may also create unacceptable effort at higher volumes. Compare the actual workload, risks and cost rather than assuming automation is always better or that avoiding a software charge always saves money.

Review assumptions when the scope changes. Adding another team can alter access, training and reporting requirements. Introducing a new customer process can require a capability absent from the original plan. A change request should identify those effects before the business approves it, so the software commitment remains connected to a defined need.

Retain internal control

Keep an authorised internal account owner who understands the administration arrangements. That does not mean one person must learn every technical setting. It means the business knows who can approve access, contact the provider and organise a handover. Responsibility should remain clear when an employee or external supplier changes.

Use supported invitations and the organisation's account-security arrangements. Do not solve onboarding friction by circulating one person's password. The NCSC's secure user management principles provide context for evaluating access controls. Apply them through the business's chosen security process and the capabilities of its actual services.

An access register can record the account, role, purpose and approving owner without holding credentials. Keep it current enough to explain who can perform important actions. At handover, have the internal owner demonstrate that they can administer the agreed arrangement. That check provides stronger evidence of control than a sentence in a proposal saying the account belongs to you.

Design the records before moving the data

A field list is only part of a CRM design. The more difficult question is what each record represents and how records connect. If that decision is wrong, a technically successful import can produce a system that users cannot trust. Spend time on a few representative customer relationships before approving hundreds of property mappings.

Imagine a fictional maintenance business serving several premises belonging to one customer. It needs to distinguish the organisation paying the bill, the people arranging visits and each commercial opportunity. The project must decide where site information belongs within the purchased system's capabilities. Putting every address into a single company note might preserve the text while losing the relationships needed for everyday work.

Draw relationships with real examples

Choose examples that challenge a simple design. Include a customer with several contacts, someone who buys for two organisations, a returning customer and a business whose trading name differs from its billing name. Describe the work your team needs to do with each. A supplier should be able to walk through that work using the proposed record structure.

Ask where a salesperson would record a second opportunity without overwriting the first. Check how an administrator would correct an address without changing a historical transaction unintentionally. Look at how someone leaving a customer organisation should affect the relationship. These questions expose assumptions that a diagram containing only “contacts”, “companies” and “deals” may conceal.

Avoid making the design depend on a feature simply because it appears in a demonstration account. The supplier must confirm that the agreed objects, associations and property types are available in your account. If a requirement depends on a different subscription, resolve that commercial decision before building the import around it.

The output should include a small set of examples showing both records and relationships. Pair those examples with a field dictionary. GRO's CRM data model service covers this area of planning. The buyer's test remains whether the proposed structure supports their actual work without forcing staff to keep a second, hidden version elsewhere.

Give each important field a contract

A useful field dictionary explains more than the display label. Record its meaning, format, allowed values, source and owner. State when it is required and who can change it. For a field used in routing or reporting, include what should happen when the value is unknown. An empty cell, an explicit “unknown” and a default value can lead to different decisions.

Take “customer region”. It might mean the salesperson's territory, the invoice address or the location receiving the service. Those meanings are not interchangeable. Choose the one the field is meant to represent, or separate them where the work genuinely requires separate facts. A short definition agreed now can prevent a long argument about the regional dashboard later.

Be careful with dropdown options. “Large”, “strategic” and “priority” may describe three different judgements. If staff can choose any of them without a shared rule, the property provides little reliable evidence. Define options using conditions people can apply. Where judgement is unavoidable, record whose judgement it is and when it should be reviewed.

Free text still has a place. A salesperson may need to explain a customer's concern in their own words. The problem comes when an essential structured decision exists only inside those notes. Keep narrative context where it helps the reader, while giving routing, reporting and operational decisions their own agreed fields.

Preserve meaning when names change

Mapping an old field to a new field is a claim that the two contain the same kind of information. Similar names are not enough. Compare the definitions, example values and actual usage. A legacy “close date” may contain a proposed signing date, while the new report expects the date a sale was confirmed.

Where meanings differ, decide whether to transform the data, keep a separate historical field or exclude it from a particular report. Document that decision. Do not silently convert uncertain history into apparently precise new information. A visible limitation is easier to manage than a chart that mixes incompatible definitions without telling its reader.

Keep a mapping version with the trial import evidence. If a stakeholder changes a definition later, the project can identify which tests and records are affected. This does not need an elaborate documentation system. A dated, controlled register with named approval is sufficient if everyone uses it and earlier versions remain available.

Limit what you collect and retain

An implementation is a useful moment to question whether every inherited field still serves a purpose. The ICO's data minimisation guidance explains the principle of keeping personal data adequate, relevant and limited to what is necessary. Apply your organisation's retention and privacy decisions before copying old information into a more widely accessible system.

Check where the account stores its data as well. HubSpot's data centre FAQ says new paid customers are assigned a hosting location from the location of their IP address at sign-up, while accounts using only free tools are placed in the United States. A UK business that started on the free CRM may therefore be hosted in the US. The current location appears under Settings, Account Defaults, Data Hosting, and HubSpot says existing paid customers can migrate to another data centre at no charge. Settle the location with whoever owns data protection before the main migration, not after it.

Separate a field's technical availability from permission to use its contents. A migration tool accepting a column does not establish a lawful purpose for keeping it or permission to send marketing. Have the responsible person decide how sensitive, obsolete or uncertain information should be handled. Record the decision in the migration scope without putting unnecessary personal information into project documents.

Finally, ask a user who did not design the model to interpret a sample record. Can they tell what happened, what is current and what they should do next? If they need the implementer's explanation for every field, simplify the labels or instructions. The design is ready when it makes the work understandable to the people who will own it.

Reconcile the migration instead of counting uploads

A completed import message is a technical event. Migration acceptance requires evidence that the right information arrived in the right place, with the right relationships. Buyers should ask for a reconciliation plan before the first bulk transfer. That plan explains how the team will account for source records, exclusions, errors and the resulting destination records.

Start with a defined source extract. Record when it was taken, which systems and record types it covers, and whether staff can still edit those systems. Without that boundary, two people may compare different versions and reach different conclusions. The migration team needs a stable reference even when the business continues operating around it.

Separate rows, records and relationships

A spreadsheet row is not always a unique customer. Several rows may describe one organisation, or one row may contain information destined for multiple record types. Agree the intended interpretation before comparing totals. Otherwise, a legitimate consolidation can look like missing data, while duplicated contacts can make an incomplete migration appear numerically complete.

Consider an explicitly hypothetical extract containing 1,000 contact rows. A review identifies 40 repeated rows and 10 rows approved for exclusion. That leaves 950 intended contacts. If the first import creates 930 contacts and rejects 20, the team has not finished. It has accounted for the difference and now has an exception queue to resolve.

The arithmetic is illustrative, not a migration benchmark. Its value is the separation of categories. After correcting the 20 rejected records, verify the intended 950 contacts using the agreed identifiers. Then check their company links and other required associations separately. Matching the contact total cannot prove that those relationships are correct.

Keep exclusions explicit. A row omitted under an agreed retention decision belongs in a different category from a row that could not be imported. The exception register should explain the reason, owner and next action without retaining more personal data than necessary. A final acceptance record can refer to controlled evidence rather than copying customer details into a public project summary.

Agree identifiers and update behaviour

Ask how the process distinguishes a new record from an update to an existing one. HubSpot's import file guidance describes requirements and identifiers for different import situations. The chosen method must fit the records being moved. Do not assume that every customer has a unique, current email address or that every company shares a simple domain pattern.

Test awkward examples before bulk work. Include a changed email address, two people with similar names, a missing identifier and a record already present in the destination. Record the expected outcome for each. The point is to prove how the agreed import behaves, rather than rely on someone saying that the tool handles duplicates.

Also agree what an empty source value means. Is it unknown, intentionally blank or a request to remove an existing value? HubSpot documents that blank cells in an import do not clear existing property values. A clearing requirement therefore needs an explicit, supported approach and its own test. Treat deletion and overwriting as separate decisions from ordinary record creation.

Use a trial that represents the difficult work

A trial containing only pristine contacts offers weak evidence. Select a controlled sample covering the important record types, relationships and problem cases. Include the variations discovered during the audit. Use appropriate test data and access controls, and agree where the trial can run safely within the available account arrangements.

Have the business owner inspect the destination through normal screens as well as through an export or reconciliation report. A technically present field may be difficult to find, formatted unexpectedly or disconnected from the record people use. Ask a salesperson to locate a sample opportunity and explain its customer relationship without help from the migration specialist.

Log import errors using the supplier's documented categories. HubSpot's import error guidance can help the implementer investigate them. The buyer needs a simpler view: what failed, how many records are affected, who owns the correction and when the result will be checked again. Do not mark an exception resolved merely because someone edited the source file.

Control changes between the trial and launch

A successful trial describes one data version and one mapping version. If either changes, decide what needs retesting. A new dropdown option may affect only a small set of records. A changed identifier rule may affect the whole migration. Record the scope of the change and the evidence supporting the decision, rather than assuming yesterday's result still applies.

Plan how updates made after the first extract will reach the new system. The approach might involve a controlled final extract, a defined change transfer or a temporary pause in particular edits. The right choice depends on the source system and business operation. What matters is that every relevant change has a known route and owner.

Finish with a migration acceptance pack containing agreed totals, exception decisions, sampled relationship checks and the source boundary. GRO's CRM data cleansing service is relevant where the source needs preparation. Keep cleansing and migration acceptance distinct: improving a file does not, by itself, prove that the final live records are correct.

Make integrations answerable for each field

An integration connects systems, but the buyer needs to know what information should move and what should happen when systems disagree. A connector name on a proposal is not a complete specification. Ask for a short agreement covering each important record type, field, direction and failure response. This makes the integration understandable without requiring you to inspect its code.

Use one everyday example to test the design. Suppose the finance system owns the invoice address while HubSpot owns the sales contact's preferred phone number. The project should explain which changes travel in each direction and why. A blanket promise of two-way sync can conceal conflicting ownership for individual fields.

Name the source that wins

For each shared field, identify the authoritative source and the permitted editor. If both systems can change a value, define the conflict rule. Ask what happens when changes arrive close together, when one value is empty and when an older value is sent again. The answers should reflect the actual connector, not a general assumption about how synchronisation works.

Finance connections show why this matters. HubSpot's Xero data sync guide describes syncing contacts, products, invoices and payments, with some objects configurable one way or both ways. Decide whether invoices are raised in Xero or in HubSpot before switching on two-way sync. If both teams create them, you can end up reconciling duplicates every month.

HubSpot's data sync documentation describes sync direction and conflict-resolution settings. Those settings need to be considered together. The supplier should demonstrate your chosen configuration using a controlled example. Different integrations can behave differently, so evidence from one connector does not automatically validate another.

Make ownership understandable to users. If finance owns a billing field, explain where a salesperson should request a correction. Otherwise, staff may repeatedly edit a value in HubSpot only to see it change back. That looks like an unreliable system even when the integration is following its configured rule precisely.

A compact integration register can record the source, destination, fields, matching method and operational owner. Add the expected update interval or condition using the supplier's verified specification. Do not describe every transfer as instantaneous. A scheduled, delayed or event-dependent update may be acceptable if users understand what to expect and the process accommodates it.

Test changes as well as creation

Creating a new contact is usually the easiest demonstration. Ask to see an existing record updated, a permitted field corrected and a conflicting value handled. Check a record that does not qualify for synchronisation. It should remain outside the connection for the intended reason, without creating an unexplained exception that someone has to investigate later.

Record matching deserves its own test. HubSpot's guidance on matching records in data sync explains that matching and ongoing pairing are related parts of the process. Have the supplier show how the agreed connection handles records already present in both systems. Do not assume that a successful initial pairing proves every future identity change is safe.

Consider an interrupted transfer. If the same event is delivered again, will the connection update the same record or create another one? Buyers do not need to prescribe the technical solution, but they should ask for repeat-delivery behaviour to be tested where relevant. A duplicated customer or invoice reference can create work far beyond the integration team.

Check the relationships surrounding a record too. A contact may arrive successfully while its associated organisation does not. Decide whether that partial result is acceptable temporarily, how it becomes visible and who completes the repair. The acceptance test should reflect the work users need to perform, not just whether a connection displays a green status.

Make failure visible to an owner

Every important connection needs an operational response when it stops doing the agreed job. Specify who sees an error, where they look and what they can safely do. If the only alert goes to the implementer's personal inbox, the business has not received a workable handover. Agree a supported route that survives staff and supplier changes.

Choose an alerting approach proportionate to the consequence. A delay in a non-urgent reporting field differs from an interruption that prevents a team receiving new enquiries. Define the point at which someone should investigate, using the expected behaviour of that connection. Avoid inventing a universal response time that has no relation to the contract or available support.

Include a recovery test where practical. Pause or otherwise simulate an authorised failure in a safe setting, then inspect how the connection catches up. Confirm whether records need manual correction and how the team knows the backlog is cleared. Do not create disruption in a live business system merely to produce a test result.

Keep access and ownership with the business

Ask which account authorises the connection and what happens when its owner leaves. Use the integration's supported account and access arrangements. Record the business owner, supplier contact and renewal dependency without placing credentials in the register. Review access as part of handover and whenever the connection's purpose changes.

Custom work needs a support boundary. Find out who maintains it when an external service changes, where its documentation lives and what is included in ongoing support. A one-time build fee does not explain those responsibilities. If the supplier provides a managed connection, document the service terms and the business's route for obtaining its data or changing provider.

GRO's HubSpot integrations service can be considered for this part of the project. Before acceptance, ask the responsible team to trace one meaningful change from origin to destination and then explain a failed change. When both journeys are clear, the integration has become something the business can operate rather than a connection only its builder understands.

Test automation at its boundaries

Automation errors often appear around the edges of an otherwise sensible process. A rule works for a new enquiry, but behaves differently when the person is already a customer, has no owner or submits the form again. Make those boundaries part of the implementation scope. They deserve attention before the team activates rules across real records.

Begin with the business decision, expressed in plain language. For example, an eligible enquiry should create a follow-up task for the assigned owner, while an enquiry without an owner should enter an agreed exception route. This is a specification to test, not a claim about what any particular HubSpot subscription provides automatically.

Define entry, exit and repetition

Every proposed automation needs an entry condition and a description of its intended action. Add the conditions under which it should stop, skip an action or become eligible again. HubSpot's workflow creation guidance distinguishes enrolment, re-enrolment and unenrolment settings. Have the implementer explain the settings selected for your use case and account. If you plan to route or prioritise leads automatically, agree the rules first; our lead scoring guide explains how to build a model sales will trust.

A returning enquiry illustrates why repetition matters. The business may want a new task when an existing contact asks about a different service, but not whenever someone corrects the contact's phone number. Write those two cases separately. The supplier can then show that a meaningful new event produces the intended action while an unrelated edit does not.

Consider what happens if a record changes during a delay. A contact may become a customer, opt out of a communication or be assigned to another team before the next action is due. Agree which changes should affect the remaining sequence. The project should demonstrate the relevant outcomes rather than assume that the original entry decision remains valid indefinitely.

Do not use operational automation as a substitute for the organisation's decisions about lawful communications. The person responsible for marketing permissions should approve eligibility and suppression rules. The implementation team then tests those rules as specified. Importing a contact or assigning a lifecycle stage does not, by itself, establish permission to send them marketing.

Build a compact test matrix

For each important rule, choose cases that cover an expected success, an exclusion and a failure or missing value. Add a repeat case where repeated events could cause harm. Record the starting data, action taken and expected result before running the test. This prevents a convenient result being described as correct after it happens.

A routing test might use four controlled records: one with a valid region and active owner, one with an unknown region, one whose normal owner is unavailable and one outside the service criteria. The exact cases depend on the agreed process. What matters is that someone has decided where each should go, including the records that do not fit neatly.

Check the visible result from the receiving user's account. A task may exist but be assigned to the wrong queue, hidden by permissions or missing the context required to act. Ask the user to find it and explain the next step. Acceptance should follow the practical task through to its destination, not end at an automation log entry.

GRO's lead routing service is relevant where ownership rules need attention. Keep the business exception route simple enough for someone to operate. An unassigned record should have a named reviewing role and a clear place to appear, rather than waiting indefinitely for a technical specialist to notice it.

Prevent rules from fighting each other

Two individually reasonable automations can make conflicting changes. One rule might assign a territory owner while another assigns a product specialist. Ask the supplier to review shared fields and overlapping eligibility across the proposed rules. The project should identify which rule controls the final value and how that decision is recorded.

Include existing automation in that review. An older workflow, external integration or manual bulk update may still affect the same records. Document dependencies before activation. If an existing rule is retired, agree how already enrolled records are handled and preserve enough information to explain the change later.

Naming helps operations, but naming alone is not documentation. A workflow title should make it findable; its supporting note should explain purpose, owner, entry conditions and consequences. Avoid names that reveal unnecessary customer information. Keep the description close enough to the configuration that the person maintaining it can find both.

Activate in a controlled sequence

Decide whether the initial activation affects existing records, future events or an explicitly selected group. These are different business choices. Before enabling a rule, ask the implementer to show the intended population and explain why it qualifies. A technically valid trigger can still affect far more records than the business expects.

Where practical, start with a bounded, approved scope and observe the result before expanding. The scope should be chosen around business risk and the capabilities available, not an arbitrary percentage. Record who watches the initial run, what would cause a pause and how affected users will be informed if the behaviour needs correction.

Agree a safe stopping procedure. Turning off a rule may prevent future actions without reversing changes already made. The handover should explain that distinction and describe how to identify affected records. Do not promise that every automation can be rolled back with one switch.

Finally, review the operational workload created by the automation. A rule that generates technically correct tasks can still overwhelm the people receiving them. Ask the team to work through a representative batch and judge whether the task content, priority and ownership are usable. GRO's automated lead follow-up service fits this discussion when follow-up is part of the agreed project.

Agree what the reports are allowed to claim

A new dashboard can look finished before its numbers have a shared meaning. Implementation reporting should begin with definitions and coverage, then move to presentation. Ask which business decision each report supports and which records qualify for it. A chart that nobody can reconcile is a weak basis for deciding whether the new system is working.

Separate implementation acceptance from commercial performance. The project may be responsible for making an agreed report accurate and usable. That does not establish that the software caused more sales or that the business will achieve a particular return. Keep delivery evidence, operational adoption and business outcomes visible as different questions.

Write the metric definition before the chart

For each important measure, record the unit counted, inclusion rule, date basis and relevant exclusions. “New opportunities this month” might refer to records created this month, opportunities first qualified this month or opportunities assigned a particular expected closing month. Each can answer a legitimate question. They should not share one label if they describe different populations.

Agree how reopened and merged records are treated. A deal that returns to active work may be new activity without being a newly created opportunity. A merged contact may reduce the record total without representing a lost customer. The reporting definition should anticipate those cases where they matter to the decision, rather than treating every change in a total as business movement.

Distinguish stock from flow. An open pipeline total describes records at a point in time; newly created opportunities describe activity over a period. Comparing them directly can produce misleading conclusions. Label the reporting period and the relevant date property clearly enough that another manager can reproduce the selection. If reports will credit marketing channels with revenue, settle the attribution approach at the same time; our marketing attribution guide compares the main models and their limits.

If the project includes forecasts, ask how the underlying fields are maintained and what the calculation assumes. GRO's sales pipeline forecasting service addresses that work. An implementation should make assumptions inspectable. It should not turn uncertain dates or amounts into a confident prediction simply because the chart has a polished appearance.

Reconcile a sample by hand

Choose a small, controlled set of records with known expected results. In an illustrative test, suppose four opportunities meet the agreed inclusion rule and a fifth falls outside the selected period. The report should contain four. Inspect the included records and confirm the excluded one is absent. The example is a test design, not a claim about any company's sales.

Then change one controlled condition and check the result again. Move a test record outside the inclusion rule, adjust its relevant date or apply an agreed exclusion. This helps demonstrate that the report responds to the intended property. A correct total on one static sample can otherwise be a coincidence.

Where a financial total is used, reconcile the values and currency treatment as well as the number of records. Document whether the report shows entered amounts, converted amounts or another agreed measure. Have the appropriate business owner approve the meaning. Avoid silently combining figures that require a commercial or accounting decision the implementation team has not been authorised to make.

Keep the reconciliation evidence with the report specification. A screenshot alone may omit filters or the selected date range. Record enough configuration and sample references for someone else to repeat the check under appropriate access controls. This makes future changes easier to assess and reduces reliance on the original report builder.

Label gaps in historical coverage

Migrated data may lack fields that the new process will collect consistently. Identify where that limits historical comparison. For example, a qualification date introduced at launch cannot automatically provide trustworthy qualification history for every old opportunity. Any reconstruction needs an agreed method and a clear label distinguishing it from directly recorded history.

Avoid filling unknown values just to make a chart look complete. A separate “unknown” category can be more useful than an unsupported assumption. The ICO's accuracy guidance provides relevant context where personal data is involved. Operationally, the report should help owners find and correct gaps without presenting guesses as facts.

Agree when a report becomes suitable for regular management use. Some measures can be checked immediately against migrated records. Others need a period of consistent new data collection before comparison is useful. State the dependency without promising a universal waiting period. The appropriate point depends on the business cycle and the measure's definition.

Use adoption evidence carefully

Logins can show that people accessed a system, but they do not prove that the intended work happened correctly. Choose a few operational checks linked to the project: required ownership present, agreed stages used consistently, exceptions reviewed and selected records complete enough for their next action. Define the sample and review method so the results are interpretable.

Ask users about work still happening elsewhere. A parallel spreadsheet may be a temporary launch aid, a genuine missing requirement or simply an old habit. Investigate before declaring adoption a success or failure. The response should address the reason, with an owner and an agreed next step.

GRO's HubSpot reporting service is relevant to building this evidence. For the wider relationship between marketing activity and commercial outcomes, the lead generation funnel guide provides context. Keep this implementation's acceptance focused on the definitions, coverage and reliability it can actually demonstrate.

Run acceptance tests with the people doing the work

User acceptance testing is the point at which the business checks that the delivered system supports the agreed work. It should happen before launch decisions become difficult to reverse. Give participants specific scenarios, enough time and accounts that reflect their normal roles. A supplier-led tour is useful preparation, but it is not the same evidence as a user completing a task.

Choose a test owner who can distinguish a defect from a new request. Both may deserve attention, but they affect the project differently. A defect fails an agreed requirement. A new request changes that requirement or adds another one. Record the distinction without using it to dismiss a practical problem that could prevent the business operating.

Trace requirements to evidence

Create a short register linking each important requirement to a test and an acceptance owner. A requirement such as “sales can work new enquiries” is too broad to check consistently. Break it into observable tasks: find the assigned enquiry, inspect the required context, record an outcome and make the next action visible to the agreed person.

Keep tests at the level of business behaviour wherever possible. The user does not need to know the internal name of every property to demonstrate that the task works. Technical checks still matter, but they support the practical outcome. Record both where a critical result depends on a configuration that the user cannot directly inspect.

Make expected outcomes specific. “Looks correct” gives a reviewer little basis for agreement. “The assigned user can open this test opportunity, see its associated company and update the agreed next-action field” is more useful. The evidence can be a controlled screen recording, a test record reference or a signed result, depending on the organisation's information-handling rules.

Test whole journeys across roles

A process can pass within each team's screen and still fail at the handover. Ask one user to create the agreed input and another to receive it. Follow the record through the relevant ownership change, notification or queue. Confirm that the second user has enough context and access to continue without asking the first person to repeat the work elsewhere.

For a fictional service business, the journey might start with an enquiry, continue through a qualified opportunity and finish with a handover to delivery. The implementation test should stop at the boundary actually included in the contract. If delivery work remains in another system, test the agreed transfer rather than implying that the entire operation now lives in HubSpot.

Include ordinary permissions. An administrator may see a record that a salesperson cannot access, or edit a field that a team member is meant only to view. Test with the relevant role arrangement through supported accounts. Do not distribute administrator access simply to make a failed test pass.

Ask users to narrate where they hesitate. Some difficulties are training needs; others reveal confusing labels, missing information or a flawed process. Record the observation before deciding which it is. A useful test session gives the project evidence about those distinctions without expecting participants to diagnose the technical cause.

Classify defects by business effect

Agree severity definitions before the final test session. A problem that prevents an essential live task needs different treatment from a cosmetic issue with an understood workaround. Describe the effect and affected scope in the defect register. Avoid relying on a colour or priority label that different people interpret differently.

For each defect, record the expected result, actual result and steps needed to reproduce it. Add the responsible owner and planned retest. Keep personal data out of screenshots where it is not necessary. A clear reproduction often saves more time than an extended discussion about whose component is responsible.

A fix is not complete until the relevant test has been repeated successfully. Consider whether it could affect neighbouring behaviour too. Changing an owner rule, for example, may require checking the exception route as well as the normal route. Choose retests based on the change's consequence rather than repeating every test without a reason.

Make the launch decision explicit

Agree the conditions required to proceed. These might include reconciled migration totals, critical role-based journeys passing, operational owners briefed and an available recovery plan. The conditions should come from this project, with a named decision-maker. Do not accept a generic “all checks complete” statement without knowing what was checked.

If an issue remains, write down its impact, workaround, owner and proposed resolution. The authorised business owner decides whether that residual issue is acceptable. Silence from a busy stakeholder is weak evidence of acceptance. Record an explicit decision against the tested version and the list of known limitations.

Keep the evidence tied to a configuration version or dated release record. Later edits can invalidate earlier tests. If the supplier changes a workflow after approval, assess and test that change before assuming the previous result still applies. This is especially relevant when small late requests arrive during training or immediately before launch.

The acceptance pack should be understandable to someone who was not in every project meeting. It explains what was agreed, what was tested, what passed and what remains open. That gives the business a practical basis for its launch decision and provides a reference if expectations differ during the support period.

Plan the cutover and the way back

Moving into a new system is a business event as well as a technical one. People need to know where to work, which records are current and what to do if the change cannot proceed. A cutover plan puts those instructions in order. It should be short enough to use during the change, with detailed technical steps available to the responsible specialists.

Choose the timing around the operation and the dependencies. An apparently quiet afternoon may still be unsuitable if finance is closing a period or the only authorised decision-maker is unavailable. Ask each owner to confirm their part of the plan. Avoid promising a fixed implementation duration before these constraints and the source data are understood.

Build the sequence around dependencies

List the steps that must finish before the next can begin. A final extract may depend on an agreed pause in edits; a report check may depend on completed imports; staff access may depend on confirmed role assignments. Mark those dependencies explicitly. A list of dates without them makes it harder to judge the effect of a delay.

Assign a named role to each action and identify the evidence that shows completion. “Migration complete” should refer to the agreed reconciliation result. “Team ready” should refer to the access and practical preparation required for their first tasks. Keep completion statements observable so the person coordinating the change can make decisions without guessing.

Agree who can say stop. That person needs a clear route to the technical and business owners, plus the authority to hold the change if a critical condition fails. The plan should state how users will hear the decision and where they should work in the meantime. Uncertainty during a paused launch can create more conflicting records than the original technical issue.

Protect changes made during the move

A business rarely stops producing information just because its CRM is changing. Decide how new enquiries, customer corrections and commercial updates will be captured during the transition. Give each type of change one agreed place and owner. Otherwise, staff may enter the same information in both systems or assume someone else has recorded it.

If a temporary capture method is needed, keep it controlled and proportionate. Explain how those entries will be transferred, checked and then handled under the organisation's retention rules. Do not let a launch workaround become a permanent, ungoverned customer database. Include the temporary records in the final reconciliation.

Tell users exactly when the working system changes. A message should identify the affected team, the point at which they should use the new process and the support route for problems. Avoid broad announcements that leave staff unsure whether a particular task is included. The person receiving an enquiry needs a practical instruction, not a technical deployment summary.

Define recovery before it is needed

A recovery plan should distinguish restoring information from reversing every consequence of a change. An exported file may preserve data without restoring all settings, relationships or external actions. Ask what can actually be recovered through the supported tools and what requires manual work. The answer should reflect the systems and account capabilities involved.

Identify the last safe decision point and what changes after it. Once users have started editing new records or an integration has updated another system, returning to the old arrangement may need reconciliation. Document that work in advance. A simple instruction to “switch back” can hide a substantial data problem.

Test the recovery approach where practical and safe. The test might demonstrate access to the protected source extract, restoration of a controlled sample or the process for replaying approved changes. Choose evidence appropriate to the risk. A backup that nobody can retrieve in the required circumstances provides little confidence at cutover.

The NCSC's guidance on backing up critical data is useful background. For this project, ask the implementer to explain the actual recovery arrangement in ordinary language. Keep the accountable business owner informed about its limits, rather than burying them in a technical appendix.

Watch the first live work closely

After the agreed switch, check the first meaningful transactions through the whole included process. Confirm that users can access the right records, new inputs arrive and ownership is correct. Inspect important connections and reports using the agreed evidence. A successful login is only the beginning of this check.

Arrange a short period of clearly owned launch support according to the contract. Define how incidents are reported, who triages them and which business effects require immediate escalation. State actual support availability rather than implying continuous cover. Users need to know what will happen if an issue appears outside those hours.

At the end of the cutover, record the final state and any outstanding work. Include temporary measures still in use and who will remove them. Keep the old system's access or retirement decision separate from the excitement of a successful launch. Confirm that the business has the information and evidence it needs before ending an earlier service or deleting an agreed source.

Make the handover usable after the supplier leaves

A project can reach launch while leaving the business dependent on the person who built it. Handover should reduce that dependency through practical ownership, documentation and training. Agree these deliverables at the start, then test them before the support arrangement changes. The person taking responsibility needs more than a folder of screenshots.

Start with the routine work the internal owner will perform. They may need to add a user, investigate an unassigned record, check an integration alert or explain a dashboard filter. The handover should show how those tasks are handled within the agreed permissions and support boundaries. It does not need to turn every employee into a system administrator.

Train people on their own tasks

Group training by the work people do, with shared context where needed. A salesperson needs to practise progressing an opportunity; a manager needs to interpret the agreed report; an administrator needs to maintain the authorised arrangement. A single tour of every menu can leave each person uncertain about the few actions they actually need. If marketing emails will move into HubSpot too, our email marketing services guide covers deliverability, consent and what to expect from an external team.

Use controlled examples that reflect the team's common situations and exceptions. Ask participants to complete the task themselves, then discuss where they needed help. Record the gaps and assign follow-up. Attendance is evidence that someone joined a session, not proof that they can perform the work independently.

Keep instructions concise and findable. A short task guide with the relevant decision and support route can be more useful than a long recording that requires searching. Recordings may still help, especially for demonstrations, but explain which version of the process they show. Retire or update guidance when the underlying configuration changes.

Plan for new starters and absences. The business should know who can provide the same practical preparation later and where the current materials live. If that service remains with the supplier, make it part of the support agreement. Avoid assuming that an informal promise during implementation creates an ongoing training commitment.

Hand over the operating records

Bring together the field dictionary, migration acceptance, integration register, automation notes, report definitions and test results. These documents serve different purposes, so organise them around the task someone is trying to perform. An owner investigating a sync failure should be able to find the connection's scope and escalation route quickly.

Include a record of known limitations. Explain their impact and any approved workaround, with a named owner and review point. This prevents the internal team rediscovering an accepted issue and mistaking it for a new defect. It also stops a temporary compromise becoming invisible simply because the implementation project has closed.

Confirm that the business can access its documentation and supported administrative arrangements without using the supplier's personal account. Keep credentials out of ordinary handover files. Where a third-party service remains part of the solution, record the organisation responsible for it and the relevant contract or support reference.

Check ownership by asking the receiving person to perform an agreed maintenance task while the implementer observes. If they cannot find the necessary information, improve the handover before signing it off. This is a direct test of whether the documentation works for its intended reader, rather than whether the project has produced a document with the right title.

Separate defects, support and further development

After launch, requests arrive in different forms. Some concern a delivered feature that fails its agreed requirement. Others ask how to use it, change a business rule or add something new. Define where each goes and who decides the category. Users should have one clear starting point even if the supplier routes work differently behind the scenes.

Check what the support agreement actually includes. Record availability, response commitments if any, exclusions and how chargeable work is approved. A vague promise to “be there if needed” leaves both parties guessing. The business needs a predictable way to obtain help without treating every conversation as a new commercial negotiation.

Use a small change register for improvements. Record the problem, affected users, proposed change and expected benefit in practical terms. Before authorising a configuration change, consider its effect on data, automation, integrations and reports. This keeps a quick fix in one screen from quietly undermining an agreed rule elsewhere.

Review the first operating cycle

Choose a review point that allows the team to complete meaningful work through the new arrangement. The right interval depends on its sales or service cycle, not a universal number of days. Bring operational evidence and user observations to the review. Distinguish a process that is still being learned from one that does not fit the work.

Look for repeated exceptions. If the same records repeatedly need manual correction, investigate the source definition or rule rather than treating each case as isolated. If staff maintain a parallel list, ask what it provides that the agreed system does not. The answer may reveal a missing requirement, an access issue or guidance that was not clear enough.

Protect the original acceptance evidence while making improvements. Record changes and retest the behaviour they affect. A successful implementation is a maintained working arrangement, and maintenance needs an owner. With that responsibility in place, the business can decide what to improve next using evidence from its own operation rather than a list of unused features.

HubSpot implementation questions buyers ask

Can we implement HubSpot in stages?

A phased project can make sense when each phase delivers a usable piece of work and its dependencies are understood. Define what the first group of users can do at the end of the phase, which system holds the current information and how work passes to teams that have not moved yet. A phase should have its own acceptance evidence.

Be cautious about dividing the work only by technical component. Importing contacts in one phase and deciding their ownership much later may leave users with records they cannot act on. Ask the supplier to explain the temporary operating arrangement between phases, including duplicated entry, reconciliation and support responsibilities.

How long should we allow for a HubSpot implementation?

There is no reliable single duration without knowing the scope, data condition, integrations and availability of the people making decisions. Ask for a plan that identifies dependencies and the evidence needed to move between stages. The estimate should explain what assumes prompt approval, clean source information or access to another supplier.

Reserve time for your own team's work as well as the implementer's. Field definitions, privacy decisions, sample checks and user acceptance cannot all be delegated away. If the plan changes, ask which dependency moved and what the revised sequence means for business readiness. A date alone tells you little about whether the work can be completed responsibly.

HubSpot's own onboarding delivery periods give a useful outer reference: 60 days for Sales Hub Professional and 90 days for Sales Hub Enterprise and Marketing Hub Professional. A single team moving from spreadsheets often fits inside that window. Several hubs, a messy legacy CRM or custom integrations usually take longer, so plan stages rather than one launch date.

Do we have to move every historical record?

A migration scope can distinguish information needed for current work from information retained elsewhere for an agreed purpose. The decision should involve the people responsible for operations, retention and privacy. Record what will move, what will remain accessible through another approved route and what will be handled under the organisation's disposal process.

Test how users will answer a legitimate historical question after the change. Keeping an archive is useful only if authorised people can find and interpret the relevant information. Moving an old record into the new CRM does not make it current or suitable for every new use. Preserve the context and limitations that matter.

Can our own team do part of the implementation?

Yes, where responsibilities match the team's capacity and the agreed support arrangement. Internal staff often contribute the business definitions, record review and practical acceptance that an external implementer cannot decide alone. They may also perform configuration or imports if they have the necessary skills, access and a tested procedure.

Write down the handovers between internal and external work. Identify who checks an internally prepared file, who fixes rejected records and who approves the final result. Shared delivery becomes difficult when both parties assume the other owns a task. A clear boundary also helps distinguish implementation fees from the internal time the project requires.

Does onboarding include a complete migration and build?

The word “onboarding” does not establish a single scope across every provider or package. Read the actual service description and order. Identify whether the supplier advises your team, performs configuration, migrates data or provides some combination. Ask which deliverables and acceptance checks are included, rather than inferring them from the package name.

HubSpot describes its own onboarding services, while an external implementation contract may include different work. Compare the written responsibilities and dependencies side by side. If a task appears in neither agreement, resolve the gap before work starts. If it appears in both, confirm who is accountable for the final result.

Is HubSpot onboarding mandatory?

For several paid tiers, yes. HubSpot's catalogue marks onboarding as required, with a one-time fee, for Sales Hub Professional and Enterprise, Marketing Hub Professional and Enterprise and Service Hub Enterprise. Service Hub Professional lists no required fee. Partner arrangements and bundles can change what appears on your order, so ask HubSpot or your partner to confirm in writing what you are paying for and who delivers it.

What is the difference between HubSpot onboarding and a partner implementation?

HubSpot onboarding gives you a specialist who guides your team through setup remotely during a fixed period. A Solutions Partner implementation is usually hands-on: the partner designs and builds the configuration, migrates data, connects other systems and trains users. Many businesses use both. What matters is a single written list of tasks showing who advises, who builds and who signs off each one.

Can HubSpot integrate with Xero?

Yes. HubSpot's Xero data sync can sync contacts, products, invoices and payments, with one-way or two-way options depending on the object, and custom field mappings need at least Data Hub Starter. Decide which system raises invoices and which wins on conflicts before switching it on, and test an amended and a cancelled invoice as well as a new one.

Put a testable implementation brief together

A useful brief makes the finished work recognisable before anyone starts configuring it. Begin with the everyday tasks your team needs to complete and the information those tasks depend on. Keep the first agreed scope small enough to explain clearly, while including the connections required to make it usable.

• Define the records, relationships and field meanings before approving the migration.
• Require reconciliation evidence and a visible owner for exceptions.
• Test integrations, automation and reports with controlled cases and ordinary user roles.
• Agree launch conditions, recovery limits and the practical handover before setting the change in motion.

Bring those decisions and your remaining uncertainties to a conversation about the project. Book a 30-minute strategy call to discuss the implementation work your business needs and how to make its scope reviewable.