Повторяемое предложение после пилота: что исправить в первую очередь

Почему успешный пилот не масштабируется

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

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

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

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

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

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

Что теряется после пилота

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

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

Что на самом деле доказал пилот

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

Если стартап нанял вас, чтобы ускорить релизы, доказательством будет не «мы тесно работали с командой», а «они стали выпускать через два дня вместо двух недель». Если пилот касался AI‑автоматизации, доказательством может быть «первичный черновик ответа на тикет приходит за 30 секунд». Делайте формулировки конкретными.

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

Простой фильтр помогает. Задайте четыре вопроса:

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

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

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

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

Уберите разовую работу

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

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

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

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

Делайте базовое предложение скучным

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

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

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

Если ваше предложение всё ещё требует подвигов от одного человека — оно не готово к копированию.

Запишите предположения на бумаге

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

Если вы хотите повторяемое предложение, выпишите операционные предположения до начала работ. Поместите их в предложение, statement of work или стартовую заметку. Если они остаются в голове у кого‑то, продажи пообещают одно, а доставка обнаружит другое.

Начните с входных данных, которые вам нужны в первый день. Точно укажите, что клиент должен предоставить: доступ к системе, образцы данных, согласование по безопасности и одного человека, который отвечает на бизнес‑вопросы. Если работа связана с настройкой AI‑разработки или новой инфраструктуры, вам также могут понадобиться доступ к репозиториям, облачные учётные данные и назначенный владелец внутренних инструментов.

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

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

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

Это может казаться строгим на бумаге. На практике это обычно делает проект спокойнее. Чёткие предположения убирают неловкие споры позже и защищают обе стороны от ложной срочности и тихого раздувания объёма.

Исправьте ценообразование до второй продажи

Большинство пилотных прайсов ломаются по простой причине: в смете отражается надежда, а в реальности — трудозатраты.

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

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

Работа по настройке — это где многие теряют деньги в первую очередь. Ранние сделки часто объединяют discovery, конфигурацию, обучение и очистку в один платёж. Это скрывает реальную стоимость ввода клиента в строй. Если первый клиент требовал 25 часов на настройку и только шесть часов в месяц после этого, в прайсе это должно быть показано отдельно.

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

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

Назначьте цену за срочные работы, дополнительные правки и поддержку сверх согласованного объёма. Даже простое правило помогает. Один раунд правок входит. Дополнительные раунды — платные.

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

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

Короткий обзор помогает:

• Что мы посчитали, и сколько реально стоила доставка?
• Какие часы случились один раз, а какие будут повторяться ежемесячно?
• Какие мелкие услуги превратились в регулярную работу?
• Какая маржа остаётся после прямых расходов и поддержки?

Если ответы размыты — цена не готова.

Сбросьте предложение

Начинайте с беспорядка, а не с презентации. Пилот оставляет подсказки везде: в предложении, тикетах поддержки, заметках встреч, Slack‑потоках, запросах на изменения и счётах. Соберите их в одном месте, чтобы увидеть, что купил клиент, что он просил позже и что ваша команда отдала бесплатно.

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

Полезный процесс сброса выглядит так:

1. Соберите исходные материалы и отметьте каждый запрос, который появился после закрытия сделки.
2. Перечислите каждый шаг доставки, кто его делал, сколько времени заняло и где команда застревала.
3. Вычеркните работу, которая существовала только потому, что у этого клиента была необычная система, дедлайн или политический контекст.
4. Превратите оставшуюся работу в черновое предложение с ясным объёмом, сроками, ценой и исключениями.
5. Попросите одного коллегу атаковать черновик до того, как продажи снова начнут его использовать.

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

Выберите рецензента, который был достаточно близок, чтобы знать, что происходило, но не настолько близок, чтобы защищать каждое решение. Задавайте резкие вопросы. Поймёт ли новый клиент, что входит в услугу? Что мы сделали один раз и больше никогда не должны делать? Где продажи будут обещать лишнего?

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

Реалистичный пример

SaaS‑стартап нанимает Oleg на короткий пилот, чтобы улучшить процесс AI‑разработки. Команда уже использует AI‑инструменты ежедневно, но результаты непостоянны. Некоторые pull request получают тщательный ревью, некоторые — нет. Тесты работают по‑разному в разных репозиториях. Разработчики переключаются между моделями без ясных правил, поэтому расходы и качество выходов колеблются сильнее, чем основатели ожидали.

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

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

Если продажи скопируют пилот как есть, прайс ломается на второй сделке. У одной компании может потребоваться два дня на очистку, у другой — три недели.

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

Всё остальное выносится и оценивается отдельно. Очистка данных становится отдельным пакетом. Настройка инструментов — платой за внедрение или отдельным проектом. Кастомные хуки, изменения CI или правила маршрутизации моделей получают собственную оценку.

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

Ошибки команд при второй продаже

Вторая сделка часто ломается потому, что команда рассматривает пилот как шаблон, а не как тест.

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

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

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

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

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

Так хороший пилот превращается в грязный сервисный бизнес. Название предложения остаётся тем же, а работа — нет.

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

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

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

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

Используйте короткую предпродажную проверку до того, как кто‑то снова предложит тот же пакет:

• Команда может объяснить предложение в одном предложении без добавления исключений.
• Первый шаг, последний шаг и точка передачи записаны.
• Базовая цена всё ещё работает, если клиент отвечает немного медленнее или задаёт нормальные уточняющие вопросы.
• Смета отделяет стандартную работу от допов: legacy‑системы, срочная доставка или дополнительное обучение.
• Новый сотрудник может прочитать документы и выполнить ту же работу с минимальной помощью.

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

Это часто встречается в консультировании и работе CTO. Если Oleg помогает стартапу выстроить AI‑ориентированный процесс разработки, базовое предложение должно точно указывать объём, нормальную поддержку и конечное состояние. Кастомные интеграции MCP, необычные проверки безопасности и обучение основателя для большой команды должны быть вне базовой цены.

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

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

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

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

Короткий чек‑лист достаточен:

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

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

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

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