Чому в шаблонах цього немає
Типовий договір підряду описує предмет, строки, ціну, порядок приймання й відповідальність за якість. Усе це правильно й потрібно.
Чого в ньому немає: що відбувається з доступами, акаунтами й напрацюваннями після завершення співпраці. Шаблони писались під роботи, де результат матеріальний — збудували, передали, розійшлись. У цифрових послугах результат живе в акаунтах, і саме акаунти лишаються неописаними.
Наслідок передбачуваний. Поки все добре, питання не виникає. Коли співпраця закінчується — особливо погано, — виявляється, що предмет спору взагалі не згаданий у документі.
Сім пунктів, які варто прописати
1. Власник рекламного акаунта. Акаунт Google Ads або Meta має бути створений на вашу юридичну особу, а агенція — отримати доступ. Не навпаки. Якщо акаунт агенції, при розриві ви втрачаєте історію кампаній, накопичені аудиторії та дані навчання алгоритмів за роки. Кампанії з нуля стартують дорожче — це не теоретична, а бюджетна втрата.
2. Власник аналітики. Google Analytics, Search Console, Tag Manager. Та сама логіка: ресурс ваш, доступ їхній. Історичні дані не переносяться між акаунтами.
3. Домен і DNS. Домен реєструється на вас. Це здається очевидним, доки не зʼясується, що його реєстрував підрядник «щоб було швидше», і тепер на ньому чужий контакт.
4. Репозиторій і права на код. Код має лежати у вашому репозиторії з першого дня, а не передаватись архівом наприкінці. Окремо пропишіть передачу майнових прав інтелектуальної власності — без цього прямого пункту права можуть лишитись у виконавця, і доробляти проєкт іншою командою ви не зможете легально.
5. Акаунт розробника в магазинах. App Store і Google Play — окрема історія. Застосунок, опублікований під акаунтом підрядника, фактично належить підряднику: ви не можете ні оновити його, ні перенести без участі другої сторони. Перенесення можливе, але це процедура, а не кнопка.
6. Сторонні сервіси й підписки. CRM, хостинг, поштові розсилки, платіжні шлюзи. Оформлені на кого і хто платить. Підписка на компанію-підрядника означає, що при розриві сервіс вимикається.
7. Порядок передачі при розриві. Строк, перелік і формат. Не «підрядник передає доступи», а конкретно: протягом скількох днів, які саме акаунти, у якому вигляді документація, хто підтверджує повноту передачі.
Скільки коштує їх відсутність
Прямих збитків зазвичай немає — є вартість відновлення.
Втрачений рекламний акаунт означає новий, з нульовою історією. Втрачений репозиторій — аудит чужого коду й часто переписування. Застосунок під чужим акаунтом — або перемовини, або публікація нового застосунку з втратою всіх відгуків і завантажень.
Кожен із цих сценаріїв рахується місяцями роботи, а не годинами юриста. При тому, що всі сім пунктів вносяться в договір за один вечір.
Це та сама ідея, яку ми ставимо в критерій оцінки підрядників: питання не в тому, скільки коштує робота, а в тому, скільки коштує від цього підрядника піти.
Як це внести, не зриваючи угоду
Ці пункти рідко викликають спротив у нормального підрядника. Якщо викликають — це інформація сама по собі.
Вносьте до підписання. Після початку робіт переговорна позиція слабша, а частина акаунтів уже створена не на вас.
Формулюйте як передумову старту, а не як недовіру. «Створюємо акаунти на нас, даємо вам доступи» — робочий порядок, а не претензія.
Перевіряйте фактично, а не за договором. Через місяць після старту відкрийте налаштування кожного акаунта й подивіться, хто власник. Договір може казати одне, а реальність показувати інше — і виправляти це дешевше на першому місяці.
Не вимагайте доступів рівня власника до внутрішніх інструментів підрядника. Його система управління проєктами, його ліцензії на софт — не ваші, і наполягати тут недоречно.
Наша позиція: якщо підрядник відмовляється створювати рекламний акаунт на клієнта, посилаючись на зручність, це достатня підстава не починати. Зручність тут одностороння. Заперечення діє для дуже дрібних разових робіт: заводити окрему інфраструктуру заради банера на тиждень справді недоцільно.