A Simple Photo Status Tracking System (No PM Tool)
Four states, one place each photo's status lives, and the math on why memory stops working around session six.
A photographer shooting four sessions a week with a twelve-day average turnaround has roughly seven sessions open at any given moment — four sessions per week times twelve days divided by seven days in a week. Seven is past the point most people can hold in their head without a system, which is exactly where "I'll remember which one that was" quietly stops being true. The fix is not a project management tool. It is photo status tracking reduced to a four-state status — Uploaded, Under Review, In Edit, Delivered — attached to the shoot itself, so the answer to "where is this one" is a fact you read, not a fact you reconstruct.
The arithmetic behind why photo status tracking becomes necessary
Run the numbers for your own week. Sessions in flight is roughly sessions booked per week multiplied by average turnaround in days, divided by seven:
- 4 sessions/week × 12-day turnaround ÷ 7 = 6.9 sessions open at once, rounding to 7.
- 2 weddings/week × 21-day turnaround ÷ 7 = 6 sessions open at once.
- 10 headshot sittings/week × 5-day turnaround ÷ 7 = 7.1 sessions open at once.
Different volumes, different turnaround times, and the number of things-in-flight lands in the same narrow band — somewhere around six to eight. That is not a coincidence; it falls out of the fact that turnaround and booking rate are usually tuned against each other, consciously or not, to keep a studio's workload roughly steady. Book faster than you deliver and the number of open sessions climbs every week until something gives; deliver faster than you book and it falls until capacity sits idle. Most studios land somewhere in the middle without ever doing the arithmetic, which is exactly why the number that arithmetic produces catches people by surprise.
Six to eight is also, for most people, past the size of a list you can hold in your head reliably alongside everything else a working week requires — client calls, a shoot day, invoicing, the next booking. It is not that anyone is bad at their job; short-term working memory for arbitrary items tops out for most people somewhere between four and seven, and a status system exists to move that fact out of someone's head and onto something that does not forget.
Put a cost on the gap. If figuring out a single session's status — opening the folder, checking email, checking whether the client replied — takes three minutes, and you do that for seven sessions once a week, that is 21 minutes a week spent on status archaeology instead of editing. Across a 48-week working year, that is 16.8 hours — two working days spent entirely on figuring out where things are, not moving them forward. That number does not include the cost of getting it wrong: telling a client a gallery is ready when it is one retoucher's note away from actually being ready costs more than three minutes to walk back.
The four states, and what actually moves a photo between them
A status system only works if each state has one clear trigger and one clear owner — a state nobody is responsible for moving is a state that quietly becomes permanent. Four states cover the whole life of a photo from import to handoff:
| State | Set when | Who moves it next |
|---|---|---|
| Uploaded | Raw import is culled and in the gallery, before the client has seen it | Photographer sends the review link |
| Under Review | Client has the link and is marking favorites or leaving notes | Client submits selects or approval |
| In Edit | Selects are approved and retouching is underway | Retoucher exports the final files |
| Delivered | Final files are exported and handed off | Nobody — the state is terminal until a revision reopens it |
Four states, not six or ten. A fifth state for "waiting on the client to reply" is tempting and wrong — it is not a different state, it is Under Review that has been open a while, and the fix is a reminder cadence, not a new column. The same goes for "waiting on the retoucher" inside In Edit: a due date attached to the state answers that question without doubling the number of labels everyone has to remember.
Notice what each trigger has in common: none of them are a person deciding to update a tracker. Each one is an action that was already going to happen — sending a link, a client clicking submit, exporting a file — which is what keeps the status from drifting out of sync with reality. A state that only changes when someone remembers to change it will eventually stop changing; a state that changes as a side effect of the actual work cannot fall behind the work, because it is not a separate record of it.
Where the status should live — and where it quietly rots
A spreadsheet, or folder colors
- Someone has to remember to update the row after every step
- It lives on one person's machine, or one shared drive nobody else checks
- A missed update just looks like a session nobody has touched — there is no way to tell "not started" from "forgot to log it"
- The status and the photos are two different objects that can silently disagree
A status on the gallery itself
- Moves when the action that defines it happens — sending a link, submitting a review, exporting files
- Visible to anyone who opens the gallery, no separate document to find
- Can never point at photos that do not exist, because it is a property of the photos, not a row about them
- One place, so it cannot disagree with itself
The spreadsheet is not a bad tool — it is a bad place for this specific fact. A status column works when someone reliably updates it every time, and the entire reason a status system exists is that updating it every time is exactly what stops happening around session six.
If your current system is filenames like v2_FINAL_final.jpg, that filename is a status column that lost its own table. "Final" is a state, not a name — and a second "final" means the state changed and nobody updated the label that was carrying it.
The state nobody puts on the chart: going backward
Every version of this model that fails in practice fails the same way — it only has arrows going forward. A client who asks for one more crop after Delivered does not create a fifth state; they move a photo back to In Edit. A system that treats Delivered as final and unchangeable forces that request into a side channel — a new email thread, a one-off file sent outside the gallery — which is exactly the kind of untracked handoff a status system exists to remove.
The same is true one step earlier. A gallery marked In Edit is not one atomic thing — it can have nine notes on it, seven closed and two still open, and "In Edit" alone cannot tell you that. Tracking which retouching notes are actually done is the same problem at finer grain: the shoot-level state answers "roughly where is this," and note-level state answers "specifically what is left," and a workflow needs both, not one standing in for the other.
Delivery has the same trap in reverse. "Delivered" answers whether files went out, not which files — knowing which edit is current is a separate question a delivered status does not answer on its own, and conflating the two is how a client ends up looking at round two while the photographer is discussing round three.
Setting this up without buying new software
This does not require a project management platform. It requires one field that lives with the photos and four allowed values in it. If the tool you already use for client galleries has any kind of status, label, or tag field on a shoot, use that — the four states become four labels, and the trigger for each is a habit, not a feature: send the link and set Under Review, get the client's submission and set In Edit, export the final files and set Delivered.
If the tool has nothing like that, a plain convention still beats nothing: a single, consistently placed word at the front of the gallery or folder name — Review, Edit, Delivered — sorts and scans faster than a mental list, precisely because it does not depend on anyone remembering which folder was which. The failure mode to watch for either way is the same one that breaks the spreadsheet: a second place the status could live. The moment there is a status on the gallery and a different status in someone's inbox, the two will eventually disagree, and whichever one gets checked first that day becomes the wrong answer.
Keeping the retoucher's status and the client's status as one fact
The most common place this model breaks is the handoff between Under Review and In Edit: the client's approval lives on the review link, and the retoucher's progress lives on their desktop, and someone has to carry the fact between the two by hand — a message, a spreadsheet update, a "just letting you know" email. A Photoshop panel that reads a project's outstanding notes directly inside the document removes that specific carry: it closes each note as the retoucher addresses it, and its delivery action exports the files, uploads them, and closes the round in the same step — so the status on the client-facing gallery and the status on the retoucher's desktop are the same record, not two records somebody reconciles by messaging.
That does not replace the four states — it just means the transition from In Edit to Delivered happens once, at the point the work actually finishes, instead of happening twice: once in Photoshop and once, later, whenever someone remembers to update the other place that was tracking it.
Frequently asked questions
What's the simplest way to track photo approval status without buying software?
Four states — Uploaded, Under Review, In Edit, Delivered — attached to each gallery or shoot rather than logged separately. The state should change automatically when the action that defines it happens: sending the review link, the client submitting selects, the retoucher exporting final files. If a human has to remember to update a separate document, the system will start missing updates around the point you have six or seven shoots open at once.
Should I track photo status in a spreadsheet?
A spreadsheet works only as long as someone updates it every single time a shoot changes state, and the entire reason tracking becomes a problem is that manual updates stop happening reliably once you have more than a handful of shoots open. A spreadsheet is fine for things that change rarely, like client contact details. For a status that changes multiple times per shoot, put it on the shoot itself instead of in a second document that can drift out of sync with reality.
How many stages should a photo workflow status have?
Four is usually enough: Uploaded, Under Review, In Edit, Delivered. Extra states for things like "waiting on client" or "needs a second pass" are usually a duration within an existing state, not a new state — solve those with a reminder or a deadline rather than adding columns, or the status list grows faster than anyone can keep it consistent.
What happens to the delivered status when a client asks for a change afterward?
The photo moves back to In Edit. Treating Delivered as a one-way, final state forces post-delivery change requests into an untracked side channel — a new email thread or a one-off file — which recreates the exact problem a status system is meant to remove. A workflow that only allows forward moves will always find a workaround for the backward one; better to allow it directly.
Is 'in edit' the same as knowing which retouching notes are done?
No — they answer different questions at different resolutions. A shoot-level status like In Edit tells you roughly where a gallery sits in the pipeline. It does not tell you that seven of nine notes on that gallery are closed and two are still open; that requires tracking status at the level of the individual note, not the whole shoot.