Сделки с размещением у клиента проваливаются без ответственного за обновления

Что идет не так после продажи

Закрыть сделку кажется финишной чертой. Во многих сделках с размещением у клиента именно с этого и начинается самое дорогое.

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

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

Сценарий знакомый. Одна команда управляет приложением. Другая — инфраструктурой. Кто-то со стороны клиента утверждает изменения по безопасности. А за обновления всей связки никто не отвечает. Продукт движется вперед, а рабочая система за ним не успевает.

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

Поддержка сразу же начинает тормозить. Когда приходит тикет, поставщику сначала нужно понять, что именно у клиента стоит в работе, кто может дать доступ, есть ли логи и где проблема — в продукте, в хостинге или в пропущенном патче. Ошибка, на подтверждение которой должно уйти 20 минут, может сжечь полдня еще до того, как кто-то откроет код.

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

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

Продажа закрывается быстро. А беспорядок проявляется позже — в очередях поддержки, отложенных патчах и счетах, которые никто не ожидал обсуждать.

Почему теряется ответственность за обновления

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

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

Операционную часть обычно подхватывает IT-команда клиента. Они управляют серверами, правилами VPN, резервными копиями и окнами на изменения. Это настоящая работа, но она не равна ответственности за сроки выхода продукта. Большинство IT-команд не решают, когда версия поставщика должна перейти с 4.2 на 4.3, и кто будет проверять это изменение в бизнес-процессах.

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

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

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

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

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

Как начинается расхождение версий

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

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

Теперь клиент уже отстал на две или три версии, и догонять становится рискованнее, чем оставаться на месте. После этого разрыв начинает расти сам по себе.

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

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

Со временем ломается даже простое общение. Ваши release notes описывают версию 6.4, а у клиента по-прежнему стоит 6.1 плюс две кастомные правки и один ручной hotfix. Поддержка читает заметки, клиент смотрит на экран, и обе стороны думают, что говорят об одном и том же продукте, хотя это уже не так.

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

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

Одно пропущенное обновление не так страшно. Цепочка пропущенных обновлений создает отдельный продукт.

Как доступ к поддержке и сроки патчей режут прибыль

В сделках с размещением у клиента поддержка быстро становится дорогой, если ваша команда не может добраться до системы в момент возникновения проблемы. Чаще всего дело даже не в самом исправлении. Задержка начинается раньше — когда инженеру нужны доступ по VPN, админские права, jump box или одобрение клиента, которое может дать только один человек.

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

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

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

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

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

Вот так прибыль утекает уже после продажи. Один аккаунт начинает съедать часы, которых хватило бы на десять небольших аккаунтов, или на развитие продукта. Время реакции ухудшается для всех, а работа над roadmap замедляется.

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

Простая история про размещение у клиента

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

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

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

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

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

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

Вот как сделки с размещением у клиента теряют маржу после продажи. Сам продукт нормальный. Команда поддержки умеет работать. Но сделка превращается в беспорядок, потому что никто четко не отвечал за путь обновлений в тот момент, когда клиент сказал: «Мы будем размещать это у себя».

Как назначить ответственного за обновления

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

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

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

Лучше всего работает простая схема:

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

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

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

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

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

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

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

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

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

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

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

Именно здесь часто помогает внешнее техническое руководство. Fractional CTO может выстроить правила ответственности, определить доступ к поддержке и остановить расхождение версий, прежде чем оно станет нормальной операционной затратой.

Короткий чек-лист перед подписанием или продлением

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

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

Используйте этот список перед новой сделкой или продлением:

• Назначьте одного человека с вашей стороны и одного со стороны клиента, кто может утверждать обновления.
• Пропишите, как поддержка получает доступ во время инцидента, кто его выдает и как быстро он должен быть доступен.
• Установите реальный срок для патчей безопасности. «Как можно скорее» — слишком расплывчато.
• Решите, что происходит после пропущенного релиза, включая возможность перескакивать через несколько версий.
• Отделите обычные обновления от дополнительной работы, такой как backport, срочная ручная помощь или исправления совместимости.

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

Полезное правило простое: если человек вне проекта не может ответить на вопросы «кто утверждает, кто получает доступ, как быстро мы патчим и кто платит за исключения», значит сделка все еще слишком рыхлая. Исправьте это до подписания.

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

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

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

Зафиксируйте правила, пока сделка еще свежая. Держите их короткими. Одной страницы часто достаточно, если она отвечает на вопросы, из-за которых люди потом спорят: кто отвечает за обновления, кто дает доступ к поддержке, как быстро должны приходить патчи и кто утверждает исключения.

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

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

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

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