Сделка с размещением у покупателя: поддержка, обновления и безопасность

Почему эта сделка может разделить ваш продукт надвое

Сделка с размещением у покупателя может выглядеть как еще одна победа в продажах. На практике она способна создать вторую версию вашего продукта со своими правилами, своим ритмом и своей нагрузкой на поддержку.

В обычной SaaS-схеме всей инфраструктурой управляет ваша команда. Вы выбираете облако, график релизов, мониторинг, план отката и процесс поддержки. Когда программой управляет покупатель, контроль переходит к нему. Его сетевые правила, процесс согласований, политика резервного копирования, инструменты безопасности и окна для изменений начинают влиять на то, как ваш продукт работает каждый день.

Именно так и начинается разделение. Одному клиенту может понадобиться старая версия базы данных, частный реестр, ручное одобрение обновлений, отдельный журнал аудита или поддержка только в рабочие часы. На бумаге базовый продукт остается тем же, но то, как ваша команда его разрабатывает, тестирует, выпускает и исправляет, меняется.

Поддержка обычно растет уже после подписания контракта, а не до него. Теперь вашей команде приходится отвечать на вопросы другого уровня: проблема в вашем коде, в инфраструктуре клиента или в том, как он настроил установку? Даже небольшая неполадка занимает больше времени, когда нельзя напрямую посмотреть логи или быстро внести исправление самостоятельно.

Вариант с размещением у клиента может занимать 15 минут на помощь. Но установка у покупателя способна съесть полдня, потому что инженеру приходится воспроизводить проблему в похожей среде, ждать доступа и объяснять одно и то же решение нескольким людям.

Поэтому на самом деле решение касается времени, рисков и ответственности. Сколько дополнительных часов инженеров и поддержки будет съедать этот клиент каждый месяц? Что произойдет, если обновления задержатся, среды начнут расходиться или станет непонятно, кто отвечает за инцидент? И кто контролирует доступность, резервные копии, доступ, обновления и финальное решение во время простоя?

Если не договориться об этом заранее, контракт превращается в операционную нагрузку. Кодовая база у вас по-прежнему одна, но поддерживать приходится два продукта: тот, который вы запускаете сами, и тот, который покупатель запускает у себя на собственных условиях.

Что меняется, когда покупатель сам запускает программное обеспечение

Как только покупатель начинает сам запускать программное обеспечение, ваша команда перестает контролировать среду, в которой возникают проблемы. Код по-прежнему ваш, но повседневная реальность быстро меняется. Небольшая неполадка в вашей собственной SaaS-среде может превратиться в длинную переписку, когда серверами, сетью и правилами доступа владеет кто-то другой.

Большая часть разделения здесь — операционная. Обычно покупатель контролирует серверы, хранилище, сеть и системный доступ. Часто он же управляет учетными записями пользователей, правилами VPN и изменениями в брандмауэре. Резервные копии могут быть на стороне покупателя, но вопросы о восстановлении все равно прилетают вашей команде. Мониторинг тоже может быть общим, и это звучит разумно, пока тревоги не уходят не тем людям.

Именно это чаще всего и вызывает трение. В обычной SaaS-схеме сбой первым видит ваша команда, потому что ваши оповещения срабатывают раньше, чем клиенты что-то замечают. В сделке с размещением у покупателя проблему может первой заметить IT-команда клиента, а может не заметить никто, пока пользователи не начнут жаловаться. И даже тогда пользователи часто винят ваш продукт, а не инфраструктуру покупателя.

Отладка тоже замедляется. Если ваши инженеры не могут открыть логи, посмотреть базу данных, перезапустить сервис или проверить системные метрики, каждый инцидент требует больше шагов. Ошибка, которую в вашей собственной среде можно диагностировать за 20 минут, может растянуться на два дня согласований, скриншотов и заранее назначенных окон доступа.

Еще одно большое изменение — расхождение версий. Один покупатель остается на актуальной версии. Другой откладывает обновление на шесть месяцев. Третий меняет версию базы данных, настройки прокси или агент резервного копирования. В итоге ваша команда поддерживает один и тот же продукт в нескольких немного разных средах, и каждая разница может породить свой способ отказа.

Именно поэтому сделка с размещением у покупателя меняет не только способ развертывания. Она меняет контроль, скорость реакции и то, на кого ложится ответственность. Если в договоре не написано, кто отвечает за каждый кусок операционной работы, ваша команда будет тратить время поддержки на споры о доступе вместо того, чтобы чинить проблему.

Сначала оформите служебную записку с решением

Прежде чем кто-то начнет править текст договора, подготовьте одностраничную записку. В ней должно быть объяснение, зачем покупатель хочет запускать программное обеспечение у себя, что именно это меняет и какую работу ваша команда возьмет на себя.

Начните с причины покупателя. Иногда причина действительно веская: внутренние сетевые правила, ограничения по обработке данных или закупочная политика, которая блокирует shared SaaS. А иногда это просто предпочтение. И это различие важно. Если причина слабая, дополнительные затраты и трение могут не стоить сделки.

Сделки с размещением у покупателя часто сначала выглядят простыми. Потом накапливаются мелкие исключения, и они превращаются в постоянную работу. Занесите в записку каждое отклонение от вашего обычного продукта, даже неловкое. Кто устанавливает программное обеспечение? Кто владеет инструкцией по действиям? Кто отвечает за резервные копии, мониторинг и реакцию по дежурству? Как происходят обновления и кто тестирует их перед выходом в продакшн? На какие проверки безопасности, аудиты и опросники вашей команде придется отвечать? Какие интеграции или сетевые правила существуют только для этого покупателя?

После этого разделите дополнительную работу на отдельные строки цены. Не прячьте ее внутри одного годового платежа. Часы поддержки, время на проверку безопасности, тестирование обновлений, обратные исправления и помощь с кастомным развертыванием стоят по-разному. Если все это упаковать в один пакет, покупатель будет считать, что оно включено навсегда.

Записка должна еще и заставить принять прямое решение по риску. Для каждого пункта отметьте: принять, изменить или отклонить. «Принять» значит, что вы готовы жить с затратами и усилиями. «Изменить» значит, что нужна более жесткая формулировка договора, более высокая цена или более узкое обещание. «Отклонить» значит, что запрос создает слишком большой долг по поддержке или слишком высокий риск для безопасности.

Используйте эту записку до того, как начнутся юридические правки. Когда юристы обмениваются версиями, люди защищают позиции вместо того, чтобы задаваться вопросом, действительно ли сделка еще имеет смысл. Четкая записка дает product, engineering, security и sales общее понимание до того, как договор затвердеет.

Опишите границы поддержки простыми словами

Сделка с размещением у покупателя становится хаотичной, когда обе стороны по-разному понимают поддержку. Если клиент запускает программное обеспечение на своих серверах, в договоре нужен простой язык о том, кто отвечает, когда он отвечает и что именно делает.

Начните с базовых вещей. Укажите часы поддержки, канал связи и целевое время реакции для каждого уровня критичности. Поддержка только по электронной почте в рабочие часы сильно отличается от круглосуточного реагирования на инциденты через чат или телефон. Все цифры нужно зафиксировать письменно. «Мы отвечаем в течение 1 рабочего дня» — это ясно. «Быстрый ответ» — нет.

Что покрывает ваша команда

Проведите жесткую границу между проблемами приложения и проблемами инфраструктуры покупателя. Если ваш код выдает ошибку после обычного развертывания, это, скорее всего, ваша зона ответственности. Если покупатель неверно настроил Kubernetes, переполнил диск, сломал DNS или заблокировал трафик брандмауэром, это его зона ответственности, если только вы не договорились управлять этим стеком.

Короткий блок про объем обычно работает лучше, чем длинный юридический абзац:

• Ваша команда поддерживает приложение, документированные шаги установки и воспроизводимые баги.
• Покупатель отвечает за свой облачный аккаунт, сеть, хостинг базы данных и контроль доступа, если в договоре не сказано иначе.
• Ваша команда просматривает логи, которые создает приложение.
• Покупатель хранит серверные логи, задания резервного копирования и мониторинг своей инфраструктуры.
• Любая сторона может перевести работу вне объема в оплачиваемые консультации.

Резервные копии и первичная разборка инцидента требуют такого же уровня детализации. Решите, кто запускает бэкапы, кто проверяет восстановление, кто сначала собирает логи и кто подключается к первому звонку по инциденту. Если никто не владеет этими задачами, обе стороны будут тратить часы на попытки доказать, что проблема началась где-то еще.

Работа вне объема должна иметь простой путь оплаты. Добавьте понятный прайс или пункт о том, что любая дополнительная работа требует письменного согласования. Это защищает отношения и не дает мелким одолжениям превратить сделку во второй продукт, который каждую неделю выматывает вашу команду.

Если клиенту нужна более тесная помощь, лучше вынести ее в отдельное соглашение об операционной поддержке или консультациях, а не прятать внутри стандартной поддержки.

Сразу зафиксируйте права на обновления

Обновления быстро превращаются в хаос, когда программное обеспечение запускает покупатель. Если никто не решит, как утверждаются новые версии, каждый релиз станет маленьким торгом.

Правила обновлений нужно прописывать в договоре, а не в письмах. Назначьте по одному человеку или команде с каждой стороны, кто может утверждать релиз. Ваша команда должна контролировать, что входит в пакет релиза. Покупатель должен контролировать, когда он попадет в его тестовую и продакшн-среду.

Несколько правил важнее остальных. Зафиксируйте окно релизов, например ежемесячное или ежеквартальное, чтобы обновления не расползались на месяцы. Добавьте правило отката с временным лимитом, понятными триггерами и одной стороной, которая может его запустить. Укажите, кто тестирует кастомные интеграции после каждого обновления. Задайте минимально поддерживаемую версию и срок, в течение которого покупатель может отставать. И если покупателю нужны особые ветки, обратные исправления или задержка обновлений, эту работу нужно оценивать отдельно и письменно.

Чаще всего больше всего трения возникает на стыке интеграций. Ваш продукт после обновления может работать отлично, а вот SSO, платежный поток, синхронизация с ERP или внутренние скрипты покупателя — нет. Если за эти интеграции отвечает покупатель, так и напишите, что именно он их тестирует. Если их строила ваша команда, укажите, входит ли повторное тестирование в обычную поддержку или оплачивается отдельно.

Не позволяйте покупателю навсегда заморозиться на старой версии. Сначала это кажется безобидным, но потом накапливаются патчи безопасности, исправления багов перестают совпадать, и ваша команда начинает поддерживать поведение, которого уже нет в основном продукте. Хорошо работает простое правило: поддерживайте текущий релиз и одну более раннюю major-версию в течение фиксированного срока. После этого поддержка становится платной best-effort работой до тех пор, пока клиент не обновится.

Особые ветки должны стоить отдельно. Если покупатель хочет кастомную версию, отложенные обновления или патчи для старого релиза, берите деньги за дополнительное время инженеров. Одна кастомная ветка может тихо съедать столько же времени, сколько несколько обычных клиентов.

Команды, которые хорошо работают с enterprise-программным обеспечением, держат здесь строгие правила. Oleg Sotnikov часто убеждает основателей сохранять один чистый путь релизов, потому что это защищает и затраты, и доступность. Он подчеркивает то же самое и в своей работе как Fractional CTO: если каждое обновление требует спора, значит объем уже слишком размыт.

Разделите обязанности по безопасности без серых зон

В сделке с размещением у покупателя путаница в безопасности быстро становится дорогой. Если договор оставляет место для догадок, обе стороны считают, что рискованные части делает кто-то другой. Так один корпоративный контракт превращается в бесконечные споры уже после первого сбоя или аудита.

Прописывайте ответственность по безопасности по слоям, а не расплывчатыми фразами вроде «shared responsibility». У каждого слоя должен быть один понятный владелец.

Покупатель должен устанавливать патчи для операционной системы, виртуальных машин, сетевых устройств, правил брандмауэра и той базы данных, которую он сам запускает. Ваша команда должна обновлять код приложения, встроенные сервисы и сторонние библиотеки, которые вы поставляете. Покупатель должен управлять административными учетными записями в своей среде и регулярно проводить ревизию доступа. Одна сторона должна хранить журналы аудита в согласованный срок, а другая — получать к ним доступ, когда начинается инцидент. Один назначенный руководитель инцидента должен координировать разбор, сбор доказательств и уведомления клиентам.

Административный доступ тоже требует простых правил. Укажите, кто может создавать привилегированные учетные записи, кто их утверждает, как часто покупатель проверяет их и как быстро удаляет устаревший доступ. Если вашей службе поддержки нужен экстренный доступ, опишите, как она его запрашивает, как долго он действует и кто наблюдает за этой сессией.

Журналы аудита требуют такой же детализации. Решите, какие логи важны, где они хранятся и как долго каждая сторона их сохраняет. В большинстве споров по контрактам на self-hosted software суть конфликта не в том, существуют ли логи. Проблема в том, что логи лежат в системе покупателя, их никто не выгрузил, а ваша команда не видит достаточно данных, чтобы диагностировать взлом или доказать, что произошло.

Реагирование на инциденты тоже нуждается в одном лидере. Если покупатель обнаружил подозрительный трафик, кто получает первый звонок? Если ваша команда нашла уязвимость в приложении, кто сообщает об этом покупателю и кто решает, нужно ли уведомлять клиентов? Все имена, роли и сроки реакции нужно зафиксировать письменно.

Затем проверьте каждое обещание по безопасности на то, что ваша команда действительно может проверить. Не обещайте безопасную инфраструктуру, если вы не можете смотреть серверы покупателя. Не обещайте скорость установки патчей для систем, которыми не управляете. Если ваша команда не может это мониторить, тестировать или менять, сузьте обещание до подписания договора.

Реалистичный пример: одна корпоративная сделка

SaaS-компания подписывает крупный годовой контракт с одним корпоративным клиентом. Покупатель хочет private deployment в своей собственной среде, и выручка выглядит достаточно сильной, чтобы оправдать дополнительную работу. Команда воспринимает это как исключение для продаж, а не как решение по продукту.

До закрытия сделки приходят три запроса. Покупатель хочет доступ по VPN для диагностики, календарь релизов, который подстраивается под его внутреннее окно изменений, и поддержку по выходным для инцидентов. По отдельности это не выглядит чем-то большим, поэтому команда соглашается на все три пункта.

Проблемы начинаются через месяц. Основной продукт выходит каждую неделю, но сделка с размещением у покупателя теперь движется по более медленному графику. Один инженер тратит пятничные вечера на подготовку отдельного пакета релиза. Сотрудники поддержки держат дежурство по телефону на выходных ради одного клиента. Операционная команда поддерживает правила VPN, журналы доступа и отдельную инструкцию по действиям только для этого разворачивания.

К третьему месяцу покупатель откладывает обновление, потому что не закончил внутреннее тестирование. SaaS-команда еще на пару недель оставляет старую версию живой. Это превращается в месяцы. Исправления багов теперь нужно дополнительно проверять в двух версиях, а некоторые исправления требуют двух отдельных патчей. Выручка по-прежнему хорошо выглядит на бумаге, но маржа уже снижается.

Короткая записка, подготовленная до подписания, могла бы остановить этот дрейф. Ей не нужен был бы юридический язык. Нужны были бы только четкие пределы по часам поддержки, политике обновлений, способам доступа и разделению безопасности. Если бы покупатель начал спорить с этими пунктами, команда увидела бы реальный объем работы еще до подписания.

Команды часто пропускают этот момент, потому что корпоративная выручка какое-то время скрывает плохое соответствие. Один аккаунт не должен заставлять вас вести два цикла релизов, две модели поддержки и два playbook по безопасности, если только договор не оплачивает именно такую реальность.

Ошибки, которые команды совершают до подписания

Договор часто выглядит знакомо, и команды просто вставляют в него свои SaaS-условия, надеясь, что остальное само как-нибудь сложится. Этот shortcut быстро создает проблемы.

В обычной SaaS-схеме ваша команда контролирует хостинг, логи, развертывания, резервные копии и мониторинг. В сделке с размещением у покупателя этим в основном управляет покупатель. Если оставить старый текст без изменений, можно случайно пообещать доступность, время реакции или восстановительные работы, которые ваша команда не сможет выполнить без доступа.

То же самое ломается и в формулировках по безопасности. Команды часто соглашаются на патчинг, реагирование на инциденты или hardening еще до того, как понимают, дадут ли им административный доступ, VPN-доступ или хотя бы полезные логи. Если серверы принадлежат покупателю, а глубокий доступ закрыт, ваша команда не сможет нормально посмотреть систему, проверить исправление или подтвердить, что случилось после тревоги.

Сроки обновлений тоже тихо превращаются в хаос. Размытая фраза вроде «поставщик будет предоставлять обновления» звучит безобидно, но покупатели часто читают ее как долгосрочную поддержку старых версий, кастомные обратные исправления и гибкие окна обновлений, подстроенные под их внутренний график. Так один релиз для клиента незаметно превращается в отдельную ветку продукта.

Кастомную поддержку тоже часто называют доброй волей. На звонке по продажам звучат несколько дружелюбных обещаний: помочь с развертыванием, посмотреть скрипт, подключиться к еще одной встрече, исправить один нестандартный workflow. По отдельности это не кажется чем-то большим. Вместе — это неоплачиваемый уровень поддержки, который инженерной команде приходится тащить каждую неделю.

Последняя ошибка проявляется слишком поздно: команды не считают внутреннюю нагрузку. Один контракт на self-hosted software может втянуть product, engineering, support, security и legal в работу, которая не помогает основной дорожной карте.

Простой пример это показывает. Покупатель просит частную установку, более редкий график обновлений и помощь с security review. Sales соглашается, потому что выручка выглядит хорошо. Через три месяца инженеры проводят пятничные вечера на задачах только этого покупателя, support обрабатывает тикеты по старой версии, а product задерживает общие для всех функции.

Если сделка работает только потому, что ваша команда «разберется потом», значит цена неверная, объем неверный или и то и другое.

Короткая проверка перед тем, как сказать «да»

Быстрая проверка интуицией может сэкономить месяцы лишней работы. Если эта сделка создает новые правила поддержки, кастомные обновления или общую работу по безопасности, вы, возможно, строите второй продукт, просто не называете его так.

Перед подписанием сделки с размещением у покупателя используйте короткую внутреннюю проверку. Если ваша команда не может ответить на эти вопросы на одном совещании, лучше притормозить.

1. Это действительно исключение или начало нового предложения? Один клиент с особенными условиями размещения может звучать безобидно. Но если такой запрос, скорее всего, повторится, относитесь к нему как к решению по продукту, а не как к одолжению для продаж.
2. Может ли один человек вслух объяснить все границы поддержки? Кто отвечает за резервные копии, неудачные обновления, медленные серверы, проблемы с доступом и выходные инциденты? Если объяснение расплывается, договор тоже будет расплывчатым.
3. Как выглядит стоимость после запуска, а не только в момент подписания? Дополнительные часы поддержки, кастомная документация, проверки безопасности и помощь с обновлениями часто превращают красивую сделку в слишком тонкую по марже.
4. Может ли product сохранить один график релизов? Если этому покупателю нужны отложенные обновления, отдельные патчи или утверждение перед каждым изменением, ваша дорожная карта может расколоться.
5. Подписали бы вы такие же условия еще для трех клиентов? Если ответ нет, значит условия, скорее всего, слишком кастомные, слишком дорогие или слишком рискованные.

Простой пример помогает это увидеть. Допустим, покупатель хочет запускать ваше приложение у себя и просит ежеквартальные обновления, совместные проверки безопасности и поддержку тикетов с временем ответа в четыре часа. Это все еще может работать, но только если ваша команда может это оценить, объяснить и повторить без напряжения.

Именно здесь может помочь внешний технический советник. Человек, который уже вел продукт, инфраструктуру и enterprise-сделки, обычно быстро замечает скрытую вторичную стоимость.

Что делать дальше

Сделка с размещением у покупателя должна завершаться одним четким пакетом, а не россыпью дополнительных обещаний из звонков и переписок. Если записка с решением получилась хорошей, сразу превратите ее в два рабочих документа: текст договора для покупателя и внутреннюю записку о передаче для вашей команды.

В договоре должно быть написано, кто что поддерживает, кто управляет обновлениями и кто отвечает за каждую задачу по безопасности. Во внутренней записке нужно сказать то же самое простыми словами, с именами, датами и ограничениями, которым ваша команда действительно сможет следовать. Если эти два документа говорят разное, сделка начнет дрейфовать в тот момент, когда покупатель попросит что-то дополнительное.

Получите одобрение того же объема работ у людей, которые будут нести расходы после подписания. Обычно это product, engineering, security и finance. Product проверяет, не уводит ли запрос дорожную карту в сторону. Engineering смотрит, реалистичны ли правила развертывания, обслуживания и версионирования. Security проверяет разделение обязанностей. Finance оценивает, сохранится ли маржа через шесть месяцев, а не только в первый день.

До принятия условий подтвердите поддерживаемую среду, что выходит за рамки поддержки, кто может задерживать обновления или требовать их, кто патчит каждый слой, каковы сроки реакции, как согласуется оплачиваемая работа вне объема и кто владеет аккаунтом после подписания. Если хотя бы один пункт остается размытым, остановитесь и сначала его проясните.

Именно здесь внешняя проверка может сэкономить реальные деньги и время. Хороший Fractional CTO может одновременно прочитать договор и архитектуру, а потом увидеть, где в реальной жизни сломаются границы поддержки, контроль обновлений или обязанности по безопасности. Если вам нужен такой второй взгляд, Oleg Sotnikov делает это через oleg.is в рамках своей консультационной работы со стартапами и небольшими командами. Особенно полезно сделать это до того, как юридический текст затвердеет, и до того, как sales начнет неформально обещать то, что потом никто не сможет поддержать.