SOW template · Data & AI
Data Warehouse Build Statement of Work Template
A data platform SOW that caps sources, models and dashboards, defines data quality responsibility, and stops a warehouse build from becoming an endless reporting queue.
- 6
- Deliverables
- 6
- Exclusions
- 2 rounds
- Revision rule
Data & AI · Exclusion rule
Sources not in Schedule A, including spreadsheets maintained manually.
Ambiguity fix
Build a single source of truth for the business.
Build models for 6 sources and 15 agreed metrics. Other sources are added by change order.
Best for
Data consultancies building a modern stack on Snowflake or BigQuery with dbt and a BI layer.
Every dashboard request in a warehouse project sounds small, because the data is "already there". In practice each new metric needs a source, a model, tests and a definition the business agrees on. This template counts sources, models and dashboards, separates metric definition workshops from build, and makes source data quality the client's responsibility with a priced remediation option.
Copy any clause block below into your own SOW. Numbers, appendix names and tools are placeholders drawn from a typical engagement, so replace them with the counts from your proposal. Every clause is written to be read by a client, not used against one.
Deliverables
Count everything. A deliverable a client cannot count is a deliverable a client can expand.
- 2.1A Snowflake account configured with dev and prod databases, role-based access for 4 roles and cost monitors.
- 2.2Ingestion of 6 sources listed in Schedule A via Fivetran connectors or a custom loader for one non-supported source.
- 2.3dbt project with staging, intermediate and mart layers, up to 40 models, tests on primary keys and freshness, and generated documentation.
- 2.4A metrics layer defining the 15 business metrics agreed in the definition workshop.
- 2.5Five dashboards in Looker Studio or Power BI listed in Schedule B, each with up to 8 charts.
- 2.6Orchestration and alerting for daily refresh, plus a handover runbook and two training sessions.
Exclusions (out of scope)
Name what the engagement does not include. These are the lines your PMs will cite most often.
- 3.1Sources not in Schedule A, including spreadsheets maintained manually.
- 3.2Fixing data quality issues in source systems.
- 3.3Machine learning models, forecasting and reverse ETL.
- 3.4Dashboards beyond Schedule B and ad hoc analysis requests.
- 3.5Connector, warehouse and BI license costs.
- 3.6Historical data older than 36 months.
Revision limits
Each dashboard includes two consolidated revision rounds on layout and filters. Changes to an agreed metric definition after the definition workshop sign-off are changes, because they ripple through models and dashboards.
Acceptance criteria
Acceptance needs a measurable test and a window. Without both, delivery never formally ends.
- 5.1Each metric in the metrics layer reconciles to within 1% of the client's agreed source of truth for a named reporting month.
- 5.2dbt tests pass on the production run for five consecutive days.
- 5.3Dashboards load in under 10 seconds with default filters.
Client assumptions & dependencies
Tie each dependency to a date so a late input has a known effect on the schedule.
- 6.1Source systems allow API or database access with read credentials within five business days of kickoff.
- 6.2A business owner for each metric attends the definition workshop and signs off definitions.
- 6.3Source data is used as is. Quality issues are logged and reported, not fixed.
Change control
Adding a source, model beyond the cap, metric, dashboard or chart, or changing an approved metric definition, is a change. The consultancy issues a change order within two business days listing affected models and dashboards, hours, cost and timeline effect.
These clauses are drafting guidance written from agency delivery practice. They are not legal advice. Agencies should have final MSAs and SOWs reviewed by counsel, especially for liability, IP, payment and termination terms, which this template does not cover.
Ambiguity check
The phrases that turn into free work, and what to write instead.
These are the vague lines we see most often in data & ai SOWs. Each one sounds reasonable at signature and becomes a dispute three months later.
Before
Build a single source of truth for the business.
Safer rewrite
Build models for 6 sources and 15 agreed metrics. Other sources are added by change order.
Why it matters: A single source of truth is a multi-year program. Name this phase.
How to adapt it
7 steps from template to signed SOW.
A template saves drafting time. The protection comes from replacing every placeholder with the real counts, names and dates from your engagement.
- 1
Read the Data Warehouse Build SOW end to end and mark every number, appendix and named tool that does not match your engagement.
- 2
Run a paid definitions workshop before the build SOW if metrics are disputed internally.
- 3
Name a reconciliation month and the system that is the source of truth for it.
- 4
Count models from a quick source review, then add a 20% buffer to the cap.
- 5
Add a data quality log as a deliverable so issues are visible without being yours to fix.
- 6
Run the ambiguity check: search your draft for words like all, any, ongoing, as needed, unlimited and timely, and replace each one with a count, a list or a date.
- 7
Have your counsel review the final MSA and SOW before signature, then load the signed SOW into TWINJAM so every request is checked against it.
Editable Word file
Get the Data Warehouse Build SOW as a DOCX.
Every clause on this page in one formatted document, with numbered sections, appendix placeholders for your counts and a one-page change order form to attach to the SOW.
- 18 numbered clauses
- Revision and change control language
- Change order form with hours and rate fields
Data Warehouse Build SOW.docx
Editable Word file with appendix placeholders
One email with the file, then The Profitable Agency newsletter. Unsubscribe in one click.
Related templates
- Data & AIAI Chatbot Integration SOWAn LLM assistant SOW that fixes knowledge sources, channels, intents, evaluation criteria and model costs, so an AI chatbot project does not chase an ever-moving accuracy target.
- MobileReact Native App SOWA fixed-fee SOW for cross-platform iOS and Android builds that names every screen, caps device coverage, and keeps store submission and backend work from drifting into the base fee.
- E-commerceShopify Plus Migration SOWA replatforming SOW that fixes the data you migrate, the apps you replace and the redirects you map, so a Magento or WooCommerce move to Shopify Plus does not absorb every loose end in the old store.
Client asking for something outside the SOW already? Use a change order script to raise it warmly.
Signed the SOW? Let TWINJAM hold the line.
TWINJAM turns these clauses into boundary rules, flags Slack and Jira requests that cross them, and drafts the change order with the clause already cited.