Connect every request to a project task
A commitment makes sense when you can explain which task depends on it and what happens if it is not fulfilled. Asking for access, information or participation without that connection creates work the client may not understand. Start with the first planned deliverables and identify the minimum contribution needed to complete them responsibly and well.
Saying “we need your cooperation” leaves almost everything undefined. It is different from explaining that the commercial proposal must be validated by whoever knows the actual sales conditions. In the second case, the client understands what needs confirming and why the external team cannot decide it alone.
Avoid requesting every possible material at the beginning too. Some will only be needed at a later stage, while others may never be used. A long list does not replace choosing what is essential to move forward with the first stage of the work.
This conversation builds on understanding the client before accepting the project. After diagnosis, turn what you learned into practical conditions for collaboration. The aim is to leave the meeting with requests someone can fulfil, rather than a vague expectation of availability.
To prepare your next step, explore How to grow a service business.
Confirm who can decide and how much time they have
The client should identify someone who can gather information and route decisions, but that does not mean this person can approve everything. Distinguish coordination, technical validation and commercial decisions according to the project. Agree realistic response times and confirm the availability of people needed at moments that could otherwise block the planned delivery.
Someone can be available every day while lacking authority to approve an important change. Someone else may have that authority but only be able to review work on specific dates. The plan should reflect both situations rather than assuming a quick reply resolves every dependency.
Imagine a sales-page project in which marketing validates the presentation but management defines prices and terms. If the copy reaches review without that distinction, repeated changes may arise around decisions nobody had taken responsibility for. In this hypothetical example, the solution starts by allocating decisions before producing the complete version.
An agreement on who approves what during onboarding should also explain how conflicting opinions will be resolved. A delivery team cannot receive contradictory instructions from several people and be expected to guess which one takes precedence.
Make conditions that could prevent results visible
When a project depends on a condition that does not yet exist, explain that dependency before accepting a deadline or promising a result. The client needs to decide whether to address it, reduce scope or postpone the work. Necessary conditions should be demonstrable in the specific context, without turning personal preferences into universal requirements.
A campaign may depend on a usable page, a clear offer and someone available to answer enquiries. That does not mean every company needs to rebuild its entire website before advertising. Show the specific weakness and explain why it limits the proposed work.
There is a difference between saying that a page does not match your taste and showing that visitors cannot understand what they are buying. The first observation may start an aesthetic discussion; the second identifies a commercial difficulty. The more precise the diagnosis, the easier it becomes to justify the commitment requested.
Also acknowledge what you do not yet know. If an initial assessment is needed to confirm the dependency, propose that stage and explain what will be decided afterwards. Requesting commitment to a limited investigation can be more honest than immediately selling complete execution based on weak assumptions.
Define what happens when an answer does not arrive
The collaboration agreement should explain how the team communicates a missing dependency and reviews the affected work. Identify the blocked task, possible impact and available alternatives before changing dates. A lack of response should not be treated as approval, nor should it automatically transfer all responsibility for the project to the client.
If copy validation is missing, other parts of the delivery may still be prepared. If the missing decision determines all subsequent work, continuing may create rework. The team should explain that difference and propose a choice the client can assess with the available information.
A useful message identifies what is missing and its specific consequence. In a hypothetical example, the final page depends on confirmation of commercial terms, while image review can continue. The conversation then moves beyond “client delays” and starts addressing what can actually be executed.
The provider also needs to fulfil its part: make clear requests, allow reasonable response time and give notice when a dependency becomes critical. Collaboration loses credibility when the team demands urgency to compensate for a late request or one that lacked the necessary context.
Request sufficient access and preserve the client's autonomy
Access and materials should enable the agreed work, with understandable responsibilities and a path to continuity after the project. Explain what will be created, where it will remain and how it will be handed over. The client's commitment to collaborate does not require losing control of assets or depending on information only the provider holds.
Organising accounts and files should be treated as part of delivery. The client needs to know where to find what was produced and who maintains each element. When an additional paid tool or service is involved, explain that dependency before it becomes indispensable to the operation.
I support a relationship in which a client's departure does not erase the work they paid to receive. That position translates into straightforward operational decisions: document, organise and prepare the handover of what was contracted. Specific conditions need to be clear from the start, particularly when delivery uses third-party resources.
It is unnecessary to anticipate every possible scenario during the first meeting. It is necessary to avoid surprises about control, continuity and responsibilities. The better that foundation is organised, the easier it becomes to focus later conversations on the project's actual decisions.
Begin with commitments both sides can fulfil
The best initial agreement contains only the commitments needed for the next stage, leaving room to revisit the plan when new information appears. Confirm who does what, which materials are missing and the first joint decision. If an essential condition remains unanswered, adjust the start of the work instead of quietly ignoring it.
When organising the first month of a project, distribute requests according to when they will be used. Clients can prepare their participation better when they see the relationship between information, execution and validation. The team can also distinguish an urgent requirement from something that can wait.
Asking for commitment should make delivery viable. This requires clarity and reciprocity: the client supplies what only they can provide, while the provider takes responsibility for the tasks it sold and explains its proposed decisions. When that division is understood before starting, both sides can assess whether the project is ready to proceed.