User onboarding in enterprise applications
User onboarding in enterprise applications
For a long time, enterprise applications were sold by salesmen in their finest suits, who travelled around the world making fancy presentations to the top CXOs and managers just to get them to invest $$$$$$ in their applications. The term onboarding, only was part of the “professional services” catalog that was offered to their customers. And since it was was done by trained personnel, the enterprise applications didn’t really bother much about onboarding process. It was after all a highly lucrative.
But then one day, internet happened and then cloud.
Vendors started selling enterprise applications online. First came the on-premises web apps and then cloud(SaaS) which basically disrupted the whole space.
As the internet provided scale and reach, having an equivalent dedicated onboarding personnel didn’t make sense. And a direct consequence of this is having a cheaper and highly scalable onboarding in place.
On the other side, this also disrupted enterprise software purchase.
Anyone in the organization now had access to information about various software products to make informed decision. A free trial period also gave them the power to explore the product on their own, in their environment before making a purchase.
With that bit of onboarding to the topic, let’s move ahead.
Consumer vs enterprise onboarding
Well, one thing I have learned from my grandma is that it’s a lot easier to learn new thing if we can relate it something we already know.
So, a familiar place for enterprise onboarding is consumer onboarding. After we are all consumers, aren’t we?
We use applications like Instagram, Twitter, Snapchat, Whatsapp, Trello, Feedly, etc. on daily basis. So, if we are to create a cohort of users for these applications, we could extrapolate it into one giant cohort called daily users. After all, the product teams in these companies are quite obsessed with Daily Active Users(DAUs) and Monthly Active Users(MAUs).
Well now consider the ones you use at work(enterprise applications) like Outlook, Zoho Docs, Box, Gmail, MS Teams, etc. and even function specific tools say Salesforce, Workday, Quickbooks, Citirx, etc..
These applications are also being used daily, right? So, in that sense, enterprise applications are very similar to consumer applications.
But, it differs in one major aspect. Choice.
You don’t have the choice to choose the application you use at work. All the applications that you use are provided to you by the organization.
That means, someone needs to “manage” these applications for the whole organization. They decide who gets access to what and when.
Well, let’s call these folks admins.
The first difference is enterprise has at least two types of users. At least because depending on the product, there can be different types of daily/admin users.
Yes, there’s going to be a lot of “depends”.
An enterprise application is trialed by an team member, bought (licensed to) by the purchase department, managed by team lead and then used by the team.
Well, here is the second difference. For an enterprise application, trial user and customer can’t be onboarded the same way.
Now, let’s zoom in a bit into trial users.
Consumer applications have only one type of user, you’d expect that person who tries the product to buy the product. For example, if you want to be more organized, you try Trello and buy the subscription if you find it worthy. (FYI, Trello also has a business offering). This way, you are not just a trial user, but you double up as evaluator as well.
Unlike a trial user, evaluator is looking for a product that could solve their problem and are willing to buy the product, if need be. Evaluators are more likely to convert into paying customers than mere trial users.
Let’s take same Trello example, if you are evaluating, you are trying to find answer to questions like:
1. Does Trello really help me keep things organized?
2. Can I categorize my tasks and add notes to them?
3. Can I move tasks around? etc.
Now, who evaluates enterprise applications? Most likely the admins (leads, managers, directors, VPs, CIOs, etc.) Evaluation is rarely done by a team member, even though they often recommend products. Ideally, anyone if free to try a product, but the one who evaluates has the power to decide if their organization(or the functional unit) can use it or not. They ask the difficult questions because they are responsible for providing a solution to a problem(at at least most important) and are accountable for the investment made. Yeah, it’s not an easy ordeal.
This brings us to the third major difference. The enterprise applications are generally evaluated by admin users not daily users.
To summarize,
The Myths
One great way to understand a topic is to question our preconceived notions. Here are a few myths about onboarding that we need to start questioning.
Onboarding is just a one time thing. It could be when you are trying to introduce new features, or updating a new user interface.
One onboarding is sufficient. Sometimes different roles (users) use different and non-overlapping features of a product. For example, Payroll manager and hiring manager use different modules of a single HR product.
Onboarding is confined to the product. Product onboarding could be complemented by a bunch of onboarding mailers, backed up by online user guides, and even getting started webinars.
Onboarding is only for new users. Well, this is a corollary to the first point. If it’s not a one time thing, then, it’s not for just new users. :)
Four myths of user onboarding in enterprise application
The types of enterprise users
As we discussed earlier, in general, there are two types of enterprise users .
Admins — The one (or ones) who is responsible for administrative tasks such as configuring the application for the organization, setting up workflows, adding users, giving them proper access permissions, scheduling reports, etc.
Daily users — The one (or ones) who uses the product on daily basis. They are the reason the product exists in the first place. It’s their lives the product is trying to improve. But as mentioned earlier, depending on the product there could be different types of daily users too. A part of the product could be abstracted for a certain set of users.
If you notice, there is an overlap between admins and daily users. That’s because admin users can also be daily users and vice versa. Also, number of admins is far fewer compared the number of daily users.
Example: Consider customer support tool.
Admin users — Could be customer support managers, Regional managers (with complete rights over a particular region), VP customer support, etc.
Daily users — Customers, who report an issue or request a service. Agents, who are looking to solve the problem at the quickest possible time. The product itself looks different for both. It looks pretty lean for the customer, but pretty expansive for technician.
Types of user onboarding
As we saw earlier, onboarding depends on the type of user and the purpose. It could be for product onboarding or feature onboarding. For example, when something new is introduced in the product, it could either be behavior aspects (UX/UI) or functional aspects (features or significant enhancements).
Depending on the product usage, one can also do a targeted onboarding for certain unused or under utilized features that could add value to the user.
If you are wondering why there are no daily users in trial users, there is a reason for that. Most free trials, by default, are offered for the admin role in the highest plan. That way anyone evaluating the product can see the full breadth of functionalities that the product offers. Since, admin users will any way have access to daily user’s functionalities, a separate onboarding is not required.
Onboarding enterprise trial users
The trial users are evaluating the product to see if:
The product can do what the current system can do but, in a better way.
The product solves the problems they have with the current system in place (even if the system means there is no existing tool)
The product sits well within the organization in terms of their privacy, security policies, integrations with other processes etc.
Ultimately, will it be worth the price they need pay
Does it remind you of a sales consultation call? Well, if it does then you are in the right track. Because, for all it’s worth, your product is the sales person here and needs to do a convincing job. That means, get everything that stands in the way of demonstrating value of the product(in product management lingo: ‘aha’ moment) needs to get out of the way.
The catch here? Trial is offered with admin privileges. So, can’t really do away with the setup. The best we can do? Keep the setup steps to minimal.
Onboarding enterprise customers
“Yes! We just bagged the another big deal for this quarter!” You hear a sales guy scream.
Well, it’s probably a long way for a customer from product purchase to day 1.
Customer either has purchased the solution(for the problem he has) for the first time, or has replaced an existing solution with a new one.
It’s most likely the latter. That means, they might want to migrate their old data into the new product. So, it’s also important to have import as a part of onboarding process.
This, of course, is in addition to, application set up, user addition, process creation, etc.
Once the product is setup, it needs to be tested to see if things are in line. For example, check if a person who shouldn’t be notified receives any mail, if the right person has the right access to sensitive information in the product, etc.
Now, it’s time to onboard the whole team, depending on the complexity of the product, it could take a few hours to several days.
Remember, this is also an onboarding exercise. So far, there are very few tools available for this to happen. But creating a wizard of some sort that will let your customers publish their unique onboarding steps to their team and end users will definitely help with product adoption.
After that, its Day 1! Uff, finally!
Side note: This whole process of implementing a new product (or solution) comes under change management and is a separate discipline to study. You see, everything in enterprise needs accountability and traceability for audits.
This arduous ordeal can be made a lot easier, if there is a strong onboarding process is in place.
User onboarding in enterprise application
Often, as product managers, when we talk about onboarding process, we only think about in-app onboarding. It could be because we spend too much time with the product. But in-app onboarding doesn’t really give a holistic experience.
Consider a sample user onboarding flow..
Looks familiar? Well, if you do observe keenly, apart from the product, the user employ various channels to explore more about the product.
Most of what’s shown above is self-explanatory. And if you recall, one of the myths we discussed earlier, onboarding applies to both product and feature onboarding.
So, let’s jump quickly into a few case studies to actually demonstrate how applications have used one or more methods shown above to onboard their users.
Hope you now have a better idea about user onboarding in enterprise application than you did before. If you found it valuable, please do spread the word around!
Enterprise onboarding case studies
Microsoft Teams, a communication tool, uses checklists and progress bars to roll out Teams to the whole organization.
2. IBM MaaS360, a unified endpoint management software, prepares a new user by providing a list of required actions. While it looks simple, it does the job. And most importantly, they provide an option to skip and come back later.
Once you skip, you see the below image. It’s a massive product, providing pointers at various elements, helps bring familiarity.
3. Atlassian Statuspage, a communication tool for incidents, highlights one feature at a time along with an action item instead of overwhelming the user with massive product. This helps user focus on the task at hand and increases the chances of them completing the setup on their own.
4. Atlassian Jira Service Desk, a service desk tool, uses demo project coupled with a very good UX writing to showcase the features in the product.
5. Pipedrive, a CRM and sales pipeline tool, usesmultiple elements such as multimedia popups with information about online tutorials and support channels and, chatbot that could interact with the user to understand what they seek and direct them accordingly.
This chatbot also doubles up as a lead qualification for the vendor’s sales/marketing team. There is always something for everyone in onboarding. ;)
6. Airtable, a spreadsheet that gives you the power of databases, uses the most typical onboarding which is not intrusive, but also guides users through various features of the product.
7. Atlassian Confluence, a knowledge base collaboration tool, has various templates listed so that the user can quickly create a knowledge base solution and see the value of the product in no time.
You would’ve seen something similar in Notion as well.
8. Zoho CRM, a CRM application, gives an option to load sample data, so that instead of starting with a blank application and adding contacts manually, one can start exploring advanced features without any delay.
9. Microsoft Azure, a cloud computing service, uses structured learning path to educate users. Given the complexity of the product, it has various filters to target specific roles and products as well.
10. Zenefits, a HRMS solution, has designed it’s online help center for different types of users namely, administrators and employees.
These are just a few examples to illustrate that onboarding is a basket of things. Mix and match various methods to see what works best for your product. I haven’t included on-boarding emails because it’s a rabbit hole in itself. But you get the idea. Don’t you?
Sign up now, to receive such posts on building enterprise products.