Why your clients ghost on feedback (and how to fix it in 60 seconds)

You sent the cut on Tuesday. It's Friday. Your client hasn't opened it. You ping. They apologize and say they'll "get to it this weekend." Monday comes. Still nothing.

The natural assumption is that they're busy or careless. The actual reason is almost always friction. You sent them a Google Drive link, which asks them to log in, which fails because they're on a different Google account, which means they have to forward the link to the right account, which they'll do later, which means never.

The hidden cost of every extra step

• Wrong Google account? They give up.
• Need to download the file first? They give up.
• Have to install Adobe Creative Cloud to comment? They give up.
• Comments require a separate doc? They give up.

Every extra click between "I got the link" and "my feedback is sent" is where reviewers fall off. In Magpiie the one step you cannot skip, creating an account, happens once, when you invite the client at the start of the project. After that every review opens in any browser, on any device, straight to the cut. They click the timeline, type, hit send. That's it.

Ghosting is usually a scheduling problem

There is a second cause hiding behind the first. Review feels like a task that needs a clear desk and thirty uninterrupted minutes, so it gets deferred to a block of time that never arrives. Your client is not avoiding your work. They are waiting for a version of Thursday afternoon that does not exist.

Reviews that work on a phone, in a gap between meetings, break that pattern. Not because the feedback is better in five-minute chunks, but because a review that can start in ten seconds actually starts.

Make the ask smaller than it feels

• Send one cut with one question, not three cuts and an open invitation
• Give a real deadline: "by Thursday" gets answered, "whenever" does not
• Say how long it will take, honestly, and be right about it
• Point at what you actually need judged, so they are not reviewing everything at once

None of this is manipulation. A reviewer with a bounded, specific ask can say yes to it in the moment. A reviewer facing an unbounded one defers, and deferral is what you experience as ghosting.

Count the steps between the link and the note

Ghosting feels like a relationship problem and is almost always a mechanics problem. The useful exercise is to count, honestly, how many actions stand between your client receiving a link and their first comment existing. Most teams guess three. The real number is usually seven or eight once you include the ones nobody counts.

• Open the email, find the link among the rest of the thread.
• Hit a signup or login wall, or worse, a wall for an account they do not have and cannot create on a work laptop.
• Verify an address, set a password, dismiss an onboarding tour.
• Download the file, or wait for a preview that buffers on hotel wifi.
• Watch the cut while trying to remember the timecode of the bit they did not like.
• Work out where comments go, and whether anyone will see them.
• Write prose describing a moment they can no longer locate.

Any one of those is survivable. Together they turn a five-minute task into something that needs a clear desk and half an hour, which is precisely the kind of task that gets deferred to a tomorrow that keeps moving. Nobody tells you the signup was the reason. They just reply on Thursday.

Move the wall to the start of the project

Magpiie does not pretend the account step away. A client who comments is a member of the project, and that means one signup, a deliberate choice that keeps unreleased work private to the people you invited. What you control is when it happens. Invite the client when the project kicks off, while they are still keen, not on the day the cut is due and they have eight minutes between meetings. From then on every review is the cut, the moment, a comment, send. No download, no tutorial. The interface is deliberately sparse because every control you add is a decision someone has to make before they can do the thing you actually want.

Worth being precise about the two ways to share, because they do different jobs. Inviting someone to the project is for the people whose feedback you want: they watch, comment and approve. A public link needs no account and is watch-only, for the wider circulation where people should see the cut but not annotate it; public viewers cannot comment or download. Sending a public link to the person whose notes you need is a common own goal, because a stakeholder who cannot comment will email you their notes instead, and you are back to prose.

Make pointing easier than describing

The second cause of silence is subtler. Your client is holding a feeling, not a timecode. Converting "the intro drags" into "trim 0.6s from the shot at 00:01:23:07" is editorial work, and a bare text box quietly asks a marketing manager to do it for free. Faced with that, plenty of people write nothing rather than write something they suspect is wrong.

So the fix is not training clients to think like editors. It is making pointing cheaper than describing: click the frame and the note pins there. Draw on it if the words are not coming. Categorise it as visual, audio, text, timing or graphics, and mark it Must Fix or Suggestion so priority is explicit rather than inferred from tone.

That last distinction resolves a surprising amount of friction. A great deal of apparent client rudeness is really an absence of volume control: with no way to say "this one is minor", people either over-state everything or say nothing. Giving them a Suggestion option makes their small notes cheap to send.

Chasing without chasing

The third cause is that the reminder falls to you, so it arrives late, sounds apologetic, and gets deferred again. Magpiie sends the nudges instead: reviewers are alerted when a new revision is ready, gentle reminders surface reviews that have gone quiet, and each person sets their own volume, including a digest instead of live pings.

Two smaller things matter more than they should. Reviewers are always pointed at the latest version, which removes a whole category of wasted feedback on a cut you already replaced. And internal team chatter stays hidden from the client view, so nobody hesitates before writing because a stakeholder might read the working-out.

A structure that gets replies

Once the mechanics are fixed, the ask itself does the remaining work. Four habits, in rough order of impact:

• Give a deadline with a reason attached. "By Thursday so we can publish Monday" outperforms "when you get a chance", because the second one is not a request, it is a wish.
• Say how long it will take. Naming a real number, "eight minutes", is what converts an unbounded chore into a task someone can slot between meetings.
• Point at what you actually need judged. A cut sent with "check 1:12 and the ending specifically" gets a faster reply than one sent with "thoughts?".
• Ask one person. Sending to five stakeholders and hoping produces a diffusion of responsibility where everyone assumes someone else is handling it.

"The client is not ignoring you. They opened the link at the wrong moment, hit one step too many, put the phone down, and the moment never came back."

Common questions

Do clients need an account? To comment, yes: they are invited to the project as members and sign up once. That is a deliberate privacy choice, so an unreleased cut is only ever annotated by people you chose. Do it at the start of the project and it never lands at review time. Anyone who only needs to watch can use a public link with no account.

Which plans include public share links? They start on the paid plans. The free tier is a genuine two-person workspace with frame-accurate comments and version stacking, and a client you invite to comment uses one of those two member slots.

What if a client insists on sending notes by email anyway? Some will, and it is not worth fighting. Paste them onto the frames yourself as you read. It takes four minutes and it means the next round starts from the same record everyone else is using.

The silence that is not ghosting

One case is worth separating out, because the fix is the opposite. Sometimes the client is not stalled, they are done: they watched the cut, thought it was fine, and said nothing because approval felt like it needed no announcement. That silence reads identically to avoidance from your side of the inbox, and teams routinely wait days on a cut that was already accepted.

This is why approval has to be an action rather than an absence. A draft carries a visible status, Draft, Editing, In Review, Changes Requested, or Approved, and a reviewer either approves the version or requests changes. Nothing sits in the ambiguous middle where you are guessing whether no news is good news.

The readiness indicator does the same job internally. It shows whether every blocking note is closed, with suggestions listed separately so a minor idea never masquerades as an obstacle. When the chip turns green, the cut is genuinely publishable, and nobody has to open a Slack thread that begins with "are we good on this?"