RFP and SOW for Game Art Outsourcing: Templates and Practices

Studios that treat vendor selection as a portfolio review and formalize the engagement with a one-page email agreement are the same studios that call their art outsourcing partner four months in to dispute what was actually included in the scope. The documentation that governs a game art outsourcing engagement — the Request for Proposal that selects the vendor and the Statement of Work that governs the production — is not administrative overhead. It is the operational infrastructure that determines whether the engagement delivers predictably or dissolves into revision chaos and budget overruns.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

This guide covers both documents from the perspective of the production team issuing them: what each one needs to contain, how they relate to each other in the procurement sequence, and what the critical clauses look like in practice for game art production specifically. Templates and clause language are included throughout.

RFP and SOW Are Different Documents for Different Stages

The most common documentation mistake in game art procurement is conflating the RFP and the SOW, or skipping the RFP entirely and going straight to a contract negotiated with a single vendor. Understanding what each document does — and when it belongs in the process — prevents both errors.

A Request for Proposal (RFP) is a pre-selection document. It is issued to multiple vendors before any engagement decision is made. Its purpose is to standardize the information you receive from each candidate so that proposals are comparable and the selection decision is defensible. An RFP describes what you need, establishes the questions each vendor must answer, and defines the criteria by which proposals will be evaluated.

A Statement of Work (SOW) is a post-selection document. It is issued to the vendor you have chosen, or negotiated collaboratively with them, as the operational and contractual specification of the engagement. The SOW defines exactly what will be produced, by when, to what standard, under what revision terms, and for what payment structure. It lives under or alongside a Master Services Agreement (MSA) that governs the legal terms of the relationship.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The procurement sequence for a structured game art outsourcing engagement follows five stages. Skipping the RFP phase and moving directly to SOW negotiation with a preferred vendor is sometimes appropriate for established relationships; for new vendor selection, it removes the comparative evaluation that protects the decision.

1. RFP Issuance — Pre-Selection Phase. Send the Request for Proposal to a curated longlist of studios. Standardize the information required so all incoming proposals are directly comparable on scope, process, team structure, and pricing — not just portfolio aesthetics.
   
2. Proposal Review and Scoring — Evaluation Phase. Apply a weighted scoring matrix to grade proposals on technical pipeline alignment, team stability, revision policy clarity, and communication maturity. Portfolio quality is one criterion among several, not the deciding factor.
   
3. Shortlist and Paid Test Asset — Validation Phase. Commission a small, paid test asset from the top one or two studios before committing to full production. Observe how the vendor interprets the brief, handles feedback, structures their files, and performs in the target engine. Production behavior reveals what no proposal document can.
   
4. SOW Negotiation and Execution — Legal Phase. Formalize the engagement with a Statement of Work covering exact deliverables, milestone gates, acceptance criteria, revision exhaustion terms, IP transfer language, and change order process — under or alongside a Master Services Agreement.
   
5. Kickoff and Production — Execution Phase. Launch full-scale asset creation with named points of contact on both sides, defined milestone cadence, and engine import reviews built into every delivery gate — not reserved for final QA.
   

Writing the Game Art RFP: What Studios Actually Need to Ask

An RFP for game art outsourcing is not a generic procurement document with “game art” inserted in the title. The questions it asks need to be specific enough to reveal whether a vendor can actually deliver in the production context you are operating in — which means the RFP needs to address art direction, technical pipeline, revision mechanics, and team structure, not just portfolio and pricing.

Section 1: Project Context

The first section of the RFP gives vendors the project context they need to provide a meaningful proposal. Generic vendor decks submitted without context are not useful for evaluation. Context should include:

• Game genre, platform, and target audience
• Visual style description with reference images (2–4 is sufficient at RFP stage)
• Engine and technical pipeline (including version, e.g., Unreal Engine 5.5)
• Expected scope: asset categories, approximate volume, and production timeline
• Whether concept art is included in scope or will be provided to the vendor
• Whether in-engine integration is part of the vendor’s deliverable or handled internally

This section should be detailed enough that vendors can qualify themselves in or out before spending time on a full proposal. A vendor that has never worked in UE5 should know from Section 1 that this RFP is not a fit.

Section 2: Required Information from the Vendor

The second section defines what each vendor must provide in their proposal response. Require the following:

Portfolio samples relevant to the scope. Not a link to the general portfolio — specific examples of work in the same asset category, visual style, and technical tier as the project. For a realistic 3D environment outsourcing engagement, this means environment art examples at the applicable fidelity level, ideally with real-time renders or in-engine screenshots rather than offline renders. Studios that outsource at scale — Guerrilla Games being the most documented example in the GDC Vault archive — maintain a small internal asset team precisely because the briefing and QA pipeline is rigorous enough to compensate for geographic distance.

Team structure for this engagement. Who specifically would work on the project? What is the ratio of senior to junior artists? Is there a dedicated art lead or point of contact? Will the same team remain consistent throughout, or does staffing change between milestones? Vendors who cannot answer these questions at proposal stage are telling you something important about how their production is managed.

Production process description. How does the vendor structure their internal review before delivering to the client? What QA steps happen before a milestone package is submitted? What project management tools do they use? What is the standard communication cadence?

Revision policy. How many feedback rounds are included per milestone? What constitutes a revision versus a new-scope request? How are out-of-scope changes handled?

Technical pipeline alignment. Can the vendor deliver assets that meet the project’s technical specification — naming conventions, file format, texture channel packing, engine-ready setup? Have they delivered into UE5 (or the applicable engine) before? Can they provide engine-import-tested deliveries rather than DCC-application renders?

Pricing and payment structure proposal. Request a line-item breakdown by asset category. Request the vendor’s standard payment structure and indicate whether milestone-based payment is expected. This is not a negotiation at RFP stage — it is information gathering.

References. Two or three professional references from comparable projects. The references should be contactable; if a vendor offers references who do not respond to outreach, that is a red flag with a clear signal.

Section 3: Submission Requirements and Timeline

Specify the submission deadline, the format in which proposals should be submitted, and the point of contact for clarification questions. Clarification windows — a defined period during which vendors may ask questions before submitting — prevent proposals based on misunderstood requirements and give all vendors equal access to the same information.

Scoring the Proposals: A Weighted Evaluation Framework

Receiving proposals and choosing a vendor by impression is the approach that produces the most regret. A structured scoring framework forces the evaluation team to apply the same criteria to every proposal, produces a documented rationale for the selection decision, and — critically for organizations with procurement governance requirements — makes the decision auditable.

A practical weighted scoring framework for game art outsourcing vendor selection uses six criteria, with weights calibrated to the project’s priorities. The weights below reflect a mid-core/AAA production context where technical pipeline alignment and process maturity are higher priority than for a casual or mobile production.

Criterion	Weight	What to Evaluate
Portfolio quality and style match	25%	Does existing work demonstrate the right fidelity tier, visual language, and asset category? Real-time renders carry more weight than offline renders.
Production process and QA	20%	Is there a documented internal review process? Do they describe QA steps before client delivery?
Technical pipeline alignment	20%	Can they deliver to the project’s engine spec? Have they worked in this engine before? Do they understand the naming schema, file format, and import requirements?
Revision and communication clarity	15%	Is the revision policy specific? Is there a named point of contact? Is communication described in operational terms rather than marketing language?
Team structure and stability	10%	Are named senior artists committed? Is there a dedicated art lead?
Price and payment terms	10%	Is pricing reasonable and transparent? Is the payment structure milestone-based and negotiable?

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Score each criterion 1–5. Multiply by the weight. Total scores determine the shortlist for test asset phase. A vendor who scores below 3 on technical pipeline alignment should not proceed to shortlist regardless of portfolio quality — a beautiful portfolio delivered in an incompatible pipeline creates integration work that offset any cost advantage.

The test asset phase should follow shortlisting: commission a small, paid test asset from the top one or two vendors before committing to full production. The test asset reveals production behavior — how the vendor interprets the brief, how they handle feedback, how their files actually arrive, and whether in-engine results match the DCC renders — that no proposal document can surface. Studios that object to paid test assets in principle are indicating something about their production confidence. This principle is consistent with industry case studies going back to large-scale AAA production: the GDC talk on outsourcing Forza Motorsport remains a reference point for identifying vendor pitfalls before committing to full-scale content production.

Writing the Game Art SOW: Structure and Required Clauses

Once the vendor is selected and the test asset has validated the partnership, the Statement of Work formalizes the engagement. A game art SOW is not a general-purpose freelance contract — it needs to address the specific operational and legal realities of art production: asset acceptance criteria, revision mechanics, IP transfer timing, source file delivery, and the change order process for scope additions.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The following structure covers every section a production-grade game art SOW needs.

1. Project Overview

A one-paragraph summary: what is being produced, for what title, on what platform, in what engine, over what general timeframe. This section should be specific enough that anyone reading the SOW can understand the production context without additional documents.

2. Scope of Work

The scope of work is the most operationally critical section of the SOW. It defines exactly what the vendor is and is not producing. Vagueness here is the primary source of scope disputes.

The scope should include:

• A complete asset list with quantity, category, and complexity tier per asset type
• For each asset category: polygon/geometry expectations, texture resolution, animation requirements (if applicable), LOD requirements, and file delivery format
• Explicit statement of what is excluded: “Concept art is not in scope. Client will provide approved concept sheets before modeling begins.” Or: “In-engine integration is in scope. Assets will be delivered engine-ready, import-tested, with Nanite configuration as specified in the technical appendix.”
• Reference to attached technical specification and art bible as governing documents for quality standard

Template language — scope inclusion/exclusion clause:

“The vendor will produce the assets listed in Exhibit A. Assets will be delivered as specified in the Technical Specification (Exhibit B) and must conform to the visual quality standard established by the art bible (Exhibit C). The following are expressly excluded from scope unless added by written change order: concept art, in-engine level assembly, animation rigging, and UI implementation.”

3. Deliverables and Milestone Schedule

This section defines what is delivered at each milestone and what acceptance looks like. Milestones should be defined by deliverable, not by date alone. A milestone that says “delivery on [date]” without a deliverable specification creates no accountability. A milestone that says “delivery of 10 hero environment props, blockout-approved, textured to first-pass standard per Exhibit B, by [date], to be reviewed against acceptance criteria in Section 5” creates a contractual checkpoint.

A typical milestone structure for a mid-scale 3D art outsourcing engagement:

Milestone 1 — Blockout approval. Grey-blocked geometry for all in-scope assets delivered at final scale. Acceptance criteria: correct proportions, modular fit, scale reference validated in engine.

Milestone 2 — First-pass textured delivery. First textured pass: base color, roughness, metallicity, normal map. Acceptance criteria: PBR values within specified range, texel density matches spec, naming conventions validated, no UV seams visible at intended viewing distance under production lighting.

Milestone 3 — Final delivery. Engine-import-tested, fully polished assets conforming to all technical and visual acceptance criteria. Source files (DCC project files, texture PSDs or Substance files) delivered alongside game-ready exports.

4. Technical Specification (as Exhibit)

The technical spec should be attached as a named exhibit rather than embedded in the SOW body, because it may be updated during production without requiring full SOW amendment. The spec document covers: naming conventions with examples, folder structure within the project, texture channel packing convention, polygon/geometry expectations per asset category, engine-specific configuration requirements (Nanite eligibility, material instance protocol, lightmap UV channel), export format and settings, and QA checklist the vendor must complete before milestone submission.

5. Acceptance Criteria

Acceptance criteria define, for each milestone, what constitutes a deliverable that meets the contract. They should be objective — measurable or verifiable by both parties without subjective judgment — and specific enough that a technical artist on either side can run through them systematically.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Template language — acceptance criteria clause:

“Deliverables at each milestone will be reviewed against the acceptance criteria in this section. Assets that meet all criteria will be accepted within [5] business days of delivery. Assets that do not meet one or more criteria will be identified in a written revision request specifying the specific criteria not met and the required correction. The vendor has [5] business days to address revision requests within the revision round included in this milestone.”

Example acceptance criteria for a 3D environment asset:

• Static mesh named per naming convention in Exhibit B
• Texel density within ±10% of specified value for asset category
• All UV channels within 0–1 space with no overlapping faces (except intentional lightmap channel)
• PBR values within range specified in Exhibit B: roughness [X–Y], metallicity [binary or specified range]
• No degenerate geometry, inverted normals, or non-manifold edges
• Nanite enabled/disabled per Exhibit B configuration table
• Material assignment maps to master material specified in Exhibit B
• Asset imports without errors in [engine version] and passes in-engine review

6. Revision Policy

The revision policy section must define two things with precision: what is included and what is not.

Included revisions: Each milestone includes [N] rounds of feedback and revision at no additional cost. A round of feedback is defined as a single consolidated set of notes from the client’s named point of contact. Revisions must address technical or visual non-conformance with the accepted brief, art bible, or acceptance criteria.

Excluded from revision rounds (new scope): Changes to approved concepts, addition of asset variants not included in the original asset list, changes to technical specification after first-pass delivery, or any request that requires substantially re-authoring an accepted asset constitute new scope and are handled through the change order process in Section 8.

Template language — revision exhaustion clause:

“If, following the included revision rounds, a deliverable has not reached acceptance, the client may: (a) accept the asset with documented exceptions; (b) commission additional revision rounds at the rate of [rate] per round; or (c) invoke the termination provisions in Section 10 for that deliverable. The vendor is not obligated to perform revisions beyond the included rounds without additional compensation.”

7. Payment Terms

Payment terms in game art outsourcing should be milestone-linked, not calendar-linked. Paying on calendar dates decouples payment from delivery; paying on milestone acceptance ties payment to performance.

A standard payment structure for a defined-scope engagement:

• 30–50% deposit at contract execution (funds initial resourcing and signals commitment)
• Milestone installments tied to accepted deliverables at each production gate
• Final payment on acceptance of all deliverables and receipt of source files

Template language — payment terms clause:

“Payment will be made according to the milestone schedule in Exhibit D. Each payment is triggered by the client’s written acceptance of the deliverables specified for that milestone. Acceptance or rejection of milestone deliverables will be communicated within [5] business days of delivery. Acceptance is not unreasonably withheld; if no written response is received within [5] business days, the milestone is deemed accepted. Late payment incurs interest at [rate]% per month.”

Late delivery: The SOW should also address late delivery by the vendor. A late delivery clause — specifying that delivery more than [N] business days after the agreed milestone date may result in a fee credit against the next milestone payment — creates accountability without invoking termination for minor slippage.

8. Change Order Process

Scope changes are inevitable in game development. The SOW should make the change order process clear enough that both parties know exactly how to handle them when they arise, so the conversation does not become adversarial.

Template language — change order clause:

“Any request by either party for work outside the scope defined in Section 2 must be submitted as a written Change Request. The vendor will respond with a written Change Order specifying the additional deliverables, timeline impact, and cost within [5] business days. Work on the changed scope does not begin until the Change Order is signed by authorized representatives of both parties. Verbal agreements to scope changes are not binding.”

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The change order clause also prevents scope creep from informal channels — the art director mentioning “one more variant” in a Slack message, or the producer asking for “just a quick adjustment” that turns into two additional days of work. When both parties know that out-of-scope requests require a formal change order to be actionable, the informal channel pressure disappears.

9. Intellectual Property and Work-for-Hire

This is the highest-stakes clause in the SOW for most game studios. The default legal position in most jurisdictions is that the creator owns the work they create. Work-for-hire and IP assignment clauses are how studios transfer ownership of outsourced assets to themselves. The gap between intent and documentation is wider than most production teams assume: Deloitte’s 2024 Global Outsourcing Survey found that fewer than half of organizations include specific IP and governance terms in their outsourcing contracts — a finding that reflects general vendor management practice, not game art specifically, but one that maps directly to the pattern of IP disputes that surface in outsourcing relationships where the SOW was treated as a formality.

Template language — work-for-hire / IP assignment clause:

“All work product created by the vendor under this Statement of Work, including but not limited to 3D models, textures, concept art, animation files, source files, and associated documentation, is created as work-for-hire. All intellectual property rights, including copyright, vest in [Client Studio] upon creation. To the extent work-for-hire does not apply under applicable law, the vendor hereby assigns all intellectual property rights to [Client Studio], effective upon full payment of the amounts due under this SOW. The vendor retains no rights to use, reproduce, or display the work product without prior written consent of [Client Studio], including for portfolio use, except as separately agreed in writing.”

Portfolio use carve-out: Many studios will request the right to display work product in their portfolio after the game ships. This is reasonable and standard — negotiating a mutual portfolio carve-out after release is preferable to a blanket prohibition that creates post-engagement friction. The clause above can be modified with: “Following public release of the game title specified in this SOW, the vendor may display deliverables in their portfolio, subject to [Client Studio]’s approval of specific portfolio use cases.”

Source file delivery: IP transfer is only meaningful if the studio also receives source files. The SOW must explicitly require delivery of DCC source files (Maya/Max/Blender project files, Substance Painter files, PSD texture sources) alongside game-ready exports. An IP assignment clause without source file delivery means owning the copyright to files you cannot open or modify.

10. Confidentiality and NDA

If an NDA has not been signed at the RFP stage, the SOW should include a confidentiality clause covering both parties’ obligations. At minimum: the vendor agrees not to disclose project details, concept art, game systems, or unreleased content to third parties; the client agrees not to disclose the vendor’s proprietary production processes or pricing to competitors. The confidentiality obligation should survive the end of the agreement for a defined term (typically 2–5 years post-completion).

11. Termination

The SOW should address both termination for cause and termination for convenience.

Termination for cause allows either party to terminate if the other materially breaches the SOW and fails to cure the breach within [10–15] business days of written notice. Material breach on the vendor’s side includes persistent failure to meet acceptance criteria, delivery delays exceeding [N] business days beyond milestone dates, or IP breach. Material breach on the client’s side includes non-payment within [N] days of milestone acceptance.

Termination for convenience allows the client to end the engagement without cause, subject to payment for all work completed and accepted at the time of termination, plus a kill fee for work in progress at the point of termination (typically 25–50% of the in-progress milestone value). The kill fee compensates the vendor for resourcing committed to work that will not be completed; it is standard practice and should be negotiated into the SOW upfront rather than disputed at termination.

How Nasty Rodent Approaches Documentation in Practice

At Nasty Rodent, every engagement begins with documentation before assets. We treat the Statement of Work not as a formality that follows the handshake but as the operational foundation that makes the handshake meaningful. Before any production scope is agreed, we align on deliverable definitions, acceptance criteria, revision boundaries, and IP terms — in writing, in a document that both parties can return to when a question arises at month three.

Our scalable art production workflow is built around milestone-based delivery with defined acceptance criteria at every gate. For studios that need production support spanning environments, characters, and art direction for outsourced production, we bring the same documentation discipline to every asset category and every milestone.

Having worked with production teams across the industry — including Void Interactive, Saber Interactive, and Funcom — we have developed a SOW structure that maps directly to game production gates and enforces technical compliance at delivery, not after integration. If your team is scoping a new outsourcing engagement and needs a partner whose documentation standards match your production requirements, that conversation starts with scope alignment, not a portfolio deck.

Nasty Rodent — game art outsourcing with production-grade documentation standards. See our structured 3D production workflow.