Your platform onboarding probably sucks.
Here's how to fix it.
In my role, I interact with platform teams across industries, from small startups to large enterprises. A common issue I encounter is the lack of awareness around the onboarding process for new users—and the significant impact this can have on adoption.
In a 2021 survey by Sitel Group looking at the importance of customer experience, they found that “a third of consumers considered severing ties with a brand because of a poor experience”. If your team embraces the platform-as-a-product mindset, there are crucial lessons to draw from this.
Why is the onboarding journey so important?
I’ve spoken before about the Diffusion of Innovation and challenge of elevating the adoption of a platform from being a niche solution to one that is ubiquitous within an organisation. In his book, Crossing the Chasm, Moore explains that innovators and early adopters—representing about 16% of an organisation—are often willing to tolerate rough edges, motivated by novelty or vision. The early majority, comprising 34%, is key to ‘going mainstream.’ They prioritize proven reliability, a clear value proposition, and ease of use. This shift in expectation catches many platform teams out.
What’s in a name?
A users’ journey often begins by hearing the name of your platform. When naming your platform, you want something that is unique in your organisation, is easy to spell, and isn’t too specific in terms of its function or the technologies that it uses.
The biggest red flags when it comes to naming are:
Your platform has a version number: if this is “platform 2” or “platform 3”, that signposts that you’ve been previously been unsuccessful, and will have users wondering if this latest version will follow the same path.
Your platform is a forgettable “TLA”: businesses love a three letter acronym, but that means there are so many that they immediately become forgettable. Worst still, the first letter is usually wasted by referencing the company name.
Your platform is named after a technology: there is no faster way to show that you value technology over people by including the name of a technology, or worse, a technology vendor, in the name of your platform.
You need a landing page
Once a prospective user has heard about your platform, they’re next step is to learn more about it. But where should they look? I’m always dismayed at how big a challenge “discovery” is within large or even medium-sized businesses.
I’ve written before about the benefits of having a simple product website for your platform to act as a landing zone for new and existing users. In my experience, this is the single best improvement you make to improve your onboarding journey and boost adoption for your platform.
The purpose of the landing page is to deliver your “elevator pitch” to prospective customers. You want to clearly articulate a few key pieces of information in a succinct and visually appealing format:
what problem does the platform solve?
what are the top five capabilities that your platform provides?
where can they get more information?
You don’t need a professional website design company to do this for you, there are plenty of templates available online, or even if you don’t have any technical skills, Canva have a great tutorial that steps you through how to create one using their platform.
Your documentation sucks
Whilst many teams might see documentation as a necessary evil, I believe the art of intentionally recording your knowledge is one of the most selfless and positive changes you can make in a business. Writing good documentation is hard though!
I’m sure we’ve all read through instructions that have proven to be more frustrating than if there were none at all. Maybe it’s too long to find what you’re looking for? Or you can’t make sense of the language? Or it’s peppered with links to other website you need to read first? Maybe there’s steps missing? Or maybe you just couldn’t get the simplest of examples working. You try your best to work through it, but in the end, you give up and search for a different solution.
I could dedicate a whole article to this one subject, but my top tips are:
Focus on the goal of making simple things easy, and hard things feel possible.
Write for your audience. Write for your audience. Most documentation assumes the reader has too much prior knowledge. Remember, others might want to learn about your platform too—executives, finance teams, compliance officers, and more. Don’t leave them behind.
Use simple language and avoid technical jargon where possible. It’s reported that 54% of U.S. adults read below a sixth-grade level. Metaphors and visuals are a great way to convey complex concepts in a more digestible format.
Have a dedicated Getting Started guide written specifically for new users, that gives a high level explanation of the platform and provides some simple “hello world” type examples.
Ensure your documentation is organised into logical, modular sections that are self-contained. I recommend aligning these to user intent, rather than functional area. The Kubernetes documentation is a good example of this.
Provide simple, worked examples. People learn by doing, and enabling them to get even the most simple example up and running will give them confidence in their ability to use your platform to solve more complex problems.
Have someone outside your team review your documentation and test your examples. As someone working with the platform, it’s easy for your to assume too much from your reader, or miss a step in an example.
Keep your documentation up to date. If getting people to write documentation is hard, getting them to keep it up to date is near impossible! Companies will often assign a Directly Responsible Individual, but I find it more helpful to measure user engagement with documentation to help identify what pages are most read; which are viewed for short periods of time; and what are people searching for that we might not have a page for.
Why does it need to be so difficult?
Teams will often agonise over the implementation of a specific platform features, but it baffles me why it feels like minimal effort is put into making it quick and easy for people to get access to the platform in the first place!
I think the most simple answer is that those building platforms never go through the onboarding experience themselves. This is compounded by the IKEA effect, where we put too much value into something we had a hand in creating, making it difficult for us to listen to negative feedback from others.
I’ve seen lots of examples of this on my travels, working with organisations of all sizes, across every industry:
The irony of a manual onboarding process being needed to gain access to a self-service platform. If you can’t fully automate the process, then do your best to fake it, by carrying out any human-in-the-loop tasks asynchronously.
Time-consuming approval steps or other barriers are sometimes necessary where there is a business cost involved with onboarding. One great solution to this is to offer immediate temporary access to your platform for free for 30 days. This is long enough for someone to decide if your platform helps them, and raise the necessary request to gain full access.
Most recently, I’ve seen organisations demand that employees complete mandatory training on security policies or artificial intelligence guidelines. Such things may be necessary, but they should be required within a period of joining the platform rather than a pre-requisite.
The vibes are off
First impressions are often visual, and aesthetics play a much bigger role in adoption than many platform teams give them credit for. Your platform’s look and feel sends a powerful message about its quality, care, and user-centricity.
If your platform interface looks outdated or inconsistent, it can deter users—even if the functionality is excellent. Is the branding cohesive? Are the color schemes visually appealing? Is the tone of your messaging welcoming and approachable? These details might seem trivial, but they set the tone for user engagement.
Beyond appearances, the wording you use is just as critical. We might be building automation robots, but we don’t need to sound like one! Does your copy feel clear and human? A user-friendly tone can make your platform feel approachable to a broader audience, from engineers to executives. Remember, a little polish goes a long way in making people feel confident about engaging with your platform.
Please hold, your call is important to us
Even the best platforms need support systems, but nothing erodes trust faster than unresponsive or ineffective help channels. The ease and speed with which they can get help will significantly impact their perception of your platform.
When a user hits a problem, your primary goal is to minimise their frustration.
Building an effective support framework starts with understanding the communication mediums that users are likely to use, along with the advantages and disadvantages of each of them.
Support Tickets provide accountability
Support tickets are universally hated, but they do provide a record of the request, and are often integrated into other systems to aid collaboration across teams.
Use support tickets to record outages, defects, or anything else that is likely going to require follow up.
Email is great for clarity
I generally suggest avoiding email communication, but it’s the most ubiquitous, compatible message format available that remains the primary communication tool for some teams.
Email is a good platform where you want to convey a complex topic with clarity. It allows you to put a lot of information in one place, as well as including diagrams, etc.
Setup an email alias for your platform that is easy to remember. When a user has a problem, they don’t want the additional problem of trying to work out what overly complicated name for your distribution list might be. Strongly encourage users to use the alias and not to contact individuals directly.
It can be useful to set up an auto-responder to acknowledge receipt of the email immediately and advise the user on the likely response times. This is a good opportunity to direct them to raise a ticket for something important, or to seek support in chat for quick resolution of simple problems.
Chat is built for responsiveness at scale
Chat systems like Slack or Teams are likely the most communication tool used amongst developers and engineers.
It’s not uncommon to find competing chat tools in an organisation. It is vital that your team is present wherever your user base is - even if that’s not your platform of choice.
Chat is ideal for solving simple queries quickly. This is phenomenally important when users are “in the flow” and would get frustrated if they need to wait hours or days for an answer by email or support ticket.
Chat moves quickly, your team should aim to answer queries within 30-60 minutes. It’s a very bad look if various people are chatting in realtime about your product and your team are nowhere to be seen.
Chat is a fantastic way of building a relationship with your users. Unfortunately, it’s just as easy to permanently ruin any credibility you’ve built up! Think of it like a “public” customer service platform. I strongly encourage platform teams to have a separate “internal” channel where they can discuss and debate topics. Users shouldn’t see “how the sausage is made”.
It’s often tempting to solve matters in private, but engineers should always update the chat platform with the outcome. Not only does this help users find solutions in future searches for similar problems, but any prospective users visiting the channel will see things being followed up. Seeing a problem reported and then no solution is not a good look.
The "TLA" comment where the first letter is the letter of the company name. So true!