A statement of work is where a white-label engagement is won or lost. Your client signs it with you. Your delivery partner builds from it. If the two readings differ, the gap lands on you, because your name is on the contract and on the invoice.
This guide walks through what to put in an SOW so it works for all three parties: the client who pays, you who own the relationship, and the partner who delivers behind your brand.
What is a statement of work for?
An SOW defines one project. It says what will be delivered, by when, to what standard, under which assumptions and for what price. The legal terms that apply to every project, such as confidentiality, ownership of work and liability, usually sit in a separate master services agreement. Keeping them apart means each new project needs only a new SOW.
In a white-label model you will often have two SOWs for the same work: one between you and your client, and one between you and your delivery partner. The single most useful habit is to write the client SOW first, then derive the partner SOW from it line by line. Anything you promise the client should have a matching line in what the partner promises you.
The sections every SOW needs
1. Background and objective
Two or three paragraphs on why the project exists and what success looks like for the client. It is not legally precise, but it is what a developer reads first to understand intent, and it helps settle disagreements about scope later.
2. Scope, in and out
List what is included as concrete features or activities. Then list what is explicitly excluded. The out-of-scope list is as important as the in-scope list. Common exclusions to state: content writing, data migration from old systems, third-party licence costs, app store submission, and support after the warranty period.
3. Deliverables
Name each thing that will be handed over: source code in a named repository, a deployed environment, design files, documentation, test reports, training sessions. Say who owns each one at the end, which should match the IP terms in your master agreement. See NDA, non-solicit and IP clauses explained.
4. Acceptance criteria
For each deliverable or milestone, write acceptance criteria that a third person could test. "The checkout works" is not testable. "A logged-in user can add an item to the cart, apply a valid coupon, pay through the named payment gateway in test mode and receive an order confirmation email, on current Chrome, Safari and Android Chrome" is testable. Add how long the client has to review a delivery and what happens if they do not respond in that time.
5. Assumptions and dependencies
Write down what you are relying on: the client supplies content and brand assets by a date, provides access to existing systems, names one decision-maker, and answers questions within an agreed number of working days. When a dependency slips, this section is what lets you move the timeline without a dispute.
6. Roles and responsibilities
Who does what on each side. In a white-label setup, keep the delivery partner out of the client document if your arrangement is that the partner stays invisible, and describe the roles as your team. Internally, map each role to a named person at the partner.
7. Timeline and milestones
Break the work into milestones that each end in something the client can see and accept. Tie payments to accepted milestones rather than to dates alone.
8. Commercial terms
Price, the pricing model (fixed price or time and materials), payment schedule, taxes, and expenses. If you are unsure which model fits, read fixed price vs time and materials.
9. Change control
Describe how a change request works: who can raise one, how it is estimated, who approves it, and that no changed work starts until it is approved in writing. A short, clear process protects both you and the client. It also protects you from your partner, who should follow the same process with you.
Turning the client SOW into a partner SOW
Once the client SOW is agreed, build the partner SOW from it:
- Copy scope and exclusions word for word. Do not paraphrase. Paraphrasing is where gaps creep in.
- Copy acceptance criteria word for word, and make partner payment depend on your client accepting the same milestone.
- Shorten the partner timeline so there is room for your own review before anything reaches the client.
- Add white-label terms: the partner works under your brand, does not contact the client directly, and hands over code and documents without the partner's name in them.
- Mirror the change process, so a change the client approves flows through to the partner at a price you have already checked.
Common mistakes
- Selling from a slide deck. If the proposal promised it, the client will expect it. Make sure everything in the proposal appears in the SOW scope or is explicitly excluded.
- Vague non-functional requirements. Performance, security, accessibility and browser support need to be written down, not assumed.
- No exit from review loops. Without a review period and a limit on rounds of feedback, acceptance can drag on indefinitely.
- Estimating without a partner's input. Get the delivery partner to review scope and estimate before you sign with the client, not after. Good presales support does exactly this.
A short checklist before you sign
- Could a developer who was not in the sales meetings build from this document alone?
- Could the client and you agree, from the text alone, whether each milestone is done?
- Does every client promise have a matching partner promise?
- Is there a written way to change scope, and does it apply on both sides?
- Do ownership of deliverables and confidentiality match the master agreement?
If the answer to all five is yes, the SOW is doing its job. If you want help shaping scope and estimates before a proposal goes out, talk to BitLab India.