Creative feedback is a PROBLEM! How are people handling it?
by•
I run multi-client creative work (video, ad scripts, photography) and feedback always ends up scattered across WhatsApp, email, and Figma comments. Half the time nobody's sure which version actually got approved.
Curious how others handle this, especially freelancers and small agencies juggling several clients at once.
Is your bottleneck getting clear feedback, keeping versions straight, or something else entirely?
161 views
Replies
I think juggling several clients makes this so much harder! @shikharbower
Proofrr
@bradywilfaqn Could not agree more!
Version control probably the biggest issue for me. Feedback is manageable until someone comments on an older file and suddenly nobody knows what's current.
Proofrr
@albert_nelson1 Have you come across any tools to work around this?
@albert_nelson1 @shikharbower the thing that fixed it for us was not a tool. it was making old links say superseded instead of just quietly opening. if v3 still opens fine, someone will always be commenting on v3.
honestlt i think biggest thins is just knowing where the final version is . otherwise someone always ends up working from an old file.
Proofrr
Proofrr
Would love to know from editors and designers specifically!
Feedback scattered across three apps is a nightmare I know well. I started forcing every client into one shared doc, even if they hate it initially. Have you tried setting a single channel rule upfront before the project starts?
Proofrr
@advin_jadis Yes, but clients (as you would know) take time to adapt and are rigorous. so ultimately we get pushed back to Whatsapp or phone calls... which is not ideal.
the one tool answers keep missing what i think is the actual failure. it is not that feedback arrives in three places. it is that approval is not an artifact anywhere, it is a state in somebody's memory.
whatsapp is not the problem, whatsapp is just where the approval happened to land. if the only record that v4 was signed off is a message someone remembers reading, a perfect single tool moves the ambiguity somewhere tidier without removing it.
what worked for us was making approval something that has to be produced rather than inferred. one line, named person, named version, and until that line exists the version is not approved no matter how many people said it looked great. it also ends the argument about which channel it came in on, because the channel stops mattering.
Proofrr
@rabnoor_s Too much effort for such a small problem :(
@shikharbower fair, and probably right for most teams. albert's recap email is the cheap version of the same thing and costs you nothing
Proofrr
@rabnoor_s I've not tried yet, can't find it online too, can you share email?
I think the real bottleneck is accountabiity not the tool itself. Clients approve things casually in chat, then forget later. Now I send a recap email after every round summarizing what was approved and by whom. Takes five minutes but has saved me from disputes more times than I can count.
Proofrr
@albertnelson Clients taking accountability... that'll be the day. hahaha...
I like your approach though.
Softorino 💻📲
Everyone here is on the sending side, so from the approving side: it scatters when the ask is open. Send me a cut and ask what I think, and I answer in whatever app I already have open. Say the only decision is whether the opening shot works, and you get one answer in one place, with nothing to reconcile later.
Proofrr
Softorino 💻📲
@shikharbower I have not used it, so just on timestamps as a mechanism: they fix where in the video, which is the cheap half. They do not tell you which cut is current or who signed off, and those were the two things breaking in your first post. A timestamp also still lets me leave scattered thoughts, it just files them tidily.
Proofrr
@yelyzaveta_kibets I couldn't agree more.
Ariso
The clients are not going to stop texting and email commenting anyway 😂
Might be more effective approach: feedback can come from everywhere, but the official version should be in one single place only.
The failure mode that survives even a good approval record is what the client actually looked at when they gave it. A line naming a version number tells you what was approved in principle, it does not tell you whether the file behind that version number was still the same file by the time someone acted on the approval, because creative files get swapped in place under the same name far more often than code does. What has worked on the ops side for problems shaped like this is treating the artifact as fixed once a decision is recorded against it, any edit after that gets a new identifier even if nothing in the workflow feels like a new version. Cheap to build, and it is the only thing standing when someone is reasonably confused six weeks later about which cut actually went out.