B2B SaaS onboarding examples: how 10 products get a new account working

How 10 B2B SaaS products handle data import, integrations, colleague invites and unfinished setup, read from their own help documentation.

  • Onboarding & Engagement
  • B2B SaaS and workflow software
  • B2B SaaS & Workflow Software
Insights

How 10 B2B SaaS products handle data import, integrations, colleague invites and unfinished setup, read from their own help documentation. In B2B software, the part of onboarding most worth studying, in our view, is not the welcome tour.

Insights · Article

In B2B software, the part of onboarding most worth studying, in our view, is not the welcome tour. It is how a product handles what has to happen before anything works: bringing in existing data, connecting other systems, getting the right colleagues involved, and showing an account where it stands while those are unfinished. These ten examples show how named products design for that, taken from their own help documentation.

This article is the worked-example companion to our guide to SaaS onboarding. The guide sets out the process. This page shows what parts of it look like in real products.

How we chose and read these examples

Most onboarding sits behind a sign-up, so we used the one public record of it that vendors maintain: their help centres and setup documentation. Every example below describes only what those pages said when we read them on 28 September 2026, and we checked each again on 13 October 2026. Where a page shows a last-updated date, we give it. We have not described screens we did not see documented, and we have not used screenshots.

We chose products whose documentation deals openly with at least one of four dependencies. They are grouped by the dependency each one handles most instructively, and several appear again in later sections.

  • Existing data: HubSpot, Pipedrive, Notion, Linear.
  • Reducing what has to be brought in: Attio, Stripe, Amplitude.
  • Other people and systems: Vanta, Intercom.
  • An unfinished account: Ramp, with Pipedrive again.

Each entry separates what the documentation shows (fact) from what we would take from it (our judgement). Documentation shows how a vendor intends onboarding to work. It does not show how often accounts succeed, and none of the pages we read published figures for that.


Bringing in existing data

This is the ugly part. Customers arrive with spreadsheets, an old system or years of history, and the product is empty until some of it arrives. The four examples below take different positions on where errors get fixed, what can be undone and how much should come across at all.

1. HubSpot: fix the file inside the import, and say exactly what didn't land

What the documentation shows. HubSpot's import guide (updated 7 October 2026) has people map each file column to a HubSpot property, and a column can be set to "Don't import column". If values are wrong, people can edit the errored values on the mapping screen, entering or selecting a replacement for each row, or choose not to import that value. To update records that already exist, the file needs a unique identifier, such as a record ID, an email address for contacts or a domain for companies.

After the import, HubSpot's error guide (updated 25 September 2026) says people land on a summary that includes an overview of errors. They can download the errors as a file and view the rows that contain errors. The same page explains that when a value isn't imported, other columns in that row could still be imported.

What to take from it. Two decisions stand out. First, repair happens where the problem is found, not in a spreadsheet the customer has to fix and upload again. Second, partial success is spelled out at column level, so the account can see what is missing rather than finding out later from a report that looks wrong. Ask of your own import: when it half works, does the customer know which half?

2. Pipedrive: preview first, allow a way back, and hand full migrations to a specialist

What the documentation shows. Pipedrive's spreadsheet import article (updated 19 October 2026) lists five steps: file information, upload, map fields, preview and finish. The preview shows how the data will appear after import, and when duplicates are detected the import offers to merge them instead of creating new records. Rows that fail go into a skip file that explains why each entry wasn't imported, so they can be corrected and imported again. Users with global admin permissions can revert an import from the import history tab within 48 hours.

For customers moving from another CRM, Pipedrive's migration article (updated 3 September 2026) points to Import2, a third-party partner. The customer supplies login credentials for their previous CRM and chooses whether pipelines, stages and custom fields are created automatically. The article says Import2 offers free migration of up to 1,000,000 records, with paid migrations above that. It suggests allowing 24 hours, and directs problems to Import2 rather than to Pipedrive.

What to take from it. Pipedrive splits the job by source. A spreadsheet is self-serve, with a preview and a time-limited undo, so a first import doesn't have to be a one-way decision. A whole system is handed to a specialist. That split is worth copying: the failures in a CSV import and in a system-to-system migration are different, and so is who should own them. Note one detail, though. Only global admins can revert, so the person who ran an import may need a colleague to undo it. The dependency on another role can come back at the recovery step.

3. Notion: say what won't survive before people start

What the documentation shows. Notion's import help page (read 28 September 2026) covers importers for apps such as Evernote, Trello, Quip and Google Docs, and for file types including CSV, Word, HTML, PDF and Markdown. For each source it lists what imports and what doesn't. For Google Docs, for example, suggestions and comments from other users don't come across. It gives file-size limits for most file types (5 MB per file on the free plan, 50 MB on paid plans) and warns that very large files can fail or partially import. For database imports it says plainly: "Imports add rows. They don't update existing rows, so watch for duplicates."

What to take from it. For a documents and knowledge product, the question customers bring is fidelity: what will my content look like afterwards? Notion answers that per source, before the import rather than after. The duplicate warning is the honest version of a limitation other importers can share. Compare HubSpot, which gives people a way to update existing records by identifier. If your import can only add rows, telling people so in advance is cheaper than a support queue of doubled records.

4. Linear: treat import as a choice, and let the old tool keep running

What the documentation shows. Linear's import documentation (read 28 September 2026) recommends dedicated in-app importers for Jira, GitHub Issues, Asana, Shortcut and Linear itself, with a command-line tool as the alternative. It says the dedicated importers keep more data and allow an import to be deleted in bulk. Running an import needs an Admin role in Linear, and possibly high permissions in the source tool.

The importer's path is to connect the source and choose a team, review the issues, projects, labels and users fetched, and choose which issues to import (active-only, or broader sets such as completed issues, depending on the source). For each user fetched, the admin chooses not to import them, to create a new user from an email address, or to map them to an existing Linear user. Imports can be deleted for a limited time after creation. Before any of this, the page asks which data is worth importing at all.

Linear's Jira integration page adds a second route. Teams that would rather not migrate everything at once can run Jira and Linear in parallel with a one-way or two-way sync. The page advises enabling the integration before importing, because running an import alone does not sync the imported issues. It also asks each user to link their own Jira account so that fields such as assignee and creator are handled properly.

What to take from it. Three ideas are worth borrowing. The import is framed as a decision about what to bring, not a copy of everything. People are part of the data: mapping users forces the question of who belongs in the new workspace. And the sync means an account doesn't need a cut-over day. One team can start while the rest of the organisation stays where it is, which removes the biggest dependency of all: everyone agreeing to move at once.


Reducing what has to be brought in

Some products make the dependency smaller instead of guiding people through it. Three different approaches follow.

5. Attio: connect the inbox instead of importing a spreadsheet

What the documentation shows. Attio's email and calendar sync page (modified 10 November 2026, per the page's metadata) describes each team member connecting their own email and calendar from their account settings. Attio then brings in past and future emails and events and creates people and company records from them. The default setting, selective contact creation, creates people records only for contacts the team has emailed or met, and not for people who emailed without a reply. The page says this is to keep out spam, notifications and newsletters. By default, metadata and subject lines are shared with the team, and internal emails and calendar events are hidden.

What to take from it. A CRM's existing data mostly lives in its customers' inboxes, and Attio reads it from there rather than asking for an export. Two defaults make that acceptable: a filter that stops junk becoming records, and a privacy setting that shares less than everything. The trade-off, which is our inference and not something the page states, is that the dependency moves from data to people. Because each person connects their own account, the workspace fills in as colleagues join. The invite becomes the import.

6. Stripe: separate what can start now from what waits on verification

What the documentation shows. Stripe's account set-up page (read 28 September 2026) says that after creating an account you can test Stripe services in a sandbox, and that using a service in live mode requires verifying the business and completing its activation requirements. Stripe's sandbox documentation explains that sandbox payments aren't processed by card networks or payment providers. An account can invite another user, such as an implementation partner or design agency, into its sandboxes without giving them access to live data. The version of the same page that Stripe provides for coding agents says they can use the Stripe CLI to create an anonymous sandbox with working API keys, with no account registration required.

What to take from it. Stripe divides onboarding by which dependency is slow. Business verification takes paperwork and someone with authority, so it gates live use and nothing else. The developer's work, building and testing the integration, starts on the first day. The scoped invitation lets an outside party help without trust decisions about live data. The lesson for any product with a slow gate such as security review, procurement or verification is to ask what can safely happen before it.

7. Amplitude: slow down where a mistake can't be undone

What the documentation shows. Amplitude offers a separate demo account that comes pre-loaded with data, and needs only an email address to sign up. For a customer's own organisation, Amplitude's getting started documentation (read 28 September 2026) advises setting up at least two projects, one for staging and one for production, before shipping instrumentation. It says Amplitude "can't retroactively change historical data", so if the instrumentation is wrong, the data already collected can't be cleaned up.

What to take from it. Here the dependency is the customer's engineering work, and a mistake in it is permanent. So the documentation deliberately slows people down: test somewhere safe before real data arrives. People who want to see value first get a demo account, kept entirely apart from their own data. Compare Pipedrive (below), which puts labelled sample records in the real account. Both are defensible. Our view is that the right choice depends on whether sample records could contaminate something the account will later rely on, such as reports and analytics.


Getting other people and systems connected

In B2B, the person who signs up may not be able to finish setup alone. These two products design for that, and Vanta says it outright.

8. Vanta: order the integrations, and help the buyer ask the colleague who holds the keys

What the documentation shows. Vanta's integration order guide (updated 10 July 2026) says "the more integrations you have, the more tests Vanta can run automatically". It sets out four phases. The cloud provider and identity provider come first. Device management, version control and vulnerability scanning follow, then the HR system and task tracker, then specialised tools. It explains that the identity provider defines the employee list for personnel tests, and advises: "If you only connect two integrations this month, make them Phase 1."

A second article, on working with system owners (updated 10 July 2026), starts from the fact that the person running a compliance programme often lacks admin access to systems such as Okta, AWS or GitHub. It calls getting time with those colleagues "often the biggest bottleneck in onboarding". In the product, an integration can be assigned to a system owner, who receives a notification. Vanta says this creates "a clear record of who is responsible" and a visible deadline. The article also provides message templates and a prepared answer to the likely security objection: Vanta requests the minimum permissions each integration needs, typically read-only access for monitoring.

What to take from it. This is the most direct example we found of a product designing for the colleague who holds the next step. It orders the work by what each connection unlocks, makes the request inside the product with a named owner and deadline, and equips the buyer to answer the colleague's first question. The "only two this month" advice also accepts that setup will be partial for a while, and says which partial state is worth having.

9. Intercom: invite the developer at the step that needs them, with only the access that step requires

What the documentation shows. Intercom's web installation article (read 28 September 2026) includes an optional step headed "Ask your developer to help". The person installing the Messenger can click Invite teammate and enter an engineer's email address. The article says the invited teammate gets a lite seat on Advanced and Expert plans or a full seat on Essential plans, with the minimum permissions required to install the Messenger: managing general and security settings, Messenger settings and workspace data.

What to take from it. The invitation sits at the moment the non-technical buyer gets stuck, not in a general "invite your team" screen. The access granted fits the task. Seat type is part of the design too: if bringing in a developer costs the customer a full seat, some may stall rather than pay. (We have not checked what each seat type costs, so we make no claim about that here.)


What an unfinished account sees

Accounts spend days or weeks partly set up. What they see in that time tells them whether they are making progress.

10. Ramp: a setup guide that reflects the account's real state

What the documentation shows. Ramp's getting started guide for admins (read 28 September 2026; no date shown) says admins see the Setup Guide in the product for their first 90 days. It states that "most Setup Guide tasks clear only after you finish the related setup in Ramp", and that a task can be dismissed or skipped only if it shows a Dismiss or Skip this task option. It adds that some onboarding experiences also let an admin hide the whole Setup Guide, which may be reopened later.

What to take from it. A checklist that clears when the work is done, rather than when someone ticks it, shows the account's true state. Letting only some tasks be skipped means the product has decided, task by task, what can safely wait. The principle is worth copying: let people safely defer what can wait, and mark clearly what cannot. The 90-day window also acknowledges that finance set-up spans weeks and several people, not a single session.

Pipedrive again: sample data that labels itself

Pipedrive's sample data article (updated 3 September 2026) says new accounts include sample records, each marked with "[Sample]" at the start of the deal, contact, organisation or activity name. Only global admins can remove them, from the Quick help panel, the import page or the Insights section.

The label is doing the work here: an account can explore a populated product without mistaking invented deals for real ones. The admin-only removal is a trade-off. It protects against accidental deletion, but a non-admin user can't clear the samples themselves.


What the import examples add up to

Set side by side, the four import examples show the decisions any import has to make. The table records only what each page we read stated. "Not stated" means the page didn't cover it, not that the product lacks it.

DecisionHubSpotPipedrive (spreadsheet)NotionLinear
Check before committingEdit errored values on the mapping screenPreview of how data will appearPer-source list of what won't importReview of fetched data; choose which issues
When some rows failError summary, downloadable errors, rows with errors viewableSkip file explaining each failure, for correction and re-importVery large files can fail or partially importNot stated
Existing recordsUnique identifier needed to updateDetects duplicates and offers to merge themAdds rows only; warns about duplicatesRe-importing the same source to the same team skips issues already imported
UndoNot statedRevert within 48 hours, global admins onlyNot statedDelete an import for a limited time
People in the dataNot statedNot statedNot statedMap, create or skip each user

Four points follow from the table, and they are our judgements rather than findings.

  • Put repair where the error is found. Sending people back to a spreadsheet creates a loop that can end with the account giving up.
  • Report partial success precisely. An account that doesn't know what failed stops trusting everything that imported.
  • Make the first import reversible. An undo window turns a risky one-way step into something people can try.
  • Decide what not to bring. Linear's "which data is worth importing?" is a better opening question than "upload everything".

On building or buying the importer: embedded import tools exist for this job. Flatfile's developer documentation, for example, describes an embedded importer that handles upload, mapping, validation and transformation inside the host product, while the host decides when imports happen and what schema they target. We haven't compared these tools and don't recommend one. Pipedrive's use of Import2 shows a third route: a migration partner for the system-to-system case. Whichever route you choose, the decisions in the table stay yours, because they determine what the customer experiences.


What these examples cannot tell you

Help documentation is written by the vendor and describes intended behaviour. It doesn't show how many accounts complete these steps, how long they take, or whether the design improved activation. None of the ten pages we read published figures for that. The same design can succeed in one product and fail in another with different customers.

The wider evidence is also thinner than the onboarding advice suggests. Rocketlane's 2025 survey of more than 950 onboarding leaders and practitioners named unclear expectations from the sale, stretched teams, siloed tools and unclear ownership as recurring obstacles. Its published summary does not single out data migration or integrations, and its respondents are implementation and onboarding teams, not self-serve users. Vanta's documentation, quoted above, calls getting time with colleagues often the biggest bottleneck in its onboarding, but that is one vendor describing its own product. Our view is that for B2B accounts the dependencies above matter more than the welcome tour. That is a judgement, not a measured result, and the way to test it for your product is to find where your own stalled accounts stopped. Who can audit your SaaS onboarding flow? sets out how to find where new users drop out and why they stop.


Where Tcules fits

We design and build the product surfaces these examples depend on: the role and permission model, set-up and import flows, invitation steps, empty and partial states, and the instrumentation that shows where accounts stop. We don't own your activation numbers and won't promise them.

If accounts are stalling and the team can't agree why, a UX Product Audit follows the affected workflow, investigates the cause and hands back a decision queue that separates quick corrections from structural work. Where the answer is structural, Information Architecture and Workflow Design settles the roles, objects and states, and SaaS and Web Application Development carries them into working import, set-up and invitation flows.

About the authors

  • Yash Gidwani

    Product Designer

    Yash Gidwani is a Product Designer at Tcules who writes about getting people into a SaaS product and keeping them there. Yash's guides cover SaaS onboarding strategies, onboarding and engagement software, and redesigning a live product without upsetting the people who use it. Other articles go into specific workflows: lending and loan origination apps, insurance quoting and claims, staffing and recruitment software, and a search-first create flow that stops duplicate records. Yash has also co-written the SaaS UX audit checklist and a 20-question checklist for legacy modernisation readiness.

    More from Yash
  • Rushali Bhatt

    Product Designer

    Rushali Bhatt is a Product Designer at Tcules. Rushali's articles start from the people inside complex software: clinicians and patients in healthcare products, users who cannot take part in research sessions, and the reviewers who check an AI feature's output before anyone acts on it. Topics include usability studies for enterprise software, human-in-the-loop patterns, a readiness checklist for AI product UX, what to fix first when adding AI to a live SaaS product, and what a heuristic evaluation should deliver. Useful reading for product teams whose software people rely on to make decisions.

    More from Rushali

Get new accounts working sooner

Show us where setup stalls: import, integrations or invites.