A client project can be approved and still be unable to begin. Copy is missing. The right files are in another folder. Nobody is sure who can approve the final direction. These are small uncertainties individually, but together they can determine the shape of the entire engagement. The Gather example below connects this question to a specific company in the Interesting Concepts portfolio.
Make readiness concrete
“Send us everything” is a request with no clear finish line. A useful intake process defines the inputs, their purpose, and what counts as ready.
For a website project, that could mean approved page copy, current brand files, image selections, and one named decision-maker. The point is not to create the longest possible checklist. It is to identify the materials without which the next piece of work cannot be completed responsibly.
Received is not the same as ready
Gather’s purpose within Interesting Concepts is to make client readiness easier to see. Suppose a client uploads a logo screenshot, a draft document, and a folder of photographs. The checklist may show three arrivals. The production team may still lack a usable logo file, approved copy, and confirmation that the photographs can be used.
This is why a readiness workflow needs a review step. An item can be missing, received, awaiting clarification, or accepted for the intended use. Calling everything “complete” as soon as a link appears transfers the ambiguity to the person starting the work.
Explain why an input matters
A request becomes easier to answer when its purpose is visible. “Upload images” gives little direction. “Share the photographs approved for the homepage, with any usage restrictions” gives the client a much clearer task.
The same principle applies to questions. Ask for the decision you need to make, rather than collecting background that nobody will use. A focused brief respects the client’s time and helps the delivery team distinguish necessary context from optional detail.
Separate received from ready
A file arriving does not mean it is the right file. A paragraph of copy may still need approval. A link may be inaccessible to the person who needs it.
A thoughtful workflow gives review its own place. The team should be able to say what arrived, what has been checked, and what needs clarification. Gather’s company proposition centers on this space between asking for materials and being ready to use them.
Keep ownership visible
When several people contribute, a vague request can circulate without finding an owner. A clear request names who is expected to respond and who can resolve a question.
This does not require turning an intake process into a complex management system. Often a simple distinction is enough: the person supplying the material may be different from the person approving it. Knowing both prevents the team from mistaking a contribution for a final decision.
Create a calm starting point
A good intake experience should leave both sides with the same picture of the work. What is ready? What remains open? Which missing item genuinely blocks progress, and which can follow later?
That shared picture is more useful than a stream of reminders. It gives the client an achievable next action and the team a sound basis for planning. The work before the work deserves the same design attention as the finished deliverable, because it shapes how the relationship begins.
A better request, in practice
Consider a studio requesting homepage photography. A broad request might read “Please send images.” A more useful one specifies the intended placement, preferred orientation, who approves the selection, and where to note usage limitations. It also gives the client a way to say that suitable images are not yet available.
That last option matters. If a request only permits a file upload, the client may provide a placeholder that the team mistakes for an approved asset. Allowing an honest answer makes the actual state of the project visible. A complete intake process handles missing information as deliberately as received information.
Make dependencies part of the brief
Not every missing item should stop every task. Page structure might proceed before final photographs arrive, while a campaign launch may depend on approved language. Write down the dependency rather than relying on everyone to infer it from a checklist.
A simple readiness review can separate three groups: material required now, material required before release, and material that would improve the result but is optional. This helps the team use the available inputs without quietly turning a provisional decision into a final one.
Close the loop with the client
Once the inputs have been reviewed, send the client a concise account of what is ready and what remains open. Use the same names for items throughout the project. A request called “homepage copy” should not return as “landing content” unless the distinction is explained.
This consistency makes later conversations easier. Instead of rebuilding context from old messages, both sides can refer to the same work. The result is a clearer starting point and a more respectful way to ask for what is still needed.
Define acceptance before asking again
A better request states what is needed and why: editable brand files for production, final page copy with a named approver, or photographs accompanied by permission for the planned use. The level of detail should match the task. An exhaustive form can be as obstructive as an unclear one.
Gather should make it easier to ask the precise remaining question. If the homepage copy is approved but the team biography is missing, ask for the biography. Repeating the entire original request wastes attention and makes the client wonder whether their earlier contribution was reviewed.
