Agency Scope of Work Template: Deliverables, Boundaries and Change Control
Use this agency scope of work template to define deliverables, responsibilities, assumptions, acceptance, exclusions, dependencies and project changes.
On this page +
- Confirm the governing context
- Define deliverables in observable terms
- Copy this agency scope of work template
- Draw boundaries with explicit exclusions
- Assign responsibilities and dependencies
- Build a realistic schedule
- Set review and acceptance rules
- Control changes before work begins
- Use Kuno in scope discussions responsibly
- Approve, baseline and maintain the scope
- FAQ
An agency scope of work template defines what an agency will deliver, what the client must provide and how both sides will handle review and change. Precision reduces avoidable ambiguity, but the document is useful only when authorized people understand and approve it.
This generic template is not legal advice and does not determine whether a document is contractually binding. Adapt it through the organization’s approved commercial process, align it with the governing agreement and ask qualified legal owners to review terms that affect rights, liability or legal obligations.
Confirm the governing context
Identify the client, agency, engagement, effective dates and documents that govern the work. State how the scope relates to a master agreement, proposal, purchase document or policy. If documents conflict, do not invent a priority rule; route the inconsistency to authorized legal and commercial owners.
Summarize the client-supplied business need and approved objective. Avoid turning an output such as “campaign assets” into the objective itself. Link the scope to an accepted project intake form template record where one exists, while keeping the scope specific enough to stand up to operational review.
Name the commercial owner and delivery owner on each side. Their responsibilities may differ from legal signing authority, so record who can clarify day-to-day work and who can approve changes.
Define deliverables in observable terms
For each deliverable, specify format, quantity, channel, language, dimensions or environment where relevant. Describe included activities and the completion evidence. “Brand support” is vague; “one facilitated positioning workshop and one documented messaging framework in the agreed file format” gives reviewers something concrete to assess.
Avoid unnecessary implementation detail that prevents sensible delivery, but include details that affect effort or acceptance. Distinguish drafts, working files and final files. State whether editable source files, licenses, data exports, training or handover materials are included.
Connect each deliverable to an owner, dependency, planned date and acceptance criteria. A schedule without client-input assumptions can imply control the agency does not have.
For recurring services, define the service period, cadence and capacity basis. Clarify whether unused capacity carries forward, whether priorities can change within a period and which work consumes the agreed allowance, but only use rules approved in the commercial agreement. Name the reporting evidence both sides will review.
For creative work, distinguish concepts, revisions, adaptations and production-ready outputs. One concept shown in several mockups is not necessarily several concepts, while adapting an approved design to many formats can create meaningful work. Define terms for the actual engagement so counts do not create false clarity.
Copy this agency scope of work template
AGENCY SCOPE OF WORK
Client / agency / engagement / version:
Governing agreement / effective dates:
Business need / approved objective:
Client commercial owner / agency delivery owner:
DELIVERABLE REGISTER
Deliverable / format / quantity:
Included activities:
Agency owner / client reviewer:
Client inputs and due date:
Delivery milestone:
Acceptance criteria / approver:
BOUNDARIES
In scope:
Explicitly out of scope:
Assumptions:
Dependencies / third parties:
Constraints / approved policies:
GOVERNANCE
Working cadence / reporting:
Review rounds / feedback route:
Acceptance process:
Change request and impact review:
Escalation contacts:
APPROVAL
Open issues / conditions:
Authorized approvers / dates / versions:
Replace placeholders with engagement-specific language. Keep referenced documents versioned and accessible to appropriate reviewers. A generic template should never be treated as authorization to spend, process data, publish material or begin changed work.
Draw boundaries with explicit exclusions
List what is included by phase, audience, market, channel and deliverable. Then identify adjacent work a reasonable client might expect but that is excluded. Common ambiguity areas include research recruitment, copy translation, development, stock assets, production costs, travel, media spend, platform fees, source files and post-launch support.
Explain exclusions neutrally. The purpose is shared planning, not defensive drafting. If an excluded item may become necessary, state the decision point and change route. Do not bury important exclusions in an appendix nobody reviews.
Separate exclusions from client responsibilities. An item can be necessary to delivery but supplied by the client, such as approved brand assets, access credentials or a legal review.
Review boundaries against the full delivery lifecycle: discovery, creation, production, implementation, launch, measurement, maintenance and archive. Scope often becomes ambiguous at the transitions. If the agency creates files but does not publish them, state the handover format and the client role. If post-launch correction is included, distinguish defects from enhancements and set an approved support window.
Address intellectual property, usage rights, licenses and confidentiality only through language approved by qualified legal and commercial owners. Do not assume that paying for a deliverable automatically transfers every source file, third-party asset or right. Operational teams should know where the authoritative terms live without paraphrasing them into a contradictory promise.
Assign responsibilities and dependencies
Name one accountable owner for each agency activity and client input. Team names can appear as contributors, but they do not answer who must resolve a delay. Record due dates for source materials, access, approvals and consolidated feedback.
Describe third-party dependencies and who manages them. Do not promise third-party performance that the agency cannot control. Where a vendor or platform imposes a constraint, identify the current assumption and the response if it changes.
Use a risk register template for uncertain events that could affect delivery. Keep confirmed missed inputs in the status record rather than relabeling them as future risks.
Build a realistic schedule
Show phases, milestones, review windows and dependencies. State whether dates are fixed commitments, targets or estimates under the approved agreement. Include time for client review and agency correction rather than placing approval on the same day as release.
Document what happens when an input or approval is late. The effect may be a replan, additional cost review or movement to the next available production window, but only include consequences supported by approved commercial terms.
Use a client status report template during delivery to distinguish completed work, next actions, decisions and blockers. A current status report does not amend the scope unless the authorized change process says it does.
Set review and acceptance rules
Define the number and purpose of review rounds, who consolidates client feedback and what counts as a new direction rather than correction. Require feedback to reference the delivered version and acceptance criteria. Conflicting comments should be resolved by the client’s authorized owner before the agency acts.
Acceptance criteria should be observable and proportionate. Avoid subjective phrases such as “to the client’s satisfaction” without an agreed decision route. Define how defects, partial acceptance and disputed items are recorded.
Silence should not become approval unless the governing agreement explicitly establishes that mechanism and qualified owners confirm it. Preserve approver, version, date and conditions for every acceptance decision.
Control changes before work begins
Create one route for requests that alter a deliverable, boundary, assumption, dependency, schedule or cost. Capture the requested change and business reason, then assess its impact across all connected work. A small wording request can have larger effects when it changes compliance review, translation or production.
Present options when possible: substitute, defer, remove another item or approve added work. Record the decision in a decision log template and update the scope baseline only after authorized approval.
Teams may explore a request enough to estimate impact, but they should not begin changed production merely because it was discussed in a meeting.
Set a practical change threshold. Minor corrections that remain inside acceptance criteria may follow normal review, while changed direction, added formats, new audiences or compressed dates may require formal assessment. The threshold must align with approved agreements and should not be manipulated by splitting one substantial request into many small comments.
Maintain a visible pending-change list. Until approval, show the request as proposed, the affected work as conditional and the baseline as unchanged. Notify contributors when a decision lands so different teams do not work from conflicting assumptions.
Review pending requests at every governance checkpoint and close those that are withdrawn, superseded or rejected with a brief rationale.
Use Kuno in scope discussions responsibly
Scope meetings often include budgets, strategy, customer information and negotiating positions. Capture them only when all required participants have clear notice and the parties’ agreements, policies and applicable law permit it. Restrict access and retention according to the sensitivity of the engagement.
Turn an authorized scope discussion into a reviewable draft record. Kuno can help create notes and follow-ups for human verification, without deciding what either party has approved. Explore Kuno
Check generated notes against the executed documents and recording. Correct speakers, dates, numbers and implied commitments. A transcript is evidence of conversation, not automatically an amendment, acceptance or legally effective approval.
Approve, baseline and maintain the scope
Before approval, have delivery, commercial and qualified legal owners review the document within their responsibilities. Confirm that referenced prices, dates, policies, rights and obligations align with authoritative records. Resolve blanks and contradictory language rather than relying on assumptions.
Store the approved version with its signatures or documented approval evidence. During delivery, link accepted changes and superseded versions without deleting history. At close, compare completed and accepted deliverables with the baseline and approved changes.
Use meeting follow-up practices to distribute reviewed actions after governance meetings. Keep the action record connected to the scope so operational conversation cannot quietly redefine the engagement.
Keep scope conversations traceable and human-approved. Kuno supports consented capture and draft action notes; responsible client, agency, commercial and legal owners retain final judgment. See Kuno