What real onboarding for an AI platform should include

Most software onboarding is a welcome email, a login, a link to a help center and maybe a recorded webinar. For a tool that does one thing, that can be enough. For an AI platform your team will use to build its own tools, it is not. The hard part is not learning the buttons. The hard part is deciding what to build first, describing your real work clearly, setting up access and budget so nothing goes wrong, and getting a team to switch from the way they have always worked.

This guide lays out what real onboarding for an AI platform should include, stage by stage, what to ask a vendor before you sign, and how to tell good onboarding from a login and a video library.

Why onboarding decides whether AI works in your company

AI use at work is growing but still uneven. Gallup reports that as of May 2026, 15% of U.S. employees use AI daily in their role and 30% a few times a week or more, while 52% use it at least a few times a year. That gap between occasional and regular use is where most AI investments stall. People try it, get something that is almost right, and drift back to what they know.

Developers feel the same pull. In Stack Overflow's 2025 survey, 66% named "AI solutions that are almost right, but not quite" as their top frustration with AI tools, and 45% said debugging AI-generated code takes more time. Microsoft's 2026 Work Trend Index found that 86% of AI users treat AI output as a starting point. If trained developers need structure to get value from AI, a team of managers, coordinators and technicians needs it more.

Good onboarding closes that gap. It turns "we have access to an AI platform" into "our dispatch board runs on a tool we built, and here is what it saved."

The six stages of real onboarding

Stage 1: The workflow workshop

Onboarding should start with your work, not the software. A good workshop is a working session, usually a couple of hours, where someone who has seen many teams sits with yours and does three things:

1. Lists the workflows that cost the most time. Not every workflow. The ones that eat hours, cause errors or make customers wait.
2. Picks the first one. Repeated often, clear start and finish, spread across email, texts and spreadsheets today, and owned by a manager who wants it fixed.
3. Maps it step by step. Who starts it, what information comes in, who touches it next, what counts as done, and who needs to know.

If a vendor's onboarding starts with a product tour, ask when they will look at your work.

Stage 2: Access, roles and budget, before anyone builds

Setting up the workspace correctly at the start is far easier than fixing it after twenty people have built things. Onboarding should cover:

• Who gets in. Invite-only access, so only the people you choose can join.
• Roles. Who owns the workspace, who administers it, who can build, and who only uses tools. Each role should see and change only what it needs.
• Budget. A spending cap, with alerts before you hit it. Confirm nothing bills by itself.
• Ownership. Every tool has an owner and a backup, so it stays with the company when people change jobs.

Check which of these the platform includes on the plan you are buying. Across the category, the controls companies need often sit on higher tiers. According to the vendors' own pages as listed in October 2026, Lovable's audit logs and SCIM (automatic user provisioning from a central directory) are Enterprise only, Replit lists SSO, SCIM and audit logs as Enterprise only, and Retool's SAML/OIDC single sign-on and SCIM are Enterprise only. Know what your plan includes before onboarding starts, not after.

Stage 3: The first real tool, on day one

The single best sign of good onboarding is a real tool your team uses, built from the workshop, on the first day. Not a demo app. Not a sample template. The workflow you mapped in stage 1.

The people who do the work should be in the room while it is built. They catch the details that make a tool usable: the field nobody remembers until it is missing, the approval that only applies above a certain amount, the status the night shift uses.

Example: a 30-person HVAC company's onboarding workshop picks "service call to invoice" as the first workflow. By the end of the day the dispatch manager and two office staff have a working tool: calls logged with customer and equipment details, jobs assigned to technicians, technicians updating status and adding photos from their phones, and completed jobs landing in a queue for the office to invoice. The team uses it the next morning.

Stage 4: Training each person on their part

Do not train everyone on everything. Train each person on the part of the tool they use, on a live item, in about ten minutes.

• Builders learn how to describe a tool clearly, how to ask for changes, and how to check a result.
• App users learn the two or three actions their job needs.
• Managers learn how to see status, approve, and spot what is stuck.
• Admins learn how to invite people, change roles, remove access and watch the budget.

Stage 5: The switch

A tool nobody switches to is a tool nobody uses. Onboarding should help you set a switch date, announce it, and close the old channels on that date: the spreadsheet becomes read-only, job details stop going out by text, the shared inbox points to the new tool. Expect a week of small fixes. That is normal, and it is where the tool becomes the team's own.

Stage 6: Follow-through over the first month

Onboarding should not end when the first tool goes live. In the first month, a good onboarding team will:

1. Check in after the first week to fix friction.
2. Measure the workflow against where it started: time per item, items waiting, errors.
3. Help pick the second tool, and the people who will build it.
4. Review roles and budget now that real use has started.

Signs onboarding is working

You can tell within two weeks whether onboarding took. Look for these signs:

• People open the tool without being reminded. The first team uses it every working day because it is the fastest way to do their job.
• The old channel goes quiet. Fewer job details by text, fewer "did anyone see my email" messages, a spreadsheet nobody has edited since the switch date.
• Requests for changes come in. A team that asks for a new field or a new status is a team that has adopted the tool. Silence usually means they went back to the old way.
• Someone outside the first team asks for a tool. Word travels when a tool saves real time.
• The owner can see what happened. Who built what, who changed what, and what it costs, without asking anyone.

And watch for the warning signs: one person doing all the data entry for everyone, the spreadsheet quietly revived "just for now," or a manager who still asks for status by phone. Each one points to a gap in training or in the switch, and each is easy to fix in the first month and hard to fix after.

Good onboarding versus a login

Questions to ask a vendor about onboarding

1. Who runs our onboarding, and have they worked with teams like ours?
2. Does onboarding start with our workflows or with your product?
3. Will we have a real tool in use on the first day?
4. What do you set up with us on access, roles and spending before anyone builds?
5. Which of those controls are included on the plan we are buying?
6. How do you train people who only use the tools, not build them?
7. What happens in the first month after launch?
8. Is onboarding included, or priced separately?

What to prepare before your onboarding

You will get far more out of onboarding if you bring a few things with you.

• Your top three time-wasting workflows, with a rough count of how often each runs.
• Real examples: the spreadsheet, the paper form, a screenshot of the group text, the email template.
• The people: a decision-maker, the manager of the first team, two or three people who do the work, and whoever handles IT.
• Your rules: approval limits, who can see pay or customer details, anything regulated.
• A budget: what you are willing to spend in the first month, so caps can be set correctly.

Onboarding checklist

1. Book a workflow workshop, not a product demo.
2. Bring your top three workflows and real examples of how they run today.
3. Invite the decision-maker, the first team's manager, two or three doers and your IT lead.
4. Set invite-only access, roles, ownership and spending caps before anyone builds.
5. Confirm those controls are included on your plan.
6. Build the first real tool with the people who do the work, on day one.
7. Train each person on their part, on a live item.
8. Set a switch date and close the old channels.
9. Measure results at the end of the first month.
10. Pick the second tool and the people who will build it.

Mistakes to avoid

• Treating onboarding as training. Training teaches the software. Onboarding gets your work into a tool.
• Starting with the hardest workflow. Payroll and billing can wait until the team has a win.
• Skipping the IT lead. Even a part-time IT person should hear how access, roles and data work. It saves an argument later.
• Letting everyone build on day one. Start with a few builders and a clear first tool. Add builders as the team learns what good requests look like.
• No switch date. Without one, the old way never ends.

How FORGE handles it

Our team onboards every company ourselves, and every onboarding starts with a workflow workshop on your real work. We sit with your people, find the work that costs you the most time, and help them describe their first tool in plain words. Most teams have their first real tool the same day.

We set up the workspace with you before anyone builds. Every app lives inside your company, people join only by invite, and owners, admins, builders and app users each see exactly what their role allows. A complete record of who did what is there from the first build. A panel of top AI models plans each tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved, so the first tool your team uses is one they can rely on.

Spending is set up with you too: $49 a seat a month with 3 builds, packs of 10 builds for $150, app users free, a build FORGE fails is free, and caps and alerts at 80 and 100 percent so nothing bills by itself. Web, mobile and desktop apps are all part of the same workspace. See how it works, review security, or talk to us to book your workshop.

Questions people ask

Sources

1. Stack Overflow Developer Survey 2025: AI
2. Microsoft Work Trend Index 2026
3. Gallup: AI use at work indicator
4. Lovable plans (docs)
5. Replit pricing
6. Retool pricing