We launched a platform for a client last year. Beautiful design, solid engineering, thorough testing. Six weeks later, adoption was at 23%. The software wasn't the problem. The onboarding was. Or rather, the absence of onboarding was. We'd built a great product and assumed people would figure it out. They didn't.
Why Onboarding Gets Ignored
In every enterprise project we've delivered, onboarding is the thing that gets cut when timelines get tight. It's understandable. The stakeholders want features. The developers want to ship. The project manager wants to hit the deadline. Onboarding feels like polish, not substance.
It's not polish. It's the difference between a platform that gets used and a platform that gets abandoned.
40-60%
of enterprise software users will use the product once and never return if onboarding is poor
Source: Pendo State of Product Engagement, 2022
Tim: I've seen this pattern enough times to call it a law. The quality of onboarding predicts adoption more reliably than the quality of the software. I've seen mediocre software with great onboarding outperform excellent software with no onboarding. Every time.
The Three Layers
Enterprise onboarding isn't one thing. It's three layers, and you need all of them.
Layer 1: Organisational Onboarding
Before anyone touches the software, the organisation needs to understand why it exists and what it means for them.
Tim: This is change management, and it starts months before launch. Who is this for? What problem does it solve? What changes about their day-to-day? What stays the same? If you can't answer these questions clearly and specifically for each user group, you're not ready to launch.
The mistake most organisations make is communicating at the wrong level. "This platform will transform our operations" means nothing to the claims processor who needs to know whether they still use the same reference numbers. Communicate at the level of the individual's daily work, not the organisation's strategic vision.
Layer 2: First-Run Experience
The user's first interaction with the software. This is Rai's domain and it's where design makes or breaks adoption.
Rai: The first five minutes matter more than the next five months. In those first five minutes, the user forms an opinion about whether this system helps them or hinders them. That opinion is extremely sticky.
What works:
- A clear starting point. Not a dashboard with twelve empty widgets. One task. "Start here."
- Immediate value. Let them accomplish something real in the first session. Not a tutorial about the system. An actual task from their actual work.
- Progressive disclosure. Show them what they need now. Everything else can wait.
- Familiar patterns. If they used a previous system, mirror the critical workflows. Don't make them relearn things that haven't actually changed.
What doesn't work:
- Video tutorials. Nobody watches them. Nobody. We've measured this across four projects. Completion rate for onboarding videos is consistently below 15%.
- Documentation links. "For more information, see the user guide." No. The information they need should be where they need it, when they need it.
- Feature tours. "Click here to see the dashboard! Click here to see reports!" Tours show features. They don't demonstrate value. Users don't care about features. They care about tasks.
Don't show people what the software can do - show them what they can do with the software. That's the difference between a feature tour and an onboarding experience.
Rainui Teihotua
Chief Creative Officer
Layer 3: Ongoing Support
Onboarding doesn't end after the first session. The first month is a continuous onboarding experience.
Tim: This is where most organisations fall off completely. The launch happens, there's a flurry of training sessions, and then support drops to "log a ticket." The users who were willing to try something new get stuck, can't find help, and go back to the spreadsheet.
What works here:
- Embedded help. Contextual guidance within the application itself. Not a help centre. Tooltips, inline explanations, and smart defaults that reduce the need for help in the first place.
- Champions in each team. One person per team who knows the system well and can answer quick questions. This scales better than a central support desk because the champion understands the team's specific context.
- Feedback loops. A simple way for users to report friction. Not a formal change request process. A quick "this is confusing" button that goes to the product team. Most of what you learn in the first month will be things you didn't anticipate.
- Visible iteration. When you fix something based on user feedback, tell them. "You told us the search was slow. We fixed it." This builds trust that the system is improving and that their input matters.
The Metrics That Matter
Time to first value. How long between first login and completing a real task? This should be minutes, not hours. If users need a training session before they can do anything useful, the onboarding has failed.
Day-7 return rate. What percentage of users come back after a week? This is the strongest predictor of long-term adoption. If it's below 50%, investigate urgently.
Support ticket themes. Cluster the first month's support tickets by theme. The top three themes tell you exactly where the onboarding experience breaks. Fix those three things and adoption will improve measurably.
Task completion rate. For the three most common tasks, what percentage of users complete them successfully on the first attempt? If it's below 80%, the task flow needs redesign.
The Checklist
Before launching any enterprise platform, validate these:
- Each user group has been told what's changing and why, in terms relevant to their daily work
- The first-run experience has a single, clear starting point
- A new user can complete a real task within five minutes of first login
- Contextual help is available within the application, not just in a separate document
- Each team has an identified champion
- There's a mechanism for users to report friction quickly
- Day-7 return rate will be measured and has a target
- The team has capacity to respond to feedback in the first month
If you can't tick all eight, you're not ready to launch. Delaying launch by two weeks to get onboarding right is cheaper than spending three months trying to recover adoption after a bad first impression.