Margaret Gamm

OneNote as Evergreen Documentation

Building out a Collaborative Operations Manual in a Special Collections and Archives Unit

Margaret Gamm, formerly of the University of Iowa Libraries, is now section head, US special acquisitions at the Library of Congress, email: mgamm@loc.gov.

© 2025 Margaret Gamm

Operations manuals document standard operating procedures (SOPs) and act as a touchpoint for the regular work of staff. They are intended to make processes more uniform, establish common understandings of how workflows advance, inform staff about what policies apply in any given situation, and more. They also help ensure continuity of practice when staff plan a departure or complement training when new staff join the department for onboarding. When not included in the larger context of a manual, written workflows, project documentation, and policies can easily become lost as procedural and workflow documentation tends to be created in small pieces.

For example, a project team is tasked with solving a problem pertaining to an intradepartmental workflow. Announcements are made to the broader organization regarding the team’s formation. The team spends months carefully crafting a written workflow, with justifications and a nice flowchart. They determine that the work is complete, their final document goes to the university librarian, and the workflow is implemented. An announcement is made, and current staff are trained in how to perform the work. But what happens in two years—when the workflow is still relevant but the staff are gone? How do future staff know where to find the documentation? And who is responsible for maintaining it?

Conception

Around 2022, as the director of special collections and archives at the University of Iowa, I recognized the need for this type of more comprehensive documentation after collaborating with other staff to build out procedural documentation over roughly a ten-year time frame. With substantial department growth had come substantial confusion regarding practices long taken for granted. With more than twenty staff in a department that once housed only ten, it was no longer practical to tell people to just ask their predecessor or a colleague about how a process was done.

I started by searching for templates I could use to create a manual. My typical practice when searching for documentation models is to turn to Google, but it quickly became clear that operations manuals tend to be highly specific to the needs of their users and that most of the examples available online were unsuitable. I began drafting an operations manual in a long-form Word document, enlisting colleagues to assist in locating existing written workflows. I fell back on trial and error, experimenting with different formats beginning in 2024 until I found something that checked all the boxes for our needs in a Microsoft environment: a OneNote guide with controlled access—easy to discover and link to within a department-specific context but with the potential to share out beyond the department.

Design and Planning Phase

In 2023, the University of Iowa renamed its operations manual to policy manual, a more accurate reflection of the document’s contents. I am unaware of any true operations manuals at that level, and most operations information comes through word of mouth. My primary interaction with the policy manual has been in a human resources context, where the order of operations is detailed to a greater extent.

The libraries actively maintain a SharePoint page, which could in a certain light be viewed as an operations manual, but there are no written policies regarding how departments should update information on their respective pages. It has been left to each department how to record critical operations information and workflows, which typically do not interlock across departmental sites. This approach risks onboarding and training inconsistencies across departments, as well as the potential for significant communications difficulties.

Key reasons you may want to create your own unit level operations manual could be any of the following:

• Absence of other systematized operational documentation
• Succession planning
• Onboarding and training streamlining
• Improved ability to standardize processes within your own area
• Improved ability to communicate procedures out to staff in other departments

Although it may not be the reason you create one, I would also argue that the process of creating an operations manual provides opportunities for advocacy and clarity. Inconsistences in practice will become obvious as you record them. The need for improvements in certain areas will crystallize. It also becomes easier to justify the need for written procedures to staff both within and outside of the department when you have a clear reason for doing so.

Determining Your Format

There is a whole industry built around workplace efficiency tools at just about every price point. Most require separate subscriptions and/or logins and, at minimum, have some kind of learning curve. I have no doubt that if I looked long enough, I could find an open-source tool that would have been amazing for my purposes. I could have taught my department staff how to use it and edit it, and it may have been great.

But we have limitations established by central campus IT regarding approved tools and administrative rights to install software. My institution operates in a Microsoft environment, and even without the security barriers of policy, I am typically a proponent of adapting an existing system to meet our needs rather than introducing a new system. For the sake of efficiency, I limited my exploration to Microsoft tools that were built to be flexible or semiflexible for documentation purposes. I investigated the following:

• Structured directories within File Explorer
• Word
• Teams
• SharePoint, both within the existing Libraries SharePoint and as a new SharePoint site
• OneNote

Two of these options had been attempted already.

Structured directories in File Explorer had effectively functioned as an informal operations manual without a ReadMe, but with no active records management system in place, a plethora of outdated documentation in combination with departmental growth broke the system. Without consistent naming standards, this system was almost impossible to maintain.

The Word document version of the operations manual that I started building out in 2022 was technically functional but left much to be desired. On the one hand, permissions were very effectively locked down to anyone who had access to the unit’s local storage where the file was saved. On the other hand, not all users had access to that local storage. Multiple staff members could not simultaneously open it, and versions split twice before the transition to a new system. Once Teams became used more heavily across the organization, cloud-based documents could be tied to a Team rather than local storage; but that still left us with other issues prevalent in Word. Using the manual necessitated what felt like endless scrolling. The table of contents alone was three pages long because many sections were simply links out to other documents to avoid moving too many files around.

Other Microsoft apps did not match the purpose of a technical manual closely enough. I considered Teams, but the point of an operations manual is to make it an integral part of your operations. Sometimes student workers would need access to the manual, and they typically do not use Teams. It would introduce many of the same problems as the File Explorer system used in the past, unless I created an extensive ReadMe that would give us another three-page table of contents. It is not meant for long-form documentation.

I found myself limited to trialing two new tools for the purpose.

I had not built out a new site in SharePoint before, and it had a steeper learning curve than I had expected for learning to format and build out new pages. I am, to put it bluntly, not a talented web editor and I have no intention of becoming one. I built a test version, which looked unnecessarily slick for an operations manual. After spending four hours to nail down the formatting on just two pages, I gave up. The point was to create less work through greater efficiency, not more work through web editing.

Finally, I tried OneNote and within a few minutes I knew it was the right tool for the job.

Why OneNote?

I had previously used OneNote for keeping track of my own meeting notes and projects, the advertised purpose for the product. I had not used it as a collaborative tool except for meeting minutes within working groups; even this was just a side effect of the way that the department team was set up within Teams, as the staff template created a OneNote file with collaborative segments.

OneNote, according to Microsoft’s page on the product, is “a digital note-taking app that provides a single place for keeping all of your notes, research, plans, and information—everything you need to remember and manage in your life at home, at work, or at school.”¹ This description, indicating personal and more ephemeral use, might explain why the product often isn’t used for the purpose of more substantive shared documentation. But the product description also indicates that “notes are easy to organize, print, and share, and you can search and find important information quickly, even if you forget where you’ve originally captured it.” This latter part indicates why OneNote can be exceedingly helpful for shared documentation like an operations manual.

OneNote offers the following:

• Flexible access control even when it’s attached to a team. I was able to make certain sections of the notebook visible to staff members from other departments if our workflows overlapped or I wanted them to review a section to ensure accuracy.
• Collaborative live edit ability. I could work on the collection development section while the lead public services librarian added pages about Aeon.
• Indications of action items with the click of a button, all of which it aggregates into a single window depending upon the interface you’re using. I was able to tag items for later follow-through, like when I needed someone else to add a step to a workflow that I was less familiar with. I could have used customized labels but elected not to; general “to do” tags were sufficient.
• Automatic tracking of additions and changes since the last time you opened the file so that you and other colleagues can review them to ensure accuracy and compatibility. Small dots appear next to modified sections, and the edited portions are labeled with the editor’s initials.
• An adaptable interface. You can use OneNote on your desktop, web app, or website. There is also a mobile version, which we expect our student workers may use more.
• Smooth image integration with text. Adding a photo or flowchart image near a text box does not affect nearby text formatting, unlike in Word. For a section on parking, I could easily paste a small map next to the descriptive text of our parking request procedures.
• Familiar software structures for those used to a Microsoft environment. Task bars look like those in Word, Excel, or other Microsoft products, making it a reasonably intuitive program.

Downsides to OneNote

Unsurprisingly, no system is perfect. Another institution’s needs may show even more flaws than I found with using OneNote at Iowa, but these are the main issues I noted.

• No tagging ability. Although the ability to collaborate on a OneNote file was a strength, it was difficult to flag action items for the attention of specific individuals. You can customize tags for individuals and add check boxes or tasks, but I really wanted to be able to tag people with @Person as you can in many Microsoft products. This would have simplified the creation and editing processes. If it were up to me, this would be the first change I would implement to the software to simplify the creating and editing processes.
• Unusual backup system. One potential failure point for any document is the risk of loss; this is especially true for a shared file in a program that users have varying degrees of familiarity with. Fortunately, OneNote files are automatically backed up on a schedule set by the primary user, going back 60 days. Unfortunately, those backups are saved section by section; if the notebook is somehow lost, it would have to be reconstructed. On the other hand, loss feels more unlikely when every member of the team has a version of the notebook saved in their backups. I have been lucky enough to avoid loss thus far, and I hope that continues.
• Difficult to print. It is unintuitive to print a OneNote notebook depending upon your system. Windows 10 allows you to print a full notebook. Windows 11 allows you to print only a page at a time, justifying the elimination of this previous feature by saying, “You never need to print anything because all your notes are easily searchable and available on all your devices.”² Although true, it would be nice to have the option. What you can do is export the file into a PDF, then print that. This may or may not be an intelligible document depending upon the organizational structure you used. But on the other hand, there is no system quite like OneNote; it makes sense that a printed document would lack the structure of the original.

Lessons Learned

In the process of creating the manual in OneNote, I learned a few lessons that I hope may help the next person who tries.

• Determine an organizational structure for your manual that will be easy to maintain. Adapting your layout to your organizational hierarchy or structure may make it easier for staff collaboration so that each staff member knows what to work on without the need for micromanagement. Alternatively, adapt your existing folder structure from shared department files, or if your library already has an operations manual, copy the structure if that makes sense for your facility.
• Come up with best practices to abide by if you elect to do the creating and editing work collaboratively. Having shared understandings will save time and hassle.
• Codify your sections from the start and keep headers as short as possible for both display purposes and navigability.
• Plan for it to be a living document. Unless legacy practices still affect operations, they do not belong in an active guide. If you want to preserve past practices, save a legacy copy of the manual in PDF form rather than leaving it in the working document to avoid confusion.
• Consider access restrictions. Do you want students to have access to the manual? Are there documents that should be kept confidential to staff or to certain staff? With OneNote, you can password protect sections if you want. You can also link out to documents in directories that only certain staff have access to. Just make sure that those documents remain accessible to your IT staff so that if staff depart, someone can still get to them.
• Use job titles instead of names for more evergreen documentation.

Conclusion

Operations manuals are an underappreciated tool to enable methodical approaches to our work. They are well worth the time invested to ensure shared understandings of processes, procedures, and policies that staff are expected to adhere to. They can serve as effective one-stop shops for new hires when done correctly. If created in a tool like OneNote that provides easy collaboration tools, access control, image integration, and automatic change-tracking, operations manuals can be even easier to create and manage over time, making the work put in well worth a team’s time.

Notes

1. “Introducing OneNote,” accessed January 17, 2025, https://support.microsoft.com/en-us/office/introducing-onenote-38be036d-5b5a-49ad-83be-292fe53ad7b3.
2. “Print a Page of Your Notes in OneNote for Windows,” accessed February 24, 2025, https://support.microsoft.com/en-us/office/print-a-page-of-your-notes-in-onenote-for-windows-13d89012-601c-4fac-84e4-b5ea92d39629.