Start with the request, not the upload folder
A shared folder gives people somewhere to put files. It does not necessarily tell them which files belong there, whether a document is complete, or who will check it. Before inviting anyone, write a short list of the decisions you need to make with the material. Then turn each decision into a specific request.
For example, “send the project documents” leaves the recipient to guess. “Upload the approved floor plan for the kitchen revision, as a PDF, showing the revision date” describes one action and one useful result. This is an illustrative project request, not a requirement for every industry.
Give every item enough context
Use a consistent set of fields: a recognizable document name, the person responsible, the relevant period or project stage, the expected format, a due date where appropriate, and a short explanation. If an example would remove ambiguity, include one that contains no confidential customer information.
State whether multiple files are acceptable. A person may have three separate monthly statements where you expected one combined file. Let them know whether to upload the three originals or prepare a single document. Avoid requiring unnecessary transformations that make a straightforward submission harder.
Make responsibility visible
When several people are involved, assign an owner to each request instead of addressing the entire group. A named owner can tell you that a document belongs with someone else; an unassigned request can remain unanswered because everyone assumes another person is handling it.
Your opening message should explain the scope, the deadline and the next step. Keep credentials and access instructions clear. If each person has an individual invitation, send that invitation to its intended recipient rather than placing everyone’s links in a shared message.
Separate arrival from acceptance
An uploaded file has arrived. That does not establish that it is the requested document. Keep a review stage in which you check the period, legibility and whether the required pages are included. Use different labels for missing, received and accepted material.
When something needs correction, describe the correction next to that item. “Please replace this with the March statement; the current file is February” gives the client a concrete next action. Keep the earlier version available where your workflow requires a history, and make the current version unambiguous.
Close the request deliberately
At the end, confirm which items have been accepted and which remain outstanding. Save a dated summary if you need a project record. Decide how long the files should remain accessible under your organization’s actual policies; do not leave access open merely because the project has ended.
Team Deliveries implements this pattern with assigned checklists, individual browser invitations and a review step. Its current public listing also describes CSV request imports with a preview and retained file versions. These features support the workflow, but the clarity of the request still depends on what you write.
A checklist to use
- One clearly named document per request
- Named participant or responsible person
- Relevant period or project stage
- Format, example and deadline where useful
- Separate submission and acceptance states
- A concrete correction message and clear final version
Product references
This guide contains general workflow suggestions. Product-specific details refer to the official sources below, reviewed September 17, 2026.