Statement of work templates describe a project’s deliverables, responsibilities, review criteria and change process. Write outputs that can be checked and identify assumptions, dependencies and exclusions. Keep proposed changes visible so the completed document supports a shared understanding of the approved scope.
Connect the scope to a two-party agreement, organize execution using a task list and record customer requirements in a service order when appropriate. Reference the accepted version across these documents instead of letting a later task note silently expand the scope.
This page now includes two original downloads: Deliverable Based Statement of Work and Recurring Support Statement of Work. Choose the Deliverable Based Statement of Work for a bounded project with observable outputs. Choose the Recurring Support Statement of Work for service windows, included requests, exclusions, and reporting.
The new files appear first with previews and clearly labeled download buttons. The original gallery and its resource examples follow the practical guide; descriptions of the older collection refer to that original gallery. The new PDFs have fillable fields; save a local copy, open it in a compatible PDF viewer, and review the saved result before printing or sharing.
Two new templates to download
Choose the Deliverable Based Statement of Work for a bounded project with observable outputs. Choose the Recurring Support Statement of Work for service windows, included requests, exclusions, and reporting.
Deliverable Based Statement of Work
Specify project outputs, acceptance evidence and connected commercial terms.
Download Deliverable Based Statement of Work (PDF)
Recurring Support Statement of Work
Define ongoing support boundaries, reporting and responsibilities.
Download Recurring Support Statement of Work (PDF)
How to use the new downloads
For a project, state what the reviewer will examine before accepting each deliverable and identify the relevant agreement and payment terms. For recurring support, define which requests and channels are included, what the response target measures, and which client responsibilities affect delivery. Keep changes connected to the approved scope.
A fictional report project might require three named sections and a specified file format before review. A support arrangement instead needs a defined service window and an agreed meaning of response. Avoid using a vague promise such as prompt service for either. The two new downloads are fillable PDFs; they do not add five Word files or replace reviewed contract terms.
Define the project outcome first
Start with the problem or need the project addresses. Describe the intended result without immediately turning it into a list of activities. “Prepare a documented inventory of the specified equipment” states an output; “hold meetings about equipment” states an activity that may or may not produce that output.
Identify the client, provider, project name, and relevant reference. Use the same names and identifiers as the associated proposal or agreement. If several teams are involved, distinguish the contracting parties from the people who coordinate the work.
Explain the boundaries. Which locations, systems, documents, or services are covered? A project involving three named offices should not be described as covering all company sites unless that is intended.
If the SOW responds to a request for proposal, check the requested requirements before drafting. The provider’s proposed scope should explain how the response fits the need, and any exception should be visible. Do not silently substitute a smaller deliverable under a similar title.
Separate activities from deliverables
Activities are things the provider does, such as conducting interviews or reviewing records. Deliverables are the outputs supplied, such as a report, an installed component, or a training session with specified material.
List the deliverables in terms that can be reviewed. “Improve documentation” is difficult to assess. “Provide an updated procedure document for the three listed processes, in the agreed format” is more definite.
Identify the format, quantity, or coverage when relevant. A report may need a particular audience and subject range; a training session may need a duration and participant scope. Include details that change the work rather than adding technical language for appearance.
Use an identifier for each major deliverable. That reference can connect the schedule, acceptance criteria, and payment milestones without repeating long descriptions. Keep the identifiers consistent across the SOW and supporting documents.
A fictional document-review project
Imagine a small organization hiring a provider to review three internal procedure documents. The project’s purpose is to identify unclear instructions and prepare revised drafts for the organization’s approval.
The scope could include reviewing the three named documents, discussing questions with one nominated contact, and preparing one revised draft of each document. It could also include one consolidated revision round after the client reviews the drafts.
Excluded work might include changing the underlying operational policy, implementing software, or training all staff. These exclusions clarify the proposal’s boundaries; they should not contradict a broader promise elsewhere in the agreement.
The client would provide the current documents and nominate a person authorized to resolve questions. The provider would identify uncertainties rather than invent procedures. Delivery timing would depend on receiving the agreed inputs.
This example illustrates a small SOW structure. It does not supply a contract or determine liability, ownership, or regulatory compliance. Those matters need the appropriate terms and review for the actual project.
Describe acceptance in observable terms
Acceptance criteria explain how the client will review the deliverable. They should be specific enough to check and appropriate to the output. “Client is delighted” is not a useful substitute for defined review criteria.
For the fictional document project, criteria might include coverage of the three named documents, use of the agreed format, and incorporation of the agreed factual corrections. The review should not require the provider to create additional procedures that were outside the scope.
Identify who reviews the output, how feedback is communicated, and the expected review period. Explain the process for addressing a deliverable that does not meet the agreed criteria. Do not assume that silence automatically means acceptance unless appropriate reviewed terms establish that process.
Acceptance criteria should agree with the scope and schedule. A criterion that demands an additional output effectively expands the work. Resolve that inconsistency before the SOW is approved.
GSA guidance in its federal purchasing context emphasizes defining scope, quality, timeliness, and deliverables. Those are useful drafting considerations, but a commercial sample does not establish compliance with federal procurement requirements.
Schedule, inputs, and dependencies
Show the work period and major milestones. Use actual dates when appropriate or a clear rule such as a defined number of working days after the agreed inputs are received. Explain what starts the clock.
List important client inputs and responsibilities. Access, source documents, nominated contacts, and review feedback can affect progress. A delivery date that depends on those inputs should not be presented as unconditional.
Identify dependencies between milestones. A provider may need approval of an initial design before producing a final version. If approval is delayed, the parties need a clear way to discuss the effect on the schedule.
A action plan template can help organize implementation tasks after the scope is agreed. The action plan should follow the SOW rather than add new commitments without review.
Avoid promising completion times you cannot support. Allow the schedule to reflect the actual work and review process. A template’s sample duration is not evidence that your project can be completed in the same period.
Pricing and payment references
The SOW may include pricing or refer to a separate commercial document, depending on the arrangement. Make the relationship clear so the reader knows where to find the applicable amount and billing basis.
A quotation template can support the pricing discussion. Check that the quotation covers the same deliverables, exclusions, and assumptions as the SOW. A low price for a limited phase should not appear to cover a much larger scope.
For milestone billing, identify the relevant trigger accurately. Delivery, review, acceptance, and payment due dates are different events. Do not use the same label for each merely because the template has one date column.
A contractor invoice template can help record a later payment request where suitable. The invoice should reference the agreed project and billing stage; it does not establish a new scope that was never authorized.
Tax treatment, retention, payment rights, and dispute provisions depend on the actual arrangement and applicable requirements. Use appropriate reviewed terms instead of treating a generic SOW as a complete answer to those issues.
Changes to the agreed work
A change process should identify how a proposed addition, removal, or revision will be evaluated. The parties need to understand its effect on scope, timing, and price before treating it as an accepted change.
Record the request and the decision through the agreed approval route. A casual comment from someone who is not authorized to approve work may not be a sufficient instruction. Clarify authority and retain the relevant record.
Do not quietly rewrite the SOW after work has started and leave the other party using an older version. Identify the revised version and the changes. Keep the original and approved revisions so the project history remains understandable.
A change log can distinguish requested changes from approved changes. Not every suggestion becomes part of the project. The provider should not assume approval, and the client should not assume that a new task is included at no additional effect.
Related documents and resource choice
A proposal describes the approach or offer for consideration. An SOW describes the defined work in more detail. A contract or other agreement may supply the broader legal and commercial terms. Keep those roles clear even when several elements appear in one document.
The proposal form template can help organize an earlier offer. When moving from proposal to SOW, carry forward the agreed requirements and resolve provisional assumptions rather than copying them as settled facts.
The original external statement-of-work guide remains available as a related resource. Review its relevance and terms independently. The single gallery PDF below is also an external resource, so do not assume that its wording or format suits every project.
If you need a Word document and the available resource is a PDF, confirm whether an editable version exists at the destination. You can prepare your own structured document from the guidance, but do not describe that as an existing downloadable Word file supplied by this gallery.
Final review before approval
Compare the SOW with the proposal, pricing document, and associated agreement. Check names, references, deliverables, exclusions, dates, responsibilities, review criteria, and change procedures for consistency.
Ask someone familiar with the project to identify unclear promises. Replace terms such as “complete support” or “all necessary work” with a defined scope where appropriate. Broad wording can hide different expectations.
Keep useful detail without overwhelming the reader. A short project may need a concise SOW, while a complex project may need schedules or annexes. The measure of quality is whether the parties can understand and review the work, not whether the document looks lengthy.
There Are Statement Of Work Templates Word
Statement of work questions
Is an SOW the same as a task list?
No. A task list identifies actions. An SOW also defines project boundaries, outputs, responsibilities, timing, and review arrangements appropriate to the work.
What formats are the two new downloads?
The two new files are fillable PDFs with different purposes and matching previews. Open them in a compatible PDF viewer, complete the fields and save your copy. They are not DOCX files, and numerical PDF fields do not calculate totals automatically. The original gallery has its own mixed resources and formats.
What makes an acceptance criterion useful?
It describes an observable requirement that matches the agreed deliverable. Identify the reviewer and process rather than relying on a vague promise of satisfaction.
Can the client request extra work during the project?
Yes, but the request should follow the agreed change process. Confirm its effect on scope, timing, and price before treating it as approved.
Should prices appear inside the SOW?
They can, or the SOW can refer to another commercial document. Make the relationship clear and ensure the scope and pricing information agree.
Can a generic SOW replace legal review?
No. Its effect and required terms depend on the project and jurisdiction. Use the appropriate agreement and review process for material commitments.
