A client dependency is any input, file, approval, access item, or decision the client must provide before the workflow can continue cleanly.

This term matters because solo operators often describe work as “blocked” without naming what exactly is missing from the client side. Once that dependency stays vague, follow-up weakens and timelines become optimistic fiction.

What this page is for

Use this page to clarify what counts as a client dependency and to name the missing client-side item more precisely.

What this term does not cover

Do not use this page as the main answer to stalled onboarding, delayed delivery, or blocked offboarding. It explains one term inside those broader problems.

Start here first if…

  • the whole stage is weak rather than one dependency,
  • you need the actual response pattern rather than the definition,
  • the work is already blocked badly enough that waiting is no longer neutral.

In those cases, go first to Client Onboarding Workflow for Freelancers and Consultants, Milestone Delivery Workflow for Solo Service Businesses, FAQ: What Should I Do When Required Client Inputs Are Late or Incomplete?, or Escalation and Pause-State Worksheet for Solo Operators.

Why it matters

When client dependencies are not explicit:

  • kickoff starts without required access,
  • milestones stall without visible reason,
  • invoices or closeout get delayed behind unspoken approval needs,
  • updates sound reactive because the true blocker was never named.

The fix is not better wording alone. The fix is to record the missing input as a real dependency with an owner, due point, and consequence.

If the term is clear but the actual dependency record is still weak, use Client Input Dependency Worksheet for Solo Operators to document the item more precisely.

If the dependency is already defined and the real question is what operating state comes next because the work is still blocked, continue to Escalation and Pause-State Worksheet for Solo Operators.

What usually counts as a client dependency

  • access to tools, files, or accounts,
  • decision on scope, priority, or approval,
  • content, assets, or source material,
  • stakeholder availability,
  • procurement or finance action tied to progress.

If the work cannot move forward without it, it is a dependency.

Practical test

You have identified the dependency clearly only if you can say:

  • what is missing,
  • who at the client side owns it,
  • what it blocks,
  • what happens if it does not arrive on time.

If you are still writing “waiting on client” with no more detail, the dependency is not documented well enough.

Common failure pattern

The operator keeps working around the missing dependency until the milestone gets fuzzy.

That usually creates:

  • unclear revised timelines,
  • weak client communication,
  • hidden rework,
  • billing or signoff delays later in the project.

Naming the dependency early protects later stages.

Where this matters most on the site

If you already understand the term, do not stay in the glossary layer longer than needed.