Let’s face it – nobody reads employee handbooks! When I worked in a corporate world, the only time I referenced an employee handbook was when I needed to inquire about a vacation policy and wanted to know about the official holidays the company observed so I could plan my away-from-the-company time. Most employee handbooks remind me of “War and Peace” novel in terms of its volume. Finding something relevant is a pain in the ass! One thing that I became quite successful at lately with my clients is the conversion of these employee handbooks to SharePoint document library with metadata. This concept might not be novel but surely allows for a better way to organize such documents and most importantly, for end-users to find them. Let me explain the approach and technique behind this so that you can implement the same in your organization and successfully convert an employee handbook to SharePoint (or any other large document or manual for that matter).
The Approach to convert an employee handbook to SharePoint
The idea behind the conversion is that instead of burying information into one big employee handbook or policy manual, you break it apart into multiple documents. For example, you might have an employee handbook with 200 pages and a table of contents (TOC). Such a document might have sections and paragraphs related to vacations, medical insurance, benefits, computer policy, you name it.
The idea is that you split all of these sections into separate documents/files. Then, you load them all into a single document library with metadata. So your metadata would be used to categorize the different chapters and sections (files) and help users find exactly what they are looking for. And of course, since the document library is fully searchable, your users will be able to search and find relevant sections not just by metadata you define, but also by keywords/text search.
Below is an image that represents the proposed solution.
Let’s go ahead and build this together. Let’s pretend we are converting an Employee Handbook.
Step 1: Create a separate document for each of the sections
I suspect you know how to do this. It will help (though not that important) if you name each file what it is. For example, if it is a vacation policy or Resignation guidelines, name them accordingly (i.e., Vacation Policy.pdf and Resignation Guidelines.pdf)
Step 2: Decide on metadata
This is the most challenging step. Most often, you have your employee handbook broken down into various chapters and sections and related to a particular topic. When converting to metadata, you might not necessarily utilize the same chapters and sections. Instead, you might want to ask yourself a question on how your employees may want to find a particular piece of content/information.
For example, here are the suggested metadata properties along with corresponding tags:
- Chapter Name/Category (i.e., Overview, Employment Information, Attendance at Work, Benefits, etc.)
- Chapter/Section Numbers (i.e., Section 1.1, 1.2, etc.) – this is not necessary, but if you need to maintain those – this can be a piece of metadata as well
- Department Owner (i.e., HR, IT, Compliance, Finance, etc.)
- Type (i.e., Policy, Guideline, Process, Form, etc.)
- Target Audience (Full-Time, Part-Time, Contract Employee, Intern Employees, Summer students)
- Effective Date
By the way, when getting ideas for the Employee Handbook Sections and Chapters, I referenced this excellent resource. Check it out.
Step 3: Build your document library with metadata
On a site where you want to build the library (i.e., Human Resources Site), create a new document library called Employee Handbook. Then build all the metadata columns. Here are a few tips for this:
- For most of the drop-down columns above, you can use a Choice Column Type
- For Chapter (Section) Names, I suggest that you use Term Store metadata. This will allow you to create subsections using the Term Store Term Hierarchy feature, as shown below. This will help users find relevant information for either the whole Section or just a subsection.
- For Section Numbers, I also suggest that you use Term Store metadata. This will allow you to create subsection numbers (i.e., 1.1, 1.2, 1.3, 1.3.1). Such an approach will also allow users to filter documents by particular sections (i.e., just 1.2 & 1.3) or by the whole chapter (i.e., Chapter 1 and all the sections underneath)
Step 4: Create different views
While users will be able to filter documents themselves, it might help to create a few special views for them. For example, you can filter by Target Audience = Full-Time.
or Group by Document Type
These ready-to-use views can help users see the relevant documents within a click, without doing any filtering on their own.
You can also train users to utilize the Filter option themselves – with the amount of metadata we have – it is quite robust and useful.
I also recommend using Compact View to save some real estate on the screen.
This is it! We built it together! Mazel Tov! It is time for a drink – Lehaim!
Other types of documents that can benefit from the same approach
I think you will agree with me that the new way of organizing this information is much sleeker, more user-friendly, and easier for everyone. When a particular clause has to be updated in the Employee Handbook or a Quality Manual, you no longer need to revise the whole document, save it as PDF and maintain an accurate Table of Content (TOC). Instead, you can update a single document within the document library above.
Here are other use cases that might benefit from the approach above.
- Employee Handbook
- Policy Manuals
- Work Instruction Manuals
- Quality Manuals
- Any large document with a Table of Contents (TOC)