Продажи обещают кастомную работу: как CTO оценивает запросы

Почему это постоянно происходит

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

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

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

Engineering обычно получает детали слишком поздно. К тому моменту, когда запрос доходит до них, он уже превратился почти в обязательство, а не в вопрос. Это меняет разговор. У инженеров уже не спрашивают: «Стоит ли это делать?» Им говорят: «Как быстро вы сможете это сделать?»

Небольшой пример хорошо показывает схему. Потенциальный клиент просит «кастомный шаг согласования» перед тем, как заказы будут проходить дальше. Sales слышит чекбокс. Product слышит вариант workflow. Позже engineering обнаруживает логику ролей, audit logs, уведомления, обработку исключений, тестирование и документацию для поддержки. То, что звучало как маленькая правка, на деле оказывается настоящим проектом.

Глубже проблема в том, кто за что отвечает. Sales отвечает за отношения, product — за дорожную карту, engineering — за delivery, finance — за маржу, а support потом разбирается с последствиями. Когда права на решение размазаны между пятью людьми, по умолчанию получается мягкое «да».

Именно поэтому один и тот же конфликт повторяется снова и снова. В компании нет понятного владельца, который мог бы превратить размытый запрос в бизнес-решение с scope, стоимостью, сроками и компромиссами. Эту роль часто берёт на себя CTO. Её может взять и fractional CTO. Задача не в том, чтобы убивать сделки. Задача в том, чтобы остановить желаемое за действительное до того, как оно превратится в срок, который никто не сможет защитить.

Что на самом деле делает техническое «нет»

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

Звучит просто, но это меняет всё. Клиент может просить кастомный workflow, специальный отчёт или копию того, как работала их старая система. Хороший CTO не отвечает прямым «нет», если идея действительно имеет смысл. Он переводит запрос в такие варианты, которые компания сможет собрать, поддерживать и оценить без сожаления.

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

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

Вот что на самом деле делает техническое «нет». Оно превращает «Вы можете это сделать?» в «Какой вариант вам нужен и сколько вы готовы за него заплатить?»

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

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

Если у компании нет постоянного CTO, с этим так же хорошо может справиться fractional CTO. Sales получает безопасный ответ, delivery — понятный scope, а размытые обещания перестают превращаться в дорогие сюрпризы.

Какие вопросы задать, прежде чем говорить «да»

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

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

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

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

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

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

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

Как CTO превращает размытый запрос в варианты

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

Одно это предложение важнее, чем кажется. Оно заставляет sales, product и engineering сначала согласовать результат, а уже потом говорить о датах и цене. На этом этапе догадки заканчиваются.

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

Хорошая проверка смотрит не только на саму фичу. Это новый код, небольшое изменение или просто настройка? Нужны ли дополнительные серверы, мониторинг, правила безопасности или настройка доступа? Кто будет обучать клиента, отвечать на тикеты и поддерживать это потом? Нужно ли менять договорные условия из-за обещаний по uptime, правил по данным или кастомной поддержки?

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

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

Fractional CTO часто может сделать это за одну рабочую сессию вместе с sales и engineering. Результат простой: меньше неожиданных разработок, чище коммерческие предложения и выбор, который компания сможет защитить, если клиент начнёт спорить.

Реалистичный пример со звонка sales

Клиент уже почти готов подписать договор. Во время финального звонка он просит специальный процесс согласования, чтобы заказы на сумму выше $10,000 требовали подтверждения менеджера перед отправкой. Account executive слышит крупный контракт и говорит: «Да, мы можем это сделать».

На поверхности это звучит как один дополнительный экран и одна кнопка. На деле — почти никогда.

CTO подключается к следующему звонку и задаёт несколько простых вопросов. Кто может одобрять? Меняются ли правила в зависимости от отдела? Нужны ли комментарии к отклонённым запросам? Нужен ли покупателю полный audit log? Что происходит, если согласующий недоступен?

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

На этом этапе CTO может превратить запрос в два варианта.

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

Такой вариант может занять две-три недели с тестированием. Его легче объяснить по цене, нагрузка на поддержку остаётся ниже, и sales может сказать честно: «Это закрывает ваш текущий процесс, но не все исключения».

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

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

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

Как честно оценивать варианты

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

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

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

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

Также полезно отдельно отметить, что команда сможет использовать потом. Отдельная CSV-выгрузка для одного клиента может помочь одной сделке и больше никогда не понадобиться. А вот более качественная история audit или более сильные настройки ролей могут пригодиться и будущим клиентам. В таком случае компания может разделить стоимость между бюджетом продукта и бюджетом сделки, а не списывать всё на одного клиента.

И ещё одна строка должна быть в каждой оценке: что сдвинется, если этот запрос встанет в приоритет. Если команда возьмёт эту работу сейчас, нужно сказать, что отодвинется назад. Может быть, исправление onboarding выйдет на две недели позже. Может быть, релиз для mobile перенесут на следующий месяц. CTO здесь нужен для того, чтобы превратить «конечно, мы можем» в оплачиваемый выбор с компромиссами, которые видны всем.

Ошибки, из-за которых кастомная работа превращается в хаос

Хаос обычно начинается ещё до того, как кто-то пишет тикет. Звонок sales проходит хорошо, покупатель просит что-то «небольшое», и команда оценивает идею по демо, которое только что показала. Это рискованно. Демо показывает счастливый путь. Реальный workflow включает старые данные, права доступа, отчётность, передачу задач и поддержку после запуска.

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

Ещё одна частая ошибка — прятать неопределённость, потому что красивая цифра легче продаётся. Лучше сказать: «Вариант A, скорее всего, займёт две-три недели. Для варианта B сначала нужна проработка», чем придумать точную цену, которую потом никто не сможет защитить. Покупатели нормально относятся к неопределённости, если вы объясняете, что именно на неё влияет. Они раздражаются, когда команда звучит уверенно, а потом промахивается и по бюджету, и по сроку.

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

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

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

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

Короткий чек-лист перед тем, как обещать delivery

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

• Запишите запрос одним простым предложением. Если команда не может объяснить его коротко, значит, она ещё не до конца его понимает.
• Спросите engineering, откуда берутся данные, куда они идут и какие интеграции изменятся. Большинство кастомных запросов становятся рискованными на стыках, а не в дизайне экрана.
• Запишите хотя бы два пути решения. Один может быть полноценной кастомной разработкой, а другой — более лёгким обходным вариантом с ограничениями.
• Разделите стоимость на разработку и постоянную поддержку. Фича, которая выходит за 30 часов, всё равно может создать месяцы последующей работы.
• Дайте sales короткий скрипт для звонка с клиентом, где объясняется, что входит, что не входит и что ещё нужно подтвердить.

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

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

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

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

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

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

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

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

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

Oleg Sotnikov на oleg.is делает именно такую работу со стартапами и небольшими компаниями как fractional CTO и advisor. Он проверяет рискованные сделки, помогает командам оценивать кастомные запросы и выстраивает практичные процессы delivery и инфраструктуры.

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