I’ve been running into a recurring problem: I align everything with a subcontractor during the pitch phase, we sign an SOW, and then mid-project there’s confusion about what’s included in scope vs. what counts as “additional work.”
Last week I had a subcontractor push back on revision rounds because they said it wasn’t explicit in the SOW. And they were right—it was clear in our conversations, but not in the document. Now I’m trying to figure out: what level of detail actually belongs in a brief versus an SOW?
The hub has some partner-network resources on this, and I’ve been studying how other agencies structure their agreements. What I’m realizing is that most people are either writing SOWs that are so detailed they become contracts, or they’re writing briefs that are so vague the SOW becomes a guessing game.
For subcontractors specifically, I’m now trying this: the brief contains the creative direction, target audience, success metrics, and timeline. The SOW contains the deliverables, revision limits, payment terms, and what happens if scope changes. But here’s the thing—both documents now reference each other, so there’s one source of truth.
I started including a “scope boundary” section in both documents that explicitly calls out what’s not included. Sounds obvious, but it’s cut down my “well, that’s not what I thought” conversations significantly.
What’s your system? Do you try to make the brief so detailed that the SOW is basically just logistics? Or do you keep the brief lighter and let the SOW be the source of truth?
This is exactly the problem I’ve been wrestling with. I’ve settled on a hybrid: the brief is strategic and directional, the SOW is transactional and specific. But the key move was creating a “brief addendum” that lives between them—it’s where I spell out revision rounds, approval process, and escalation paths.
What changed for me was using the hub’s strategy-sharing feature to see how other agencies structure this. I noticed the agencies doing clean projects have one person responsible for maintaining that bridge document—usually project manager on the agency side, lead creative on the subcontractor side.
Have you tried assigning a single point person to own the alignment between brief and SOW? Because when that ownership is clear, the confusion drops significantly.
Strong observation about the scope boundary section. I’m stealing that. Most of my SOWs probably assume subcontractors will infer what’s not included, which is a bad assumption.
One tactical thing: I started watermarking my briefs and SOWs with version numbers and a “last updated” date. When a subcontractor comes back asking about something, I can literally show them the version they signed off on and what was different. Sounds bureaucratic, but it’s saved conversations.
The reference system you mentioned—where brief and SOW point to each other—that’s the real infrastructure. Are you using a doc system, spreadsheet, or something more formal?
This is the gap I’ve been feeling for months. The real issue is that SOWs written by lawyers and briefs written by creatives live in completely different universes. I’ve started requiring that whoever writes the SOW actually reads the brief first, and whoever briefs the subcontractor has to sign off on the SOW language.
My question: when you’re working with subcontractors across Russian and US markets, are you creating separate SOWs with different language/terms, or forcing everything into one bilingual document?
From the subcontractor perspective, this is exactly where friction happens. I’ve been on projects where the brief had amazing creative direction, but the SOW said something different about deliverables. It makes me paranoid.
What actually helps: when the agency sends me a brief, I now ask them explicitly to highlight the revision policy and the definition of “done” in yellow. If they can do that without going back to check, it means the brief is clear enough. If they hesitate, I know we need to talk more before signing.
I’d rather spend 30 minutes clarifying scope upfront than 5 revision rounds later. Your scope boundary section would absolutely help subcontractors like me feel confident taking on work.
You’ve identified the core issue: briefs and SOWs are written by different teams with different objectives. From a DTC perspective, I care most about whether subcontractors deliver by the deadline and hit KPIs. Everything else is operational noise.
Here’s what I’d test: instead of separating brief and SOW, create a single “scope document” that contains both strategic intent and transactional terms, with clear sections. Subcontractors might have better retention if everything lives in one place instead of bouncing between two documents.
Also—and this is critical—include a KPI section that’s shared with the subcontractor. Not hidden until post-launch. Tell them what you’re measuring and why. They’ll operate better with that context.
Отличный вопрос! Я вижу, что боль реальная. В моей практике я разработала простую систему:
- Брифф описывает “что” и “почему”
- SOW описывает “как”, “когда” и “за сколько”
- Приложение к контракту содержит определения—что считается ревизией, что считается дополнительной работой
Большой момент: я всегда провожу call перед подписанием, где мы вместе читаем ключевые части SOW. Не просто отправляю. Собеседуемся вместе. Это занимает 30 минут, но экономит недели волнений.
Мне нравится ваш подход с “scope boundary”. Я давно применяю похожую практику—в конце brief я всегда добавляю раздел “В ЭТОМ ПРОЕКТЕ НЕ ВХОДИТ”. Кажется очевидно, но это спасает.
Мой совет: убедитесь, что субподрядчик может дать вам письменный feedback на black and white пункты. Не просто согласиться, а сказать: “да, я понимаю, что ревизии лимитированы до 3 раундов.” Письменное подтверждение.
Это очень полезная рамка. Мы в стартапе часто спешим и недооцениваем важность четкого SOW. Но я вижу, что когда дело касается международных партнеров, документация становится еще более критична, потому что нет возможности трясти столом.
Внос вопрос: когда вы создаете SOW для субподрядчиков в разных странах, нужно ли переводить все детали на их язык или можно оставить оригинал + перевод?
Ваша система с point person, ответственном за синхронизацию brief и SOW—это умно. В нашем стартапе я обычно это делаю сам, но понимаю, что это масштабируемость неправильная. Как вы определяете, кто эту роль должен играть? Нужен ли специальный experience или достаточно внимательности и ответственности?