How To Create an Onboarding Case Study | Support Driven Development
At Personio, we take our onboarding experience seriously because we know that starting off a new job right can make all the difference. Especially within Product, Design, and Engineering, having new joiners work on an onboarding case study helps them learn how our platform works from the very beginning. And, if done correctly, it allows them to have their own personalised version of our software.
Today we’ll walk through the impact that an onboarding case study can have and the step-by-step process of how we set one up at Personio.
What is an Onboarding Case Study?
An onboarding case study is basically a bunch of categorised steps and instructions that are designed to teach a new joiner about the company’s platform. Each employee should be able to complete these steps in their own test account, and can only be done correctly if they follow the instructions appropriately. Think of it like more elaborate, connected test cases that every employee has to follow.
Simple Example
- Log into your test account and create a new customer profile for a customer who wants to buy a number of your products from you.
- You must create sample products in your inventory first, and then use the invoicing feature to create and send an invoice to that customer for at least two different products.
- Download the invoice once it is sent and save it as “onboardingInvoice_yourname” to show you have completed this section.
I wish we had had something like this in my previous role, but a few things blocked me from creating it. I thought my main blocker was due to a lack of free capacity, but looking back now, the deeper issue was that I didn’t really know where to start. Our product had grown so much that I struggled to grasp what the target audience was and if it was to be just for Customer Experience and Support team, Product, Dev, or anyone else.
When I started at Personio in early 2021, I was told by my manager that one of my onboarding tasks was to complete a case study — and to say I was intrigued was an understatement!The case study looked exactly like the thing I had been trying to visualise for the past couple of years in my previous role.
I was supplied with my own personal demo account and told that I should block some space in my calendar over the coming weeks to make sure I was able to complete it. The general idea I sensed was that I should have it completed in my first 30 days, but it could take quite a chunk of my schedule to complete.
And I was not wrong! In the end, it took me around 12 hours in total to complete the entire case study, and immediately gave me massive insight into the company, the product, and how it all works.
So, how do we do it in Personio?
How should you do it?
Let’s dive in.
How to Create an Onboarding Case Study
The most difficult step is the first one: where do you start? Conversely, where should you not start?
Where to Start
Areas with the most frequent support issues
I’ve mentioned a few times in past articles that queries raised through Support should be categorised into the particular feature that they are relevant to. This is super important for so many reasons, not the least of which is that you really should know which areas of your platform your Support team is spending the most time answering queries. This can mean that these areas need better UX or clearer documentation. But, for the purposes of this topic, these are the areas you want your staff to know inside and out, so they can better explain them to customers when they have issues.
Going briefly on a tangent to explain the above…
Wherever you raise or track your tickets, make sure you offer a list of all possible features on your app in two separate dropdowns. Many of your features will interact and if the support team has to choose one of two features they may opt for “other,” which isn’t helpful.
For example, if you have a billing page that sends invoices, feature 1 is billing and feature 2 is invoices. This is really useful info to gather and if Support doesn’t have to think about it, they’ll be more likely to tag it correctly.
(On the same topic, if you do have an “other” option, it should have a mandatory text input box so that you can use these inputs to decide if the feature needs its own option on the list moving forward.)
Tangent over.
Areas with the most bugs
This one could be treated similarly to the above: if a feature of your platform has lots of bugs, you can be sure customers will be trying to get around them. In order to do this, your staff should know how the features work so they can offer workarounds and solutions.
Don’t get me wrong — I hate workarounds. They are a waste of everyone’s time and can usually be fixed with a relatively small piece of work on the part of your Dev team. (I’ll be dedicating an entire post to workarounds in the future, so I won’t spend time on explaining why they are so toxic in this post!)
Once you start categorising support tickets, you’ll be able to see which features are the most buggy.
Features with no help articles
If you don’t have help articles on a public page for your customers on a specific feature, you can be sure that they’ll raise support tickets. Your staff will need to know these areas to be able to answer these questions.
Features where you want to write help articles
The onboarding case can actually work as a sounding board for help articles. If you want to document how a new (or old) feature works and supply this information on a public forum, get your team to follow the instructions first. Some of the benefits to doing it this way are as follows:
- It doesn’t have to be perfect! While I am a supporter of all documentation being written well regardless if it’s internal or external, sometimes it’s more important to just get the information to your support staff in a legible format.
- Once it’s reviewed internally, your team — who should know how to use your platform — can suggest changes to the help article so topics won’t be missed in the final iteration.
- It only has to be done in one language first. Your team will likely be doing it in your operating language, so you can revise it and make it final by going through the steps first before it goes to the translators.
- Spot bugs before going public. You should not have public documentation that reproduces bugs. (This one sounds simple but I’ve seen it so often in action.)
Features that are monetised
At the end of the day, you need to sell your product, so it stands to reason that you want your team to know how to use and support the features that are monetised.
Simply talk to your support team
This one is the easiest! Simply sit down with a few of your support team in a workshop, and get them to explain which areas of the platform that they feel like they’re answering the most questions about. They probably also have an idea about which sections are trickiest to debug, or which ones have the need for the most workarounds. These are definitely good places to start.
Where Not to Start
You should not try to cover absolutely everything on your platform from the beginning. If you do this, you might get overwhelmed with documentation and end up giving up before you actually deliver anything.
In a perfect scenario, this is what you might think you need to cover:
- Any and every possible functionality on every page or section of your software
- All customer user flows
- All support user flows (if being completed by support staff)
- Instructions supporting every guide or knowledge base article on your customer support portal
The last point above will only be valid if you actually have a customer support portal/help centre. You definitely should have one — customers shouldn’t have to contact support for simple guides and help articles — but if you don’t, having a product case will show you where your own employees are having difficulties using your software’s functionality. This alone can actually influence you to create some external documentation on certain topics even your own staff struggle with.
Putting it All Together
Now that you know your areas of focus, you can start building your document and creating the case study. Don’t try anything too fancy at the beginning — a simple step-by-step guide in a PowerPoint or Word document is enough. Just make sure all your staff has access and the ability to comment on the document. (Though it’s probably best to restrict editing to the people who will be creating the document, just in case a new joiner changes something they shouldn’t.)
The document should have linked features like in my example at the beginning. This helps it feel natural to the person completing the case study, and feels like the same flow a customer might follow the first time they start using your product. A little bit of imagination would be a benefit here to create the “story,, but this shouldn’t be too much of a problem if you know your product well enough.
Additional Considerations
Here are a bunch of ideas you can use when building, administering, or improving your onboarding case.
Make someone the owner
Initiatives fail when there is no ownership. From the beginning this should not be one person’s job: If one person creates everything and then leaves the company, it will be very difficult to pass ownership to someone else. Ideally the ownership would fall to an Operations or Support team. The team in charge of documentation could own it if necessary.
Put it onto an eLearning portal
We ourselves have only recently moved the case study to the learning platform LearnUpon, so that it can be properly assigned as training to all necessary staff, and we can see who has yet to complete it. Other advantages to having it on an eLearning platform include:
- The ability to categorise features and assign new feature sections to staff who have completed it previously
- The ability to test staff on the case study or have them upload documents/screenshots that show completion of sections
- Having an official location for the case study rather than it sitting in a doc or shared folder
Creating temporary message channels
If you are hiring multiple staff over the course of a month or quarter, you can add all new joiners or new case study participants to a temporary Slack or Teams channel where they can ask the team running the case study questions if they get stuck. They also may raise bugs or issues here too.
Review the completed case studies
Having a peer or manager review process is not strictly necessary, but I do think it’s important. Due to the nature of this case study, it will eat up a good chunk of your employees’ time, and it might be de-prioritised in favour of their normal workload. Until the onboarding case becomes second nature to everyone in the company, you should have peer or manager reviews to make sure new joiners are completing it fully.
In Personio, the case study is recognised across the company as a vital tool for onboarding, and most peers and managers regularly tell their staff to prioritise it above any of their new workload when they start. Giving a timeframe for it to be completed in the first 30 or 60 days is also a good idea.
Decide who will have to complete it
In most scenarios, I would say everyone in your company. Even if an employee’s role has zero or little to do with your product, having a basic product knowledge can never hurt. Your developers that work on a team that covers Feature A might wonder why they are learning about Feature Z — a feature that they currently have zero involvement with — but, you can never be sure that there won’t be opportunities for those features to connect down the line. This might actually be a positive for your company, as your employees might come up with some valuable functionality to connect features you may not have thought of.
Some people tend to think that the higher you go up in a company, the less of this kind of thing you should be partaking in. I would argue that people at a VP in a company are one of the groups who need this the most, as they don’t get that many opportunities to build customer empathy in their normal roles.
Create sample data where needed
Where doing time-consuming or repetitive tasks adds no value for your team, save them time by creating sample data. For example, in sections where they need to create a file for upload or add 100 records manually somewhere, you can provide the file for upload.
You can still make them personalise an upload file by changing one column or editing a couple of values, and this way you can ensure they know what they are doing and that they have completed the step.
As long as you think about all of the above when creating your onboarding case study, you should be able to come up with something that will be useful for your entire workforce.
All in all, we have found that having a new joiner onboarding case has been very valuable for our new joiners. They’re able to get a better handle, and faster, on our product and platform from Day One of their new jobs. And, as a bonus, those same new joiners can help identify areas that often cause confusion among your actual customers. So, give it a try and let us know how it goes!
Do you want to try out our onboarding case study yourself? Then you’re in luck — Personio is hiring for multiple roles within PDE! Head to our careers page today to find the right role for you.
