Client portal file sharing runs in two directions, and they differ

Client portal file sharing sounds like one capability and behaves like two. Sending things to a client is a publishing problem: they need to find it later, possibly years later, possibly after the person who received it has left. Collecting things from a client is a chasing problem: you need to know what has not arrived. Products are usually good at one and adequate at the other, and which one they are good at is rarely stated on the pricing page. Working out which half you need more is the whole decision.

Outbound is a findability problem

When you publish a report, a set of accounts or a finished deliverable, the file is easy and the finding is hard. The client will come looking in eighteen months, from a different device, possibly a different employee. What they need is an obvious, stable place organised the way they think, which is usually by date and by what the thing is, not by your internal project code. Naming and structure do more work here than any feature.

Inbound is a chasing problem

When you need something from the client, the file is again easy and the knowing is hard. What is outstanding, who was asked, when, and did the reminder go. This is why a shared folder is a poor collection tool no matter how good the sharing is: it can show you what arrived and cannot show you what did not. Inbound needs named requests with statuses behind it.

Versions, and the file everybody is arguing about

Both directions eventually produce the same disagreement about which copy is current. The fix is not more folders, it is that the portal shows one current version per thing with the earlier ones behind it, and that the date and who put it there are visible. If your portal lets two files with almost the same name sit side by side at the top level, you have not removed the argument, you have relocated it.

Questions people ask about client portal file sharing

Is a client portal better than a file sharing service?

For pure sending, a file sharing service is often just as good. A portal earns its place when files need to hang off a client record with a status, a history and an owner.

Should clients be able to delete files they uploaded?

Generally no, or only within a short window. Once a document forms part of your record of the work, its disappearance is a problem you will discover at the worst moment.

How do we stop clients emailing files anyway?

Make the portal path shorter than the email path, and reply to emailed files by asking for them in the portal once. Habit follows convenience, not policy.

Sources

Related answers

Start Retainvo ProKeep every client filed