SOP naming convention that flags a stale procedure

The short answer

Give every SOP file a name made of four parts, in this order: the tool the procedure runs in, the date someone last checked it, the process it covers, and the owner's initials. For example:

Sort the folder by name and every tool's procedures group together, oldest check first. The ones nobody has looked at this year rise to the top, without anyone opening a file.

One condition makes it worth doing: the date must mean someone opened the procedure, ran it against the live tool, and confirmed it still matches. A date typed in without checking is worse than no date.

Why these four fields

Put in the name the things that go out of date. Leave the things that don't change, like the department, to the folder.

• The tool changes first. A procedure in Klaviyo or Gorgias depends on screens the vendor controls. When the vendor redesigns them, your steps and screenshots are wrong, but your file hasn't changed. With the tool at the front of the name, you can find every affected procedure the week the change ships.
• The date goes stale on its own. Nothing happens to the file, but the claim "last checked" gets a week older every week. It belongs where people will see it.
• The owner changes when people leave, swap roles or hand work to a contractor. Initials in the name only help if that person really still owns the procedure.
• The process name says what the file is. It rarely changes, but you need it to tell files apart.

The same idea applies inside the tools themselves. Klaviyo segments, for example, need their own naming convention.

Why this order

Harvard Medical School's guidance on naming files makes the key point: the computer sorts files by name, character by character, so put the most important information first. And if you want to find files by date, put the date near the front.

That is why the date comes straight after the tool. Sort a folder by name and files group by tool first, then by date within each tool, oldest first. If the date came last, files would sort by process name instead, and the old ones would be scattered through the list.

Write the date year first: 2026-06-18, never 06/18/26. The international date standard, ISO 8601, sets year, month, day in that order because other formats are ambiguous. 01/05/22 could be 5 January or 1 May. Year-first dates also sort into the right order automatically, which is what makes the whole system work.

The pattern, field by field

Separate the four fields with underscores, and use dashes inside a field. That gives gor_2026-06-18_refund-macro-review_AY.

Harvard's guidance adds a few rules worth following. Keep names to about 40 to 50 characters. Use only letters, numbers, dashes and underscores, with no spaces or special characters. Replace long categories with short 2 or 3 letter codes, and write those codes down in a README file kept with the documents, so anyone can decode a name even after a file has been moved or shared.

If your pattern starts growing a fifth and sixth field, stop. Harvard's advice is that a lot of information belongs in a separate spreadsheet, not in the file name.

Should the name carry a version?

Harvard's guidance suggests adding a version number to file names, and for research files that makes sense. For SOPs, keep it out of the name.

The reason is that "v3" in a file name quickly becomes "v3-final-FINAL", and a procedure's history belongs in version history, where you can see exactly what changed. The date in the name is a claim about freshness, not a revision counter, so don't change it just because someone fixed a typo. Change it only when someone has checked the whole procedure.

Renaming a library you already have

Do it in stages over a few weeks, not in one weekend. Write the pattern and your tool codes into a README first, so nobody renames from memory and invents their own version.

1. Start with the files people actually use. Rename only the procedures opened this quarter. The rest can wait, or be archived.
2. Add owners. Work out who really holds each procedure and put their initials in.
3. Add dates honestly. Use the real date it was last checked where you know it. Where you don't, put "unverified" in place of the date rather than typing today's. Typing today's date turns an unknown into a false claim.

Rename the existing file rather than saving a copy under the new name, or you end up with both. And don't repeat in the folder names what is already in the file name. Use folders for what the name leaves out, like department.

Where a file name stops working

A date in a file name is a claim that someone checked the procedure that day. It isn't proof. Someone renaming forty files in one sitting can stamp today's date on all of them and check nothing, and the library will look healthier than it is.

The other failure is quieter. A convention nobody wrote down turns into several competing ones, usually starting with the first new hire who was never told the rule.

The fix is the order of work: open the procedure, run it in the live tool, then update the date. Never the other way round.

This is where ReccordSOP helps. Record yourself doing a task and it becomes a step-by-step SOP with a screenshot of each step. It keeps version history instead of overwriting, and it emails the owner when a published SOP has gone 90 days without a review, so freshness doesn't depend on anyone retyping a date. You own all SOPs, recordings and content you create. What it won't do is run the procedure or watch your Klaviyo and Gorgias settings; someone still has to open the tool and check.

Start this week. Write the pattern and tool codes into a README. Rename the ten SOPs your team opens most, using real check dates or "unverified". Then sort the folder by name and count how many sit at the top of their tool group with a date more than six months old. That count is your audit result. If you want the reminder to chase the team rather than sit in a file name, ReccordSOP's free plan covers 3 SOPs in total, and Team is $19 per user per month, with a 3-user minimum.