Client materials: what to check before kickoff

The client has sent a folder: a logo, four documents, several pictures and a message saying, “You can start with this.” Before kickoff, check which task each input enables, who verifies it and what remains before it can be accepted. A full folder does not answer those questions.

This worksheet is for an agency that has already agreed the work. It does not renegotiate the estimate or calculate team availability. It turns receipt of materials into an operational decision. A shared spreadsheet is enough; you do not need to buy a tool.

Request inputs for tasks, not a “complete” folder

Start with the first deliverable and work through its tasks. Building a page requires identified content; choosing a crop requires the original photograph; checking changes requires access to the right environment. If you cannot name the task behind a request, reconsider whether you need that input now.

Atlassian’s kickoff guide recommends aligning purpose, roles and success criteria. This article adds a narrower preliminary check: the inputs needed to execute the first part of the work. It is a proposed editorial method, not a certification standard.

Separate inputs needed to begin from those needed to publish. Publication access may wait if the first phase uses a test environment. Main copy, however, may determine the structure on day one. Record when each task needs its input; do not use the meeting date as an arbitrary deadline for everything.

Define “usable” before receipt

“Send photos” leaves too much open. Write “provide the original hero photograph, check that it supports the agreed crop, and confirm the intended use.” An acceptance criterion should describe a small check that someone else can repeat.

For copy, identify sections, language, version and the person confirming the content. For brand assets, request a usable file and the chosen variant: a screenshot of a logo does not establish that a vector original exists. For access, test the necessary action from the assigned account. Receiving an invitation does not prove that account can do the work.

Google Drive’s documentation distinguishes viewer, commenter and editor permissions. “The link opens” and “I can edit” are therefore separate tests. Do not put passwords in the worksheet or make a link public to fix an individual permission problem. Record an access reference, not a secret.

The client supplies the input; the agency checks its fitness for the task. One person can coordinate several inputs, but “the client” and “us” are not sufficient owners if nobody knows whom to contact.

Hypothetical example: five inputs, two accepted

An agency is preparing a five-section campaign page. All data below is fictional practice material. Days are relative to the planned start, not recommended deadlines.

2 of 5 inputs are accepted: 2 ÷ 5 = 40%. This percentage describes the inventory, not project readiness. Even four accepted inputs would not enable content build if the remaining one were K01. Importance depends on the blocked task, not the count of green rows.

Design may explore a direction using the accepted logo if that exploration does not require final copy or the photograph. Record that limitation. Do not present a layout with placeholders as approved content.

Copy a worksheet that makes the next action visible

Use one row per dependency, keeping the identifier when a new version arrives:

ID / input / dependent task:
Observable acceptance test:
Supplier / reviewer:
Needed before / version received:
Status: pending / received / needs correction / accepted / not needed
Check evidence and date:
Next action / owner / next review:
If late: task that can proceed and task that waits:

“Received” means a submission exists and awaits checking. “Needs correction” must name a specific defect, not a judgment such as “bad material.” “Not needed” requires a reason and decision maker; it must not hide an input nobody can obtain.

When an accepted version changes, check which tasks used the earlier version. Keep the new reference and reopen only affected checks. A change to the agreed deliverable requires a separate scope decision; editing the worksheet does not replace it.

Send a request someone can resolve

For the example: “Content build needs section 5 and version confirmation for K01. The header needs the original K03; the thumbnail received is 320 px. Development will check K04. Please confirm who will supply the two corrections and when; we will then review which tasks can start.”

Do not promise a new date automatically when a file arrives. It still needs checking, along with actual availability. Silence is not acceptance. In an agency, one consolidated request also prevents specialists from asking for different versions.

If internal requests multiply without helping delivery, revisit the order of eliminating, automating and delegating. A longer worksheet is not necessarily better. If the task was never defined, return to the scope in the proposal.

Finish kickoff with a decision for each task: ready to start, waiting on an input, or needing clarification. Name the next reviewer. The useful outcome is that the person starting tomorrow knows what they can use.