Помощь внешнего CTO для продаж: говорите нет, не теряя сделки

Почему запросы превращаются в плохие обещания

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

Для звонка это работает. Через неделю все часто разваливается.

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

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

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

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

Такой сценарий встречается часто:

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

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

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

За что должен отвечать внешний CTO

Эта работа не про то, чтобы быть на каждом звонке с продажами. Она про то, чтобы дать команде надежный способ отвечать на сложные запросы.

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

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

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

Хорошо работает простое распределение ролей:

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

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

Есть еще одна важная обязанность: держать всех на одном ответе. Если продажи говорят покупателю одно, продукт намекает на другое, а потом инженеры сужают объем работ, доверие быстро падает. Хороший fractional CTO формирует одну общую позицию, которую команда может повторять в звонках, предложениях и follow-up сообщениях.

Пятишаговая проверка для необычных запросов

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

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

1. Запишите запрос одним простым предложением. Используйте конкретные слова, а не сокращения. «Клиент хочет SSO с Okta для 150 сотрудников до подписания» — это понятно. «Им нужна enterprise auth» — нет.
2. Спросите, кому это нужно и почему именно сейчас. Это идет от безопасности, закупок, юристов или от одного человека в команде покупателя? Многие запросы кажутся обязательными, пока не выясняется, что это просто предпочтения или хвост от старого инструмента.
3. Проверьте трудозатраты на разработку, стоимость поддержки и влияние на безопасность. Запрос, который делается за два дня, все равно может стать дорогим, если команде придется поддерживать его годами.
4. Выберите один путь. Большинство запросов попадают в одну из четырех корзин: стандартное предложение, платное исключение, возможное будущее соответствие или уверенное «нет». «Будущее соответствие» работает только если вы не называете дату, пока инженерная команда уже не согласовала ее.
5. Отправьте один ответ с объемом и ограничениями. Сформулируйте решение в одном сообщении. Скажите, что вы сделаете, чего не сделаете, сколько это стоит, если это дополнительная работа, и какие условия действуют.

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

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

Кастомные функции: продукт, платный проект или отказ

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

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

Начните с двух проверок. Возникал ли этот запрос раньше и готовы ли за него платить другие аккаунты? Если на оба вопроса ответ «нет», считайте это работой под конкретного клиента, а не работой для roadmap.

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

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

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

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

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

Требования к хостингу: обязательство или предпочтение?

Когда покупатель просит приватный хостинг, установку on-prem или «только наш cloud», продажи должны сделать паузу и сначала задать один вопрос: это реальное требование или просто предпочтение?

Ответ меняет все.

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

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

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

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

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

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

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

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

Обещания по roadmap: обещайте проверку, а не поставку

Разговоры о roadmap идут не туда, когда продажи превращают интерес в обязательство. Безопасное правило простое: продажи могут обещать проверку, но не поставку.

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

Диапазоны времени безопаснее точных дат, даже после проверки. Фраза вроде «самое раннее реалистичное окно — 6–8 недель, если финальный объем не изменится» дает покупателю что-то полезное, не делая вид, что работа уже забронирована.

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

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

Фразы, которые может использовать sales

Короткий скрипт помогает лучше, чем длинная политика:

• «Мы можем обсудить этот запрос с инженерной командой, но сегодня я не могу включить его в roadmap как обязательство».
• «Если команда одобрит это, я вернусь к вам с диапазоном сроков, а не с фиксированной датой».
• «Мы понимаем сценарий использования, но сейчас это не запланировано».
• «Это не совпадает с текущим планом продукта. При необходимости можем обсудить обходной вариант или отдельную платную работу».

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

Как выглядит реалистичная проверка сделки

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

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

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

В быстрой проверке разделение может выглядеть так:

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

Это меняет ответ sales. Вместо безусловного «да» команда предлагает поэтапный план. Первый этап покрывает основной продукт и реалистичные сроки по SSO. Второй этап — приватный хостинг после технического разбора и отдельного коммерческого соглашения. Третий этап — отчеты, если они все еще нужны после онбординга.

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

Ошибки, которые бьют по доверию и марже

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

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

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

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

Скрытые затраты редко остаются скрытыми надолго:

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

Есть и ловушка roadmap. Громкий потенциальный клиент может сделать нишевый запрос срочным на слух. Перед тем как менять направление, задайте простой вопрос: сколько текущих клиентов будут использовать это в ближайшие шесть месяцев? Если ответ — «один, может быть два», считайте это кастомной работой, а не продуктовой стратегией.

Запросы по хостингу тоже постоянно недооценивают. Команды воспринимают хостинг как галочку: single-tenant, особый регион, частная сеть, on-prem. Ничто из этого не является простым после подписания договора. Это меняет мониторинг, бэкапы, безопасность, реагирование на инциденты и то, кого будят в два часа ночи.

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

Быстрые проверки перед ответом sales

Быстрый ответ кажется хорошей идеей, но небрежный ответ обходится дороже, чем медленный. Sales стоит сделать паузу и пройти короткий чек-лист, прежде чем говорить «да», «нет» или «возможно».

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

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

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

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

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

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

Sales не должен отвечать по памяти или из оптимизма.

Лучший ответ конкретен: команда может проверить схему хостинга, оценить экспорт как платную кастомную работу и обсудить направление roadmap без обещания дат поставки. Это сохраняет сделку и удерживает маржу.

Как встроить это в процесс продаж

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

Несколько ситуаций должны всегда запускать техническую проверку:

• Кастомная функция меняет базовое поведение продукта.
• Покупатель просит хостинг вне стандартной схемы.
• Сделка зависит от даты в roadmap или названного milestone.
• Интеграция может увеличить нагрузку на поддержку или риск простоев.

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

Шаблоны ответов тоже помогают. Напишите несколько простых формулировок для запросов, которые команда слышит каждую неделю: кастомная работа, исключения по хостингу, проверка безопасности и вопросы по roadmap. Язык должен быть простым. Обещайте проверку, объясняйте следующий шаг и не называйте даты поставки, пока не подпишется кто-то технический.

В небольших компаниях часто нет CTO на каждой серьезной сделке. Вот где поддержка fractional CTO может реально помочь. Если вашей команде нужна внешняя помощь, Oleg Sotnikov на oleg.is консультирует стартапы и SMB по архитектуре продукта, инфраструктуре и AI-first разработке программного обеспечения. Такая поддержка особенно полезна, когда объем становится необычным, требования по хостингу начинают менять операционные процессы или условия договора начинают влиять на сам продукт.

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

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