Treat missing client inputs as a named dependency, not as background frustration.

This page is for the narrow question of what to do when required assets, access, approvals, or source material do not arrive on time. It does not replace the broader onboarding or delivery workflows. It exists to help you respond cleanly once the dependency is already slowing real work.

When this answer is too narrow

Do not use this FAQ to define the whole onboarding stage, redesign delivery control, or replace the broader dependency and escalation rules.

Start upstream first if…

  • the stage itself is still poorly designed,
  • the dependency record does not exist yet,
  • the work is already far enough off track that a pause or reset decision is needed.

In those cases, go first to Client Onboarding Workflow for Freelancers and Consultants, Milestone Delivery Workflow for Solo Service Businesses, Client Input Dependency Worksheet for Solo Operators, or Escalation and Pause-State Worksheet for Solo Operators.

What should you do first?

Document three things immediately:

  • what exact input is missing,
  • who on the client side owns it,
  • what it is blocking.

If you cannot name those clearly, you do not yet have a useful record of the Client Dependency.

If the dependency keeps recurring because the input was never documented tightly enough, define it first with Client Input Dependency Worksheet for Solo Operators.

If the dependency is now severe enough that waiting is no longer a neutral choice, use Escalation and Pause-State Worksheet for Solo Operators to define the next operating state explicitly.

If that blocked state has already made the original plan unreliable, move next to Scope Reset and Recovery Worksheet for Solo Operators.

Should you work around it if you can?

Only if the workaround does not hide the true delay.

Temporary workarounds are useful when they protect momentum. They become harmful when they create false confidence, hidden rework, or a timeline that still assumes the missing input was not important.

What if the delay is happening before kickoff?

Treat it as an onboarding readiness issue.

Do not let kickoff pretend to be complete if access, assets, or stakeholder clarity are still missing. Use Client Onboarding Workflow for Freelancers and Consultants to define what must be present before real execution starts.

What if the delay is happening during active work?

Move the milestone into a visible blocked or at-risk state. Do not leave it looking active if progress now depends on client action.

That protects:

  • status accuracy,
  • review timing,
  • billing expectations,
  • later closeout clarity.

For the operating rule, use Milestone Delivery Workflow for Solo Service Businesses.

How should you communicate the delay?

Keep the message specific:

  • name the missing item,
  • name the owner,
  • name the effect on timing or scope,
  • name the next review point.

That works better than writing “waiting on client” because it gives the delay structure and consequence.

When does this become a larger workflow issue?

It becomes larger than a one-off support question when:

  • the same dependency pattern keeps happening at onboarding,
  • work frequently proceeds without required inputs,
  • blocked stages still appear healthy in your system,
  • downstream billing or offboarding gets delayed by upstream vagueness.

At that point, leave the FAQ and fix the broader stage design.

What if the missing input is delaying closeout?

Then this is no longer just an onboarding or delivery issue. It is now part of closeout control.

Use Client Offboarding Workflow for Freelancers and Solo Service Businesses when the missing input is a final signoff item, handoff approval, or last dependency before archive and billing closure.

Where to go next