Skip to content
sorted.solutions•

Case studies

Case study 01 / Operational SOP system

One place for a department to run from.

A maintained operational reference brings a department’s processes, timelines, resources, decisions, and recurring questions into one clear starting point.

System type
Operational reference
Primary use
Departments and projects
Operating model
One maintained source
Staff role
Ownership and upkeep

01 / Overview

A starting point for recurring operational work.

Departments and projects accumulate instructions, working files, decisions, timelines, and recurring questions across multiple locations.

The system organises that context around how the work is performed, so staff can begin with one reference instead of reconstructing the process each time.

One reference, not one storage location

Source files remain in the applications and folders where they belong. The reference explains how the work is organised and connects staff to the information they need.

02 / Previous state

How the information was organised before

Operational information was distributed across email threads, Google Drive folders, individual documents, and staff members’ memories.

Finding an answer often meant searching through several locations or asking someone who already knew where the information was stored. Important context could be difficult to recover when a staff member was absent, a project changed ownership, or a recurring task had not been performed recently.

The information usually existed, but it was not organised around how the department actually worked.

03 / Current state

One maintained operational reference

Each department or project now has one structured operational reference.

  • Department responsibilities and ownership
  • Recurring processes and instructions
  • Timelines, deadlines, and important dates
  • Links to working files and resources
  • Relevant communications and recorded decisions
  • Frequently asked questions
  • Escalation or handover information

Supporting files remain in their appropriate locations. The operational document provides the structure that connects them.

04 / How the system works

Five steps create and sustain the reference.

  1. 01

    Gather

    Identify existing instructions, files, timelines, decisions, and recurring questions.

  2. 02

    Structure

    Organise information around responsibilities and recurring workflows—not storage locations.

  3. 03

    Connect

    Place supporting files, folders, forms, and templates beside the work they support.

  4. 04

    Use

    Start here for recurring work, common questions, onboarding, and handovers.

  5. 05

    Maintain

    Assign an owner who reviews and updates responsibilities, dates, and procedures.

05 / Operational impact

Less time lost reconstructing routine work.

Staff can begin routine work from a maintained reference instead of reconstructing context from scattered inboxes, folders, and individual memory.

  • 01 Less time spent searching through inboxes and folders
  • 02 Fewer repeated questions about routine work
  • 03 Easier onboarding and handovers
  • 04 Better continuity during absence or ownership changes

06 / Tools and boundaries

Technical component

Google Docs
A familiar, searchable, collaborative document that staff can maintain without specialist software or technical support.
Download SOP template

Case study 02 / Recording operations system

A daily recording archive and automated student delivery.

One workflow maintains a daily recording archive. A separate workflow checks the recording source every few hours and emails available recording links and passcodes to students.

System type
Archive and fulfilment
Primary use
Recording operations
Operating model
Two independent workflows
Staff role
Exception handling

01 / Overview

Two workflows use the same recording source.

The archive workflow collects new cloud recordings on a daily schedule and places copies in an organised shared archive.

The separate delivery workflow interprets each absence request, identifies the affected sessions, and checks the cloud recording source every few hours so available links and passcodes can be emailed to the student.

Workflow A / Archive

Cloud recordings → Daily archive

Maintains organised recording availability.

Workflow B / Delivery

Absence request → Cloud retrieval → Student email

Resolves one request into direct recording links and passcodes.

02 / Previous state

Two recording workflows depended on repeated manual handling.

Recording archive

Zoom recordings had to be located, downloaded, and uploaded to Google Drive individually. Because the required bulk-download process was not available through the Zoom interface, staff repeated the same sequence for every recording.

The amount of work increased with the number of classes, and the archive required regular manual attention to remain current.

Absence requests

A single absence request could cover several days and courses, but every affected session had its own recording.

Staff had to interpret the request, identify the relevant sessions, locate each recording, and send the files to the student. One request could therefore create several separate pieces of administrative work.

Both workflows scaled through repeated staff handling. Higher recording volume increased the likelihood of delays, omissions, and inconsistent completion.

03 / Current state

A maintained archive and a separate request workflow.

New recordings enter an organised archive on a daily schedule without someone processing every file individually.

The archive remains available in its designated storage location without routine per-file handling from staff.

One absence request becomes a visible set of recording jobs, one for each affected session.

Every few hours, jobs progress through matching and direct cloud retrieval before an email is sent with the recording link and passcode. Incomplete and failed work remains visible for staff.

Daily archive
Maintained on schedule
One request
Becomes multiple jobs
Job status
Stays visible
Staff
Resolve exceptions

04 / How the system works

Two workflows operate independently from the same source.

Workflow A / Archive

  1. A1

    Check

    Check for new cloud recordings on a daily schedule.

  2. A2

    Download

    Download recordings that have not already been processed.

  3. A3

    Archive

    Upload the recordings to the organised archive.

Workflow B / Delivery

  1. B1

    Request

    Record one absence request covering the relevant dates and courses.

  2. B2

    Resolve

    Identify the sessions affected by the request.

  3. B3

    Create jobs

    Create and process one recording job for each session.

  4. B4

    Retrieve

    Check the cloud recording source every few hours for each available recording.

  5. B5

    Email

    Send the student the recording link and passcode, then update the job’s status.

The workflows do not retrieve from one another. Both use the same cloud recording source for different purposes: the archive workflow copies files into long-term storage, while the delivery workflow retrieves links and passcodes directly from the source. When a required recording is unavailable, its job remains visible for staff.

05 / Operational impact

Routine processing no longer grows one-for-one with recording volume.

The archive and delivery workflows remove two different forms of repetition: handling every recording file individually and manually checking, matching, and emailing recordings for each absence request.

  • 01 Daily archiving no longer requires per-file staff handling
  • 02 One request becomes multiple trackable recording jobs
  • 03 Pending and failed jobs remain visible
  • 04 Higher volume does not require proportional routine effort

06 / Tools and boundaries

Technical components and their roles

Zoom
Provides the original cloud recordings. The delivery workflow retrieves recording links and passcodes directly from Zoom.
Python
Runs the archive workflow that downloads Zoom recordings and uploads them to Google Drive.
Cron
Starts the archive process each day.
Virtual private server
Hosts the Python scripts and runs the archive download and upload jobs independently of a staff computer.
Google Drive
Stores the organised archive; it is not the source used for student delivery.
Airtable
Maintains requests, recording jobs, relationships, and statuses.
n8n
Checks Zoom every few hours, coordinates matching and retrieval, emails recording links and passcodes, and updates job statuses.

End of case studies

These cases explain the operating change first, then identify the tools and human responsibilities that support it.

Back to systems in practice