Risks › Vague deliverables

Vague deliverables.
The root of every other risk.

"A website." "The branding." "Marketing materials." Every other risk in this library starts here — where the contract doesn't say what's actually being made.

Draft an agreement that prevents it

Free. No registration. No card. No catch.

What it means

In plain English.

A deliverable is what you're handing over at the end of the engagement. It needs to be specific enough that both parties can independently verify whether it's been delivered. If two people can read the same description and picture different things, the deliverable is too vague.

What it looks like

"A logo" — but one party imagined three concepts, the other imagined one final file. "A marketing strategy" — but one party wanted a deck, the other expected a 30-page report with implementation timelines.

Why it's so common

Specificity takes time, and both parties often want to move fast. The client assumes it includes everything they're imagining. The provider assumes it matches what they're quoting. Those imaginations rarely match.

Why it's the root cause

Scope creep, unlimited revisions, payment disputes, approval delays — all of them become easier to prevent once deliverables are defined concretely. The deliverable definition is the contract's foundation.

Why it's missed

Writing specifics feels like limiting the relationship. It isn't.

Why missed

Specifics feel like distrust

Writing down exactly what you will and won't deliver feels like you're preparing for a fight. In reality, it's the thing that prevents one.

Why missed

The scope is still evolving

Many projects start before the full scope is known. The contract gets signed with placeholders. Those placeholders never get filled in.

Why missed

Industry norms assumed

"They know what a brand kit includes." "Everyone knows a full website has X pages." Industry assumptions don't survive disputes. Write them in.

What can go wrong

The downstream consequences.

Infinite scope

Without a concrete deliverable, the client can always say "this isn't what I meant." The project has no finish line.

Payment blocked

If the client can argue the deliverable isn't complete, they can withhold payment indefinitely. Vague deliverables give them the tool to do it.

Scope creep guaranteed

When the contract doesn't define what's included, anything the client asks for is, by implication, part of the deal.

No revision limit enforcement

You can't enforce a revision cap if the original deliverable isn't defined. Every revision is technically a new interpretation of an undefined spec.

Red-flag wording

These phrases describe categories, not deliverables.

A deliverable needs to be verifiable. These phrases describe types of work, not the specific output being produced.

Red flag

"a website"

How many pages? What functionality? CMS? E-commerce? Mobile-optimized? "A website" describes an entire industry, not a project.

Red flag

"marketing materials"

Print? Digital? How many? What dimensions? What formats? "Materials" is a category, not a spec.

Red flag

"the branding"

Logo only? Brand guide? Color palette? Typography? Iconography? Social assets? "Branding" is whatever the client imagines it to be.

Red flag

"as discussed"

What was discussed isn't in the contract. What isn't in the contract doesn't exist for purposes of enforcement.

Red flag

"ongoing support"

For how long? How many hours? What's in scope? "Ongoing" is a blank check on your time.

Safer pattern

The deliverable definition that closes the loop.

A good deliverable definition passes the verification test: can both parties independently look at what was delivered and agree it matches what the contract describes? If yes, it's specific enough. If there's room for interpretation, tighten it.

BizDraft prompts you to define deliverables concretely and builds the scope-of-work section from your inputs — preventing the "as discussed" placeholder from ever making it in.

The pattern

Name the output precisely. Not "a website" but "a five-page marketing website (Home, About, Services, Blog, Contact) built on WordPress with a contact form, mobile-responsive layout, and stock imagery sourced from [provider]."
Specify formats and file types. "Deliverables will be provided in the following formats: [list]. Source files will / will not be included."
List what's explicitly excluded. "This agreement does not include: blog setup, e-commerce functionality, third-party integrations, custom illustrations, or copywriting."
Define acceptance criteria. "Deliverables will be deemed accepted if Client does not provide written feedback within [N] business days of delivery."

Most affected