A Statement of Work for a Virtual Delivery Center engagement is structurally different from a staff-augmentation or outsourcing SOW. The differences aren't decorative — they reflect a different operating model. Treating a VDC like a staff-aug contract, or a VDC like a fixed-bid outsourcing job, produces friction that compounds across quarters.
This piece walks through what belongs in a VDC SOW, what doesn't, the seven clauses that matter most for procurement and execution, and the structural shape that holds up across long-running engagements.
What's structurally different about a VDC SOW
Three differences from traditional contracting:
- The unit being purchased is shipped outcomes, not contracted hours. The SOW lists milestones with acceptance criteria, not roles with hourly rates.
- Pod composition flexes inside the contract. The SOW doesn't lock you into specific named individuals. Specialists can be added, rotated, or removed without contract amendments.
- Termination is milestone-bounded, not duration-bounded. Either side can exit at the next completed milestone. There's no multi-quarter wind-down clause.
If a vendor's proposed SOW looks like a staff-aug contract with the words "outcome-based" sprinkled on top, you're not getting a VDC — you're getting staff aug rebranded.
Section 1: Engagement scope and outcomes
The most important section, and the one most often under-specified. It should contain:
- Outcomes statement — what the engagement is supposed to ship, in business terms. "We will replace the legacy auth system with a new OAuth2-based identity layer that supports SSO across our existing applications."
- Anti-goals — what's explicitly NOT in scope. "Mobile app rewrite is not in this engagement."
- Success criteria — how the buyer will know the work is done. Often quantitative ("auth latency under 80ms p99," "all existing flows pass acceptance tests").
- Integration boundaries — which systems the pod has authority to modify and which they have to coordinate with via the client's other teams.
Avoid: generic outcome statements ("improve our delivery velocity"). These are unmeasurable and become disputes later. Be specific.
Section 2: Milestone schedule
For pure-milestone or T&M+milestone pricing, this section is the contract's heart. Each milestone needs:
- Title and number.
- Deliverables — what gets shipped at this milestone.
- Acceptance criteria — testable conditions for sign-off.
- Estimated duration (typically 2–4 weeks).
- Payment amount or rate (depending on pricing model).
- Dependencies — what must be true (from the client side) before the milestone can be hit.
The first 2–3 milestones should be detailed; later milestones can be sketched with the understanding they'll be refined as the engagement progresses. Locking 12 months of milestones upfront produces obsolete contracts within 90 days.
Section 3: Pod composition (without naming individuals)
The SOW specifies the role mix and seniority distribution, not the individual humans. This is the structural difference from staff aug — naming individuals locks them in and prevents the platform from rotating as work shifts.
What to include:
- Pod size (e.g., "5–7 specialists plus delivery manager and tech lead").
- Role mix (e.g., "2 backend, 2 frontend, 1 QA, 1 designer").
- Seniority distribution (e.g., "1 senior, 3 mid, 1 junior").
- The platform's commitment that the named delivery manager and tech lead won't rotate without 30-day notice and client agreement on replacement.
What NOT to include: specific named pod members. Tempting but wrong — it converts the engagement into staff augmentation by contract.
Section 4: Pricing model and payment terms
AiDOOS prices delivery in Delivery Units (DUs) — a universal output-based currency that replaces hourly billing, per-FTE subscription, and milestone-billing variants in a single primitive. The SOW spells out:
- The DU pack purchased (Starter / Small / Scale / Enterprise) or the engagement's estimated DU count and corresponding tier rate.
- $/DU rate locked for the validity window (90 days / 6 months / 12 months / custom).
- Trust mechanisms: pre-flight DU estimation transparency, re-delivery on acceptance miss, refundable unused DUs.
- Invoicing cadence (Starter / Small / Scale: paid up-front per pack; Enterprise: per agreed schedule).
- Payment terms (net 30 standard for Enterprise; credit-card up-front for Starter/Small/Scale).
- Currency.
- Tax responsibility.
- Renewal-rate guarantee (rate-locked for the engagement; renewal terms specified for Enterprise multi-year deals).
Section 5: Governance and reporting
Defines the operational rhythm:
- Sprint cadence (sprint length, ceremonies).
- Reporting schedule (typically weekly milestone updates plus monthly engagement reviews).
- Communication channels (Slack/Teams, email, formal reports).
- Escalation path (3 levels: pod-level, platform-level, contract-level) with SLAs.
- Audit trail commitments (what gets logged, retention, access).
Section 6: IP, NDA, and data handling
The legal core. The four sub-clauses that matter:
- IP transfer: at commit, not at full payment. Anything else is leverage masquerading as a clause.
- NDA: mutual, with explicit definitions of confidential information and standard exceptions (publicly available, independently developed, etc.).
- Data-handling addendum: co-authored for regulated sectors. Spells out classification, access boundaries, retention, audit.
- Work-for-hire: explicit work-product assignment with waiver of moral rights. Standard but worth verifying.
Section 7: Termination, replacement, and dispute resolution
The structural difference from outsourcing shows up here:
- Termination: milestone-bounded. Either side can exit at the next completed milestone with 30-day notice. No multi-quarter wind-down.
- Pod-member replacement: platform-default and automatic on underperformance. Client can request replacement of a specific pod member with reasonable cause.
- Missed-milestone remediation: platform-funded remediation OR proportional credit per milestone. Spelled out in advance, not negotiated when it happens.
- Dispute escalation: three-level path (pod, platform, contract) with SLAs at each level.
- Force majeure: standard clauses, with explicit treatment of cyber events.
What doesn't belong in a VDC SOW
Five clauses that traditional contracts include but a VDC contract shouldn't:
- Hourly rates by role. The contract is about milestones, not hours. Hourly rates only appear if the pricing model is T&M+milestone.
- Named individuals as the pod composition. Names lock in staff-aug behavior.
- Multi-quarter termination wind-down. Milestone-bounded exit is the model. A long wind-down is a red flag.
- Change-order procedures for scope adjustment. Scope changes recompose the milestone schedule, not trigger a change order. (Fixed-bid is the exception — change orders apply there.)
- "Best efforts" language for delivery commitments. Replace with milestone-acceptance criteria. "Best efforts" is unenforceable.
The procurement-defensible structure
For procurement and legal teams who haven't seen this contract shape before, the structural framing that defends well:
- "This is a milestone-based contract, not a time-and-materials contract."
- "Pod composition is configured by the platform; we contract for outcomes, not roles."
- "Termination is milestone-bounded — we have explicit exit points every 2–4 weeks."
- "IP transfers at commit, not at payment, eliminating IP-leverage risk."
- "The platform absorbs bench tax and management overhead; we don't pay for unproductive time."
Each of these is a structural improvement over typical procurement contracts. The framing positions the engagement model as risk-reducing rather than novel.
Frequently asked questions
How long is a typical VDC SOW?
10–20 pages. Shorter than a comparable outsourcing SOW (which often runs 40+ pages with role definitions and per-role rates) and longer than a staff-aug SOW (which is usually 5–10 pages of rates plus generic terms).
Can we negotiate the milestone schedule after signing?
Yes — milestone schedules recompose as scope evolves. The platform delivery manager facilitates the recompose conversation. No contract amendment required for normal scope shifts.
What if our legal team insists on naming individuals in the SOW?
Push back. Naming individuals is a staff-aug pattern, not a VDC one. The compromise: name the delivery manager and tech lead (these don't rotate without notice), but don't name the specialist engineers (those need to rotate as work shifts).
Who owns the engagement-specific risk register?
The platform delivery manager maintains it; the client engineering leadership has read access and adds items at their discretion. Risk-register items aren't contractual but are part of the standard governance reporting.
Where to start
If you have a draft SOW from a candidate VDC vendor, run it against this checklist. Anything missing or misaligned is worth flagging before signing — most issues are fixable through redlines, but post-signing they become operational friction.
To review your specific draft SOW or get a model SOW for an engagement you're scoping, schedule a 30-minute call. We'll walk through the structure and flag anything that should change.
For broader procurement context, see the 12-question adoption checklist. For the day-by-day execution context after the SOW is signed, see onboarding a VDC: the first 14 days.