How to Write a Consulting Statement of Work: Scope and Acceptance

A consulting statement of work is where the airy parts of a proposal become operational. It translates "help us evaluate options" into work packages, deliverables, acceptance criteria and a change route. Without that structure, consulting teams end up debating whether an extra interview, another model or a second workshop was always implied.

This walkthrough uses a fictional scenario: a consulting firm will perform a six-week customer-retention diagnostic for a B2B software company. The client wants to understand why renewals are slipping in one segment. The consultant will interview customers and staff, analyze existing renewal records and deliver a recommendations report. The SOW does not include implementation, CRM configuration or legal advice.

Step 1: Set scope boundaries before listing tasks

Open with the purpose, then draw the line around the work. Scope boundaries should be specific to the tempting adjacent work.

Draft language

This Statement of Work covers a customer-retention diagnostic for [Client]'s [segment name] customers. Consultant will identify likely drivers of renewal risk and recommend management actions based on the evidence gathered during the diagnostic.

The SOW excludes implementation management, CRM configuration, compensation-plan design, customer contract negotiation and legal advice. Those items require a separate written scope.

Approval check: Ask the sponsor which adjacent requests are most likely. If they are predictable, name them as exclusions.

For U.S. federal schedule orders, FAR 8.405-2 says statements of work include the work to be performed, location, period of performance, deliverable schedule, performance standards and special requirements when applicable (Acquisition.GOV, FAR 8.405-2). Even in private consulting, that list is a strong scope test.

Step 2: Break the work into packages

Work packages make the SOW easier to price, review and change. Each package should have a purpose, activities, deliverables and client inputs.

Draft language

Work package 1: Discovery setup. Consultant will confirm interview groups, review the records listed in Appendix A and prepare a discovery plan. Client will provide renewal records, customer segment definitions and a sponsor-approved interview list by [date].

Work package 2: Interviews and evidence review. Consultant will conduct up to [number] interviews and review the supplied records for patterns relevant to renewal risk. Consultant will not independently verify the accuracy of source records unless a separate scope is agreed.

Work package 3: Findings and recommendations. Consultant will prepare a recommendations report and facilitate one review session with the sponsor group.

Approval check: If a work package has no deliverable or decision point, ask whether it belongs in the SOW or only in the project plan.

The Oregon Department of Transportation SOW guide recommends defining deliverables by task and discussing tasks, deliverables and schedule before execution (ODOT SOW Writing Guide). That advice was written for ODOT procurement, but the drafting habit is useful for consulting: every task should make review easier, not just describe effort.

Step 3: Write deliverables as reviewable outputs

Deliverables should be tangible enough that both parties know what has been submitted.

Draft language

Approval check: Remove vague deliverables such as "strategic support" unless they are paired with a concrete output.

Acceptance should not mean "the client likes the conclusion." For advisory work, it is fairer to tie acceptance to the agreed output and correction of factual issues.

Draft language

A deliverable is accepted when it matches the format and scope in this SOW and the reviewer confirms acceptance in writing. If the reviewer identifies factual errors or missing agreed elements within [number] business days, Consultant will correct them and resubmit. Disagreement with a professional recommendation is not, by itself, a failure of acceptance.

Approval check: Counsel should review whether this acceptance mechanism fits the agreement and jurisdiction.

Step 4: State assumptions and dependencies

Assumptions are not filler. They are the conditions under which the schedule and fee make sense.

Draft language

The schedule assumes Client provides the records in Appendix A by [date], confirms interview availability within [number] business days and returns one consolidated set of comments per deliverable. If those assumptions change, Consultant will notify Client of the likely impact on timing, fee or deliverable scope.

Approval check: Convert hidden hopes into written assumptions. If the project depends on access to renewal data, do not bury that in a kickoff email.

The ODOT SOW Writing Conventions document advises either specifying deliverable due dates within each task or listing all deliverables and due dates in a table, rather than duplicating dates in conflicting places (ODOT Statement of Work Writing Conventions). Use one source of truth for due dates in your consulting SOW.

Step 5: Add change control before the first change

Change control should be written before anyone asks for extra work. Keep it simple enough that the team will use it.

Draft language

A change is required before Consultant performs work outside this SOW, including additional interviews, additional data analysis, new stakeholder workshops or implementation support. Each change will state the requested work, reason, fee impact, schedule impact and approval. Consultant will not begin changed work until both parties approve the change in writing.

Approval check: Test the clause against a likely request: "Can we add five more customer interviews?" The answer should be a documented yes, no or later, not an argument.

If optional tasks are likely, define them:

Optional task: up to [number] additional interviews at [fee or rate], available only if approved in writing by [date].

Optional tasks prevent small expansions from feeling informal.

Step 6: Finish with approvals and Word cleanup

The SOW should end with a clean approval route:

This SOW is approved when signed by authorized representatives of both parties. The client sponsor may approve delivery decisions under this SOW but may not approve fee or legal-term changes unless separately authorized.

Before sending the signature version, clean the document. Microsoft Support says Word tracked changes are resolved by accepting or rejecting them (Microsoft Support). Use that review step intentionally so old comments, draft options and internal notes do not travel with the final SOW.

Also check the SOW against the proposal or service agreement it depends on. A common failure mode is that the proposal promises one workshop, the SOW lists two and the fee section still assumes one. Create a short consistency pass:

• The project name and client entity match across documents.
• Deliverable names are identical or intentionally different.
• Dates in the workplan do not conflict with the deliverable table.
• Fee assumptions match the number of interviews, workshops and review rounds.
• The change-control clause points to the same approver named in the agreement.

This pass is mundane, but it catches the errors that clients notice immediately because they affect money, timing and authority.

Start from an editable structure

The consulting statement of work template includes editable Word sections for authorization and boundaries, deliverables and acceptance criteria, responsibilities and dependencies, change control and completion, plus approval prompts. Use it to build the SOW around a real engagement, then align it with the governing service agreement before signature.

Sources: FAR 8.405-2, Acquisition.GOV, Statement of Work Writing Guide, Oregon Department of Transportation, Statement of Work Writing Conventions, Oregon Department of Transportation, Accept tracked changes, Microsoft Support