Your client should never get a login

The approval you need is a ten-second decision. Look at the post, say yes. So why is there a signup form in front of it?

Count the steps honestly. You send an email. The client clicks a link. The link asks them to create an account. They pick a password, or more likely they do not, and close the tab. Two days later you follow up. They try again, hit a verification email, find it in spam, get in, land on a dashboard they have never seen, and now have to work out where the thing you wanted them to look at actually lives.

Eight steps to say yes to a photo of a rooftop pool.

Every step is a place to lose the week

None of those steps is difficult. That is what makes them easy to defend and easy to underestimate. Each one has maybe a ten percent drop-off, and ten percent eight times over is most of your clients not making it through on the first attempt.

The cost does not show up as a lost client. It shows up as a week of slippage, a Friday spent chasing, and a content calendar that is permanently running a few days behind the plan you sold.

You are not competing with your client’s attention. You are competing with the tab they closed.

“But we need an account for security”

This is the objection, and it deserves a real answer rather than a shrug, because the underlying concern is legitimate. You need to know who approved what. If a client says they never signed off on something, you need a record.

But an account is not the only way to get that record, and it is a strangely heavy way to get it. A scoped, signed link identifies exactly one person on exactly one workspace. It can expire. It can be revoked. It can be tied to an email address you already verified when you invited them. Every action taken through it can be logged with a name, a timestamp and a version.

What you actually need is attribution and version history. Those are properties of the link and the record, not of a password.

What a no-account flow has to get right

It has to work on a phone, properly

Your client is not at a desk. They are reading this between meetings, on a train, on a phone. If reviewing means pinching and zooming a desktop layout, they will postpone it, and postponing is the whole problem. The review experience should be built mobile-first and the approve action should be reachable with a thumb.

The notification has to carry context

“You have 3 items awaiting review” is a request to go and do work. The post itself, in the email, with the caption and the question you are actually asking, is a decision the client can make where they are standing.

Feedback has to land on the thing

The reason clients write vague feedback is that most tools give them nowhere precise to put it. Give them a comment pinned to a point on the image, or to a second in the video, and the vagueness disappears without you having to ask for it. “The third one, I think” is a tooling failure, not a client failure.

It has to look like you

If the link opens something branded by a software company your client has never heard of, you have introduced a third party into a relationship you are being paid to own. Your domain, your logo, your colours, your sending address.

What this looks like in Ovia

Clients never create an account in Ovia. They get a link on your domain, they see the month laid out as a client would want to see it, and they approve, comment, or ask for a change, from a phone, without installing anything.

Every one of those actions is recorded against their name with the version they were looking at, so when someone asks who signed off on this, the answer is one click away. You get the version history. They never get a password.