How to Track Which Retouching Notes Are Actually Done

Retouching notes and the three places 'done' lives

Picture a round with 24 notes on it — a normal load for a mid-size commercial job with three or four images getting heavy work. The retoucher works through the file, and for each note there's a small decision to make twice: is this actually done, and where do I write that down?

Most retouchers keep a personal tracker for this — a spreadsheet, a sticky note on the monitor, a mental list carried between files. Ticking off 24 notes there, even moving fast, is close to 15 seconds each once you count finding the right row and marking it: 24 × 15 seconds = 6 minutes. Then comes the recap that actually goes back to the client, because the review tool's status field either doesn't exist or isn't something the retoucher has access to update directly. Writing a clear, numbered recap for a list that size — not copy-pasting, actually composing sentences a client will read and trust — runs closer to 10 minutes for a round this size.

That's 16 minutes of pure status bookkeeping per round, before a single pixel gets exported. Multiply it out across a normal month: three rounds per shoot, six shoots a month, and it comes to 16 × 3 × 6 = 288 minutes — just under 5 hours spent re-typing the same information into three different places instead of retouching.

None of that accounts for the actual cost, which isn't the clicking — it's what happens when the three lists disagree. A note ticked in the spreadsheet but never mentioned in the recap reads to the client as unaddressed. One mentioned in the recap but never actually ticked anywhere durable gets re-opened next round because nobody can point to where it was marked closed. Both directions cost more time than the 16 minutes did in the first place, because now someone has to reconstruct what actually happened.

Why a separate tracker doesn't fix it

Buying a nicer tracker doesn't close the gap, because the tracker's real weakness was never its interface — it's that status lives somewhere other than the note, and somewhere other than the file being edited. Every context switch between “look at the note,” “make the edit,” and “go record that I made it” is a place a note gets missed, double-counted, or ticked against the wrong frame when a shoot has forty similar-looking product shots.

The same disconnect shows up on the client-facing side of markup, not just the status side. A note pasted into a screenshot layer has the identical problem: the feedback and the file agree with each other for exactly as long as nobody edits either one afterward. Status tracking and markup are really the same failure wearing two different names — information that lives apart from the pixel it describes is information that goes stale the moment the pixel changes.

This is also why adding process rarely helps. A studio that mandates “update the tracker before you close a note” is asking retouchers to do the same re-typing, just with a rule attached. The rule doesn't remove a step; it adds an audit for whether the step happened, and audits only catch drift after a client has already seen the wrong number.

The version-numbering side of a job has the same shape. A studio that names files client_v2_FINAL_notes_done.psd is doing exactly what the spreadsheet does — encoding status in a label that has to be updated by hand, separately from the file it describes, every time something changes. A note's status and a file's version are both metadata about a document, and both drift for the identical reason: the metadata lives somewhere the document itself can't enforce.

What it looks like when the tick lives in the file

Appruva's Photoshop panel — built for Photoshop 2023 (24.0) or newer, on macOS or Windows — puts the notes for the open document directly in a docked panel, numbered to match the badges the art director placed on the frame. Ticking a note off happens right there, next to the layer it applies to, not in a separate window and not from memory an hour later.

Under the project's local-tick setting, those ticks stay private to the retoucher until the round is actually handed back. That matters for the same reason a private “done” column matters in any tracker: a retoucher can mark their own progress mid-file without the client seeing a note flip to resolved before there's an export to back it up.

Deliver runs the studio's export recipe, uploads the result, stacks it as a new version — and this is the part that removes the 10-minute recap from the arithmetic above — closes the ticked notes and posts a delivery note stating what was addressed and what wasn't. The recap gets generated from the same ticks the retoucher already made while working, instead of retyped afterward from memory.

None of this has run at studio scale — it's been exercised end to end on one install, not across a team, and that's a narrower claim on purpose. The honest version isn't “this is how studios work now.” It's that ticking status where the edit happens, instead of in a fourth place, is a solved problem for a Photoshop-based retouching workflow, today, and the arithmetic above is what it removes when it works that way.

Freelance retouchers and the same status problem

The status problem gets sharper the moment a freelancer is in the file, because now the tracker also has to answer a second question: does this person still need access at all. A share link scoped to Retoucher access handles that half — it can be revoked the moment the job ends, instead of leaving a folder invite active for a contractor from three projects back. The local-tick setting handles the other half: a freelancer's in-progress ticks don't reach the client until the round is actually handed back, so partial progress on someone else's file never gets mistaken for a finished one.

That split matters more than it sounds like it should. A studio bringing in a freelancer for overflow work usually has the least visibility into that person's actual progress — which is exactly when a status system that only reports finished rounds, not half-finished ones, earns its keep.

If you don't use a panel: three habits that help anyway

None of this requires a specific tool. The underlying fix is available to anyone retouching client work by hand, panel or no panel:

• Give every note a stable ID that means the same thing in the client's tool and in whatever the retoucher tracks internally — a number, not a description, so “the sky” from three rounds ago doesn't get confused with today's sky on a different frame.
• Tick status in exactly one place, and generate everything downstream from it. The moment a recap gets written from a second, hand-kept list, that second list is where drift starts.
• Batch the recap from the tracker instead of composing it from memory. A recap built by reading a ticked list top to bottom takes a fraction of the time one composed from what the retoucher remembers doing, and it's far less likely to skip something that actually got fixed.

Even without a panel, cutting from three status locations down to two recovers most of the saving. The biggest cost in the arithmetic above was never the raw seconds spent clicking a checkbox — it was the reconciliation work that happens whenever two lists disagree about the same note.

Worth naming the failure mode that habit two is actually defending against: a note ticked as done in the personal tracker, then genuinely forgotten by the time the recap gets written an hour or a day later. That's not carelessness, it's working memory doing what working memory does across twenty-odd small edits on one file. A single source of truth doesn't require better memory from anyone — it just removes the step where memory was ever load-bearing in the first place.

The order matters too. Tackle the stable ID first, because the other two habits assume it. A recap batched from a tracker that uses descriptions instead of numbers still needs to be cross-checked against the client's own note list by eye, which is most of the work the batching was supposed to remove.