Company procedures and policies: documents vs pages?

[Tormod Solem Slupphaug]

Hi.

I'm about to move all our company's procedures and policies over to SharePoint, but I'm wondering if I should use a Document Library or Pages. All procedures / policies mostly follow the same main Word-format with a set of headers and body text, perhaps a few images, links etc.

A document libary with Word files is more traditional, but I really like the more modern layout of SharePoint pages, built for web and mobile from the ground up. 

What are the potential pros and cons of choosing one over the other, and is there any good reason why either could be a bad choice?

[#2]

@Tormod Solem Slupphaug 

I am new to SharePoint and i happened to have the same idea as you. I like how on pages you can "link" related policies which in this case would be pages and it would be easy in access and navigation.

Let me know what you did, and what was the outcome :).

[#3]

Hi @isaiasandrade! 
We ended up going for SharePoint Pages, and I haven't regretted it so far.

Pros:

• The usual 2-3 first pages with revision details, etc. are hidden away from the end user, and they're instead immediately brought to the stuff that really matters. Revision history is still available, but it doesn't distract the end user.
• Gone is looking for the latest Word or pdf version. Everyone always see the latest published version and nothing else.
• More modern and consistent look.
• Use of Windows' stock photos is easily available and gives a more welcoming user experience.
• Responsiveness for viewing procedures on mobile.
• Comment field at the bottom. Can be used to comment and tag users when finding stuff that should be updated, is unclear, etc.. We're a small company and we also use the comment field to have a "Read and aknowledged" confirmation on a few of our procedures.
• Easy to share

Cons:

• It's not possible to create additional "Page Libraries" in addition to the standard "Site Pages" library. So, the columns and views you create for your procedures will also be visible for any other pages. You can either put all your procedures within a folder to keep the separate from the Home page, news pages, etc.. Another alternative would be to have an entirely separate Site for your procedures. I'd suggest the latter. That way you can also easily share view access to the entire site or individual procedures with e.g. Auditers, subcontractors, etc..
• It's not possible (or at least a bit cumbersome) to mix different "documents". In a document library, you can upload something as Word, something as pdf, Excel, etc.. The page library is limited to pages only. You can however add URLs, so you could have a Document Library within the Site, and then link to attachments / other files from the library view. I'd try to limit this to an absolute minimum though, as you'll easily loose a little track of what's been updated when if you start crossing pages and files too much.
• No Table of Contents: both a pro and a con, as it kind of puts a limit on how long your procedures can be. This has forced us to split up certain long procedures into smaller ones. This has however been a positive change for us. "If you need a table of contents, your procedure is too long!" :) 

[#4]

You can do either, but think about how your procedures and policies will be used. Do you need to be able to print them for Front Line Workers? Documents are easier. Do you need to easily share them with a regulatory agency? Documents are easier. Do you need to have unique editor permissions for different collections of policies and procedures? This is easier to do in document libraries than pages. Do you want to store policies and procedures locally rather than in a central Policy Center? Use documents and an enterprise content type so that you can build a search experience to create a “policy center experience” no matter where the policies are stored.

If none of these are issues or desired outcomes, pages can work well. They are easier to maintain and if they are long, you can create anchor links to create a table of contents. They are also easier to create connected inline experiences - for example, dynamically showing the policies and forms related to a procedure in context. If you choose pages, you really have to create a central policy and procedure management experience. But, although I have built solutions using both policies and pages and I wish I could consistently use pages, I find that most often, we need to go with the document route because of the way policies and procedures need to be consumed and permissioned and maintained.

[#5 · Accepted solution]

When we're looking at moving our company's procedures and policies over to SharePoint, we're essentially faced with two paths: Document Libraries or Pages. It's not just a choice between two features; it's about picking the tool that matches how we work and what we need from our documents. So, Document Libraries, that's the traditional route. It's what most people are already used to. You get the benefit of offline access, which is great for anyone who needs to take these documents on the go or share them outside our SharePoint environment. Plus, SharePoint's got this solid setup for tracking changes to documents, which can be a lifesaver. The downside? Well, it's not the easiest to sift through on mobile, and updating documents involves a few extra steps.

Then, there's Pages. This is the modern approach. It's built with today's web and mobile use in mind, making information more accessible and engaging. You can easily add videos, links, or images, which could make our policies more interesting to read. Also, finding stuff is generally easier with Pages. The trade-offs? It might take a bit for everyone to get used to this new way of looking at our policies. And if you need to access these offline, it's not as straightforward. So, what's the best path? It really depends on what's more important for us. Do we need that traditional, familiar format that's easy to take offline and share? Or, are we leaning towards something more modern and accessible, even if it means a bit of a learning curve and figuring out a workaround for offline access?

There's no one-size-fits-all answer here. It's about finding the right fit for our team's needs and how we like to work with our content.