Source: https://asterly.co/resources/blog/document-it-procedures

[Blog](https://asterly.co/resources/blog)

# How Small IT Teams Document Procedures: Text First, Screenshots Where It Counts

4 November 2026

![A numbered procedure checklist card in front of a small server icon card and a terminal style window, on a soft sky blue wash.](https://asterly.co/resources/blog/images/document-it-procedures/featured-hifi.png)

Every small IT team runs on procedures that live in one person's head.

The catch: that person is usually busy, sometimes on leave, and occasionally gone for good.

So how do you document IT processes and procedures without starting a giant wiki project? Write text first. Add screenshots only where the reader has to find something on a screen. Keep one procedure per page, give each one an owner and a "last checked" date.

In this post, we'll go through what to document, how to write it and how to keep it from going stale.

## What Should You Document First?

Not everything. Start with the procedures that hurt when they're missing.

-   **Recurring:** things you do every week or month, like adding a new user.
-   **Rare but scary:** things you do twice a year and always forget, like renewing a certificate.
-   **Interrupt-driven:** things people ask you about constantly, like resetting MFA.

For example, a good starter list for a small team:

1.  Add a new employee to the admin console.
2.  Remove a leaver's access.
3.  Reset a user's MFA.
4.  Add someone to a shared mailbox.
5.  Renew the domain and check DNS records.

A quick way to find the rest: search your own chat history for "can you" and "how do I." The repeats are your backlog (it's mildly embarrassing how obvious the list is).

## Text First: Why?

Why not just screenshot everything?

Because most IT procedures are about decisions and order, not buttons. Text handles that better. It's searchable, quick to update and easy to copy commands from.

For example, "Before removing access, export their mailbox if HR asked for it" is a decision. No screenshot helps there.

Screenshots also go stale fastest. Every UI refresh in an admin console turns your nice images into lies.

## Screenshots Where It Counts

[![Decision diagram: if the step is a decision or an order of steps, write it as text; if the reader must find something on a busy screen, add one cropped screenshot with one highlight.](https://asterly.co/resources/blog/images/document-it-procedures/text-or-screenshot.png)](https://asterly.co/resources/blog/images/document-it-procedures/text-or-screenshot.png)

Text or screenshot? Ask what the reader is doing at that step.

So when do screenshots earn their place?

When the reader has to find something on a busy screen. Admin consoles are full of nested menus, similar-sounding settings and tabs inside tabs.

Rules that keep screenshots useful:

-   **One action per step:** one click or one field, not a whole page of work.
-   **The screen before the action:** show what they'll see right before they click.
-   **One highlight:** a box around the exact thing to click.
-   **Crop out the noise:** nobody needs the whole browser window.

For example, a bad step:

> Go to user settings and turn off sign-in.

A good step:

> 1.  Click **Users** in the left menu.
> 2.  Search for the user and click their name.
> 3.  Click **Block sign-in** and confirm.

Exact labels, in bold, as they appear on screen.

## A Procedure Template That Works

[![Six cards showing the parts of every procedure page: title, when to use it, before you start, steps, check it worked, and owner and date.](https://asterly.co/resources/blog/images/document-it-procedures/procedure-template.png)](https://asterly.co/resources/blog/images/document-it-procedures/procedure-template.png)

The same six parts on every page, so people know where to look.

Every procedure page gets the same parts:

-   **Title:** a task, like "Remove a leaver's access."
-   **When to use it:** one line.
-   **Before you start:** permissions and anything to check first.
-   **Steps:** numbered, one action each, screenshots only where needed.
-   **How to check it worked:** what you should see at the end.
-   **Owner and last checked date:** at the top.

For example, the "how to check it worked" line for a leaver might be: "Their account shows as blocked and their licence is unassigned."

That last part is the one people skip. It's also the one that stops a half-done procedure from looking finished.

## Keeping Procedures From Rotting

How do procedures go wrong over time?

A vendor redesigns the admin console. A menu gets renamed. Your team adds an approval step. The doc still reads fine and is quietly wrong.

A few habits help:

-   **Date every procedure.** "Last checked" means someone followed it and it worked.
-   **One owner per procedure.** Usually whoever does it most.
-   **Redo only what changed.** When a console changes, fix the procedures that touch that screen.
-   **Delete instead of patching.** If half the steps are wrong, write it again from scratch.

For example, once a month, take the five oldest procedures, follow each one exactly and update the date. An hour, tops.

I'll be honest: "I'll write it up later" is the most common lie in IT. Writing it up while you do the task is the only version that actually happens.

## Where to Keep Them

Wherever your team already looks. A wiki, a shared drive or your ticketing tool's knowledge base.

What matters more than the tool:

-   **One place.** Not three.
-   **Searchable titles.** "Reset MFA," not "Authentication procedures v2."
-   **Stable links.** So you can paste them into tickets and chat.

## The Wrap-Up

Good IT documentation isn't a big project. It's a habit: one procedure at a time, written while you do it, checked once in a while.

Text for decisions. Screenshots for finding things. A date so people know what to trust.

Write it once, stop explaining it forever.

_Written by the Asterly team._

[All posts](https://asterly.co/resources/blog)