Documentation Your Volunteers Will Actually Use

Every AV room I have ever inherited came with documentation that had one thing in common: nobody used it. Thirty pages in a binder, written by the one person who did not need it, findable by no one at 7:45 on a Sunday morning.

I know that binder well. I have written that binder. Early in my career I produced a beautiful, comprehensive manual for a church video system, complete with a table of contents and signal flow diagrams, and I was proud of it right up until the first Sunday I was out of town. The volunteer covering for me called at 7:52 AM. The manual was on the shelf six feet from where he was standing. It never occurred to him to open it, and once I thought about it honestly, I understood why. It was written for a reader who was calm, seated, and had twenty minutes. He was standing, panicking, and had four.

After two decades of building volunteer production teams in churches across Georgia and Alabama, here is what actually works.

Write for the nervous stranger

The test for every document is simple. Could a reasonably smart person who has never been in this room follow it under mild panic? Not your best operator. The person covering for your best operator, the week they are out sick.

That standard changes everything. You stop writing explanations and start writing steps. You stop assuming anyone knows what the words mean. You number things.

Look at the difference in practice. The binder version says: "Ensure the house console is properly configured before enabling the stream feed, verifying that the matrix routing reflects the broadcast preset." The nervous stranger version says: "1. Turn on the sound board (big power switch, back right corner, labeled POWER). 2. Press the button labeled STREAM PRESET. It will light up green. 3. If it lights up red instead, see the red light card taped below this one."

The first version demonstrates that the writer understands the system. The second version lets a stranger operate it. Those are different goals, and almost all documentation fails because it quietly pursues the first one. Writing simply feels like dumbing it down, and nobody wants to dumb down their own expertise. But the reader at 7:45 on Sunday does not need your expertise. They need your steps.

There is a discipline to this that resembles writing for radio. Short sentences. One action per line. The object of every verb named exactly as it is labeled in the room. No pronouns doing heavy lifting, because "then switch it back" is useless when three things were just mentioned. It is harder to write this way than it sounds, which is exactly why so few people do it.

Photos beat prose

A picture of the mixer with three circles drawn on it outperforms four paragraphs describing the mixer. My runbooks are mostly annotated photos: this button, then this one, and if this light is red, here is the picture of what to press.

This is not a style preference. It is about how people read under stress. A panicking volunteer does not read left to right, top to bottom. They scan. Their eyes bounce around the page looking for something that matches what is in front of them. A photograph gives them that match instantly. A paragraph gives them nothing to grab, so they put the page down and start pressing buttons, and now you have two problems.

Making these is cheap now. Take a photo with your phone, drop three arrows and a circle on it, print it. When we rebuilt the runbooks for one church's video system, the entire photo pass took a single afternoon, and support calls on Sunday mornings dropped to nearly nothing within a month. The most effective page in the whole set was a photo of the streaming computer's screen showing exactly what "everything is fine" looks like. Volunteers checked their screen against the picture and relaxed. It turns out half the panicked calls I used to get were not about problems. They were about not knowing what normal looked like.

Label the physical room to match. If the doc says Camera 2, there is a label on that camera that says Camera 2. Cable ends are labeled at both ends, because a cable you can trace is a problem you can solve. This sounds obsessive until the first time a volunteer follows a mystery cable behind the platform on their hands and knees during the second verse of the opening song. The label maker is the cheapest piece of production equipment you will ever buy, and it is not close.

One page per job, posted at the station

Nobody opens a binder during a show. Each position gets one laminated page at the station: startup steps, the three most likely failures, and the fix for each. The full manual can exist somewhere, but the survival card lives where the panic happens.

The constraint of a single page is the point. Fitting a job onto one laminated card forces you to decide what actually matters, and that decision is the real documentation work. Writing thirty pages is easy. Choosing the eight steps and three failures that cover ninety-five percent of Sundays is hard, and it is the part your volunteers will thank you for.

How do you know which three failures make the card? You do not guess. You keep a log. For a season, every time something goes wrong, it gets a one-line entry: date, what happened, what fixed it. After a couple of months the pattern is unmistakable, and it is never what you would have predicted. On one team, my failure log showed that the single most common Sunday problem was a wireless microphone with a dying battery, followed by the presentation computer losing its display output, followed by someone bumping a cable at the amp rack. Not one of those three was in the old manual. All three went on the cards, with photos.

The laminated card also solves the findability problem permanently. Nobody has to remember where the documentation is, because it is bolted to the desk they are sitting at. The best documentation location strategy is to eliminate the concept of a location.

Write the closing doc too

Here is a section most teams skip entirely: shutdown documentation. Everyone writes startup guides, because startup is when the fear is. But half the mysterious problems that greet you on Sunday morning were created by an undocumented shutdown the week before. The board got powered off in the wrong order. A setting got changed for a special event and never changed back. The camera got left in a mode nobody recognizes.

A shutdown card is short and dull: power off in this order, return these three settings to these positions, plug the batteries into the charger, and a photo of what the rack should look like when you walk away. Dull is the goal. Every minute spent on the shutdown card buys back ten minutes of confusion the following week, because the next crew inherits a known starting state instead of an archaeological site.

The Saturday test

Before I trust any runbook, someone who did not write it runs the whole system from it while I sit on my hands. Every place they stall is a bug in the document, not a flaw in the volunteer. Fix the doc, test again.

Sitting on my hands is the hard part, and I mean that literally. The first time I ran this test I lasted about ninety seconds before jumping in to explain, which of course invalidated the whole exercise. The document has to survive without its author standing next to it, because on the Sunday that matters, the author will not be standing next to it. That is the entire scenario we are preparing for.

The stalls you find are humbling and specific. The doc says "press the stream button" and there are two buttons with stream in the name. The doc says the power switch is on the right, and it is on the right if you are facing the back of the rack, which the writer always was and the reader never is. The doc assumes you know the projector takes forty seconds to warm up, so the reader concludes it is broken and starts troubleshooting a working projector. None of these are things the writer could have caught alone. The writer's knowledge fills every gap automatically, which is exactly what makes the writer the least qualified tester in the building.

Run the test once a season, not once ever. Rooms drift. Gear gets swapped, settings evolve, and the documentation quietly falls out of sync with reality. A runbook that is wrong is worse than no runbook, because it burns the volunteer's trust in every other page.

Keep it alive, or watch it die

Documentation has a half-life. The moment it is finished, it starts decaying toward that binder on the shelf, and the only countermeasure is ownership and rhythm.

Make updating the doc part of fixing the problem. On my teams the rule was simple: if something went wrong on Sunday and the card did not cover it, updating the card was part of the fix, done that week while the details were fresh. Not a someday task. Part of the fix. The runbook became a living record of everything the room had ever done to us, which is precisely what makes a runbook valuable.

Date every page. A footer that says "updated January 2026" tells a volunteer they can trust what they are holding, and it tells you at a glance which cards have gone stale. And keep the source files somewhere the whole team can reach, not on the one laptop that leaves the building every week. The documentation about the single point of failure should not itself be a single point of failure.

Documentation is not a formality. It is how a team survives your vacation, and eventually, your departure. Twenty years of volunteer teams taught me that the goal was never to make myself essential on Sunday morning. The goal was the opposite. The best compliment my documentation ever received was a Sunday I heard about after the fact: something broke, a first-year volunteer followed the card, the service never noticed, and nobody called me at all. Write it like you love the people who come after you, because that is exactly what it is for.