Пилот прошёл успешно: как подготовить решение о покупке
Пилотом в B2B-продаже называют ограниченную по сроку и объёму проверку решения на выбранных задачах заказчика. Поставщик и заказчик согласуют сценарии, участников и критерии результата: например, проверяют совместимость продукта с инфраструктурой и выполнение конкретной рабочей операции. Полученные данные помогают решить, стоит ли закупать и внедрять решение и на каких условиях.
Демонстрация знакомит с возможностями продукта, а пилот проверяет их применимость в условиях, значимых для конкретного заказчика. От полноценного внедрения он отличается ограниченным масштабом и задачей проверки: положительный результат ещё не означает запуска во всей организации. Пилот может быть платным или бесплатным и сам по себе не обязывает заказчика к покупке; коммерческие условия стороны согласуют отдельно.
Пилот завершён. Инженеры заказчика подтвердили, что решение работает, команда поставщика подготовила отчёт, критических замечаний нет. Продавец ожидает обсуждения договора. Вместо этого заказчик предлагает вернуться к вопросу позже: бюджет ещё предстоит защитить, руководитель занят другим проектом, закупка требует дополнительных материалов.
Технический результат получен, но решение о покупке осталось неподготовленным. В сложной B2B-продаже это два разных результата работы. Паспорт пилота помогает заранее связать их: определить, что проверяет команда, кто принимает результаты и какое решение заказчик сможет принять после испытаний.
Материал адресован руководителям продаж, пресейла и внедрения технологических компаний. Наблюдения обобщены и обезличены. Ситуации ниже реконструируют управленческие механизмы; все числа в учебном примере условные и не описывают результаты конкретного клиента.
Два результата одного пилота
У технической команды есть понятная задача: проверить совместимость, функциональность, устойчивость и ограничения продукта в согласованной среде. Она отвечает на вопрос: «Сможем ли мы применять это решение в наших условиях?»
У людей, которые согласуют расходы, возникает другой набор вопросов. Какую задачу организации решит покупка? Почему её нужно решать сейчас? Какие затраты потребуются помимо лицензии? Кто обеспечит внедрение? Какие альтернативы рассмотрены? Что произойдёт, если отложить проект?
Успешное испытание помогает ответить на эти вопросы, если команда заранее определила, какие наблюдения ей нужны. Например, запись действий пользователя подтверждает работу функции аудита. Измерение времени поиска нужного события показывает изменение конкретной операции. Решение о бюджете дополнительно требует оценки масштаба применения, стоимости внедрения и приоритета задачи для заказчика.
До запуска полезно записать два ожидаемых результата. Технический: какие сценарии заказчик проверит и по каким условиям примет их. Коммерческий: какое решение он рассмотрит после проверки, кто участвует в согласовании и какой материал нужен каждому участнику. Обещания купить заранее не требуется. Нужен понятный порядок рассмотрения результатов.
Три ситуации, которые стоит предусмотреть
1. Инженер согласен, руководитель ещё не включился
Поставщик проверяет решение для управления доступом к корпоративным системам. Специалист заказчика успешно проходит сценарии подключения и аудита. Итоговый протокол содержит скриншоты и перечень работающих функций. На встрече с руководителем выясняется, что документ не объясняет, какую текущую проблему устраняет проект и какие ресурсы понадобятся для его эксплуатации.
При подготовке пилота продавцу стоило согласовать с владельцем задачи короткую записку: исходная ситуация, последствия, проверяемое изменение, предполагаемый масштаб внедрения и порядок оценки затрат. Тогда технический отчёт стал бы приложением к подготовленному решению. Пресейл предоставляет измерения и ограничения, продавец вместе с заказчиком собирает обоснование, руководитель заказчика оценивает приоритет.
2. Заказчик не выполняет свою часть испытаний
Стенд развёрнут, инженер поставщика готов продолжать, но заказчик не предоставил тестовые учётные записи или время администратора. В календаре пилот идёт третью неделю, фактически команда почти не проверила сценарии. Продавец просит инженера оставаться на связи, потому что клиент важный.
Здесь нужен заранее согласованный порядок паузы. Например: если обязательный ресурс заказчика недоступен к контрольной дате, стороны фиксируют невыполненное условие, освобождают зарезервированные часы и назначают дату возвращения к вопросу. Продление имеет конкретную цель, новую дату и согласованный объём работ. Простое течение времени не считается прогрессом пилота.
3. Опытный продавец договаривается, команда не видит механизма
Сильный продавец ещё до испытаний обсуждает бюджет, выясняет процедуру закупки и приглашает нужного руководителя на итоговую встречу. Коллеги видят удачный пилот и договор. Они воспроизводят демонстрацию и технические проверки, но получают другой результат: часть договорённостей осталась в личных разговорах опытного сотрудника.
Руководителю полезно разобрать последовательность действий на состоявшихся сделках: когда продавец выяснил источник финансирования, кто помог организовать обсуждение, какие документы запросила закупка, что изменило решение клиента. Эти действия можно включить в паспорт и разборы сделок. Высокая личная конверсия сама по себе ещё не показывает, что команда умеет повторять этот способ работы.
Что согласовать до выделения инженерных часов
Пилот имеет смысл запускать, когда у него есть конкретный вопрос, который нельзя достаточно надёжно закрыть демонстрацией, документацией или референсным визитом. Если заказчик хочет познакомиться с интерфейсом, начать можно с показа. Если нужно проверить работу в его среде, потребуются испытания.
Минимальная договорённость перед стартом охватывает сценарий, среду, участников, ресурсы обеих сторон, способ проверки и дату итогового обсуждения. Степень подготовки коммерческой части зависит от стадии сделки. Иногда пилот нужен для формирования требований или сравнения архитектур, а бюджет ещё не выделен. Такой запуск допустим, если команда понимает цель и ограничивает вложения.
Отдельно следует согласовать цену и условия самого пилота. Бесплатный формат не освобождает заказчика от предоставления людей, среды и обратной связи. Платный формат тоже не гарантирует дальнейшую закупку. В обоих случаях стороны договариваются, какие работы входят в проверку, как принимают результат и что делают после завершения.
Паспорт пилота: рабочий шаблон
Паспорт заполняют продавец, технический руководитель пилота и представители заказчика. Он может быть документом или набором связанных полей CRM. Важнее, чтобы участники работали с одной актуальной версией и явно подтверждали договорённости.
Скачать заполняемый паспорт пилота
| Раздел | Что записать |
|---|---|
| Задача и решение | Какую ситуацию хочет изменить заказчик? Какое решение он намерен рассмотреть после пилота: выбрать архитектуру, включить проект в бюджет, начать закупку или отказаться? |
| Исходное состояние | Как процесс работает сейчас? Источник данных, период наблюдения, объём операций, ограничения. Что известно, а что ещё нужно измерить? |
| Границы | Системы, площадки, пользователи, сценарии и нагрузка. Что входит в проверку и что остаётся за её пределами? |
| Участники | Владелец задачи, технический ответственный, участник согласования бюджета и контакт закупки со стороны заказчика. Продавец, инженер и партнёр со стороны поставки. Для каждой роли — действие и выход. |
| Критерии приёмки | По каждому сценарию: условие, порог, метод измерения, источник результата и человек, который его принимает. Раздельно техническая проверка и оценка полезности. |
| Ресурсы и обязательства | Что и к какой дате предоставляет каждая сторона: доступы, тестовые данные, лицензии, часы специалистов, инфраструктуру. Кто снимает блокировку? |
| Стоимость и ограничения | Условия пилота, предел инженерных часов, известные расходы будущего внедрения. Требования к тестовым данным и доступам, порядок завершения и удаления временных ресурсов. |
| Сроки и контроль | Дата готовности среды, начало испытаний, промежуточная проверка и итоговая встреча. Кто и когда принимает решение о паузе, продлении или остановке? |
| Обоснование покупки | Какие измерения помогут оценить эффект? Какие допущения проверяет заказчик? Полная стоимость, альтернативы, источник финансирования или порядок его определения. |
| Итог и следующий шаг | Результат каждого сценария, ограничения переноса на весь контур, решение заказчика. Следующее действие, ответственный, дата и ожидаемый документ или событие. |
Если бюджетный участник пока не установлен, так и запишите. Назначьте действие, которое поможет его определить, и ограничьте масштаб проверки. Пустое поле показывает неизвестное условие сделки; формальная фамилия без договорённости его не устраняет.
Как заполнить паспорт на конкретном сценарии
Рассмотрим учебный пример. Заказчик хочет сократить трудоёмкость подготовки отчёта о доступе внешних специалистов. Сейчас администратор вручную собирает сведения из нескольких систем. Поставщик предлагает проверить автоматизированный сбор данных в двух тестовых системах. Все объёмы, сроки и пороги ниже выбраны для объяснения метода.
Вопрос пилота. Может ли команда формировать полный отчёт по согласованному набору операций быстрее текущего способа, сохранив необходимые сведения? После испытаний руководитель заказчика рассмотрит целесообразность внедрения в более широком контуре.
Исходное состояние. Администратор измеряет время выполнения пяти сопоставимых заданий текущим способом. Команда фиксирует состав операций, полноту отчёта и медианное время. Допустим, в примере оно составило 40 минут на задание. Это измерение конкретной выборки, которую нельзя автоматически считать нормой для всей компании.
Границы. Две тестовые системы, десять тестовых учётных записей, три заранее описанных сценария доступа. Производственный контур, отказоустойчивость и нагрузочные испытания в эту проверку не входят. Технический ответственный заказчика принимает результаты; продавец отвечает за подготовку итогового обсуждения.
Критерии. В каждом сценарии отчёт содержит все заранее перечисленные обязательные поля. Команда выполняет пять сопоставимых заданий новым способом и измеряет время тем же методом. Условный ориентир — медиана не более 10 минут при сохранении полноты. Если полнота не достигнута, сокращение времени отдельно не означает успеха.
Ресурсы и срок. В примере стороны выделяют десять рабочих дней и до 24 инженерных часов поставщика. Заказчик предоставляет среду и администратора к началу проверки. На пятый день стороны оценивают выполненные сценарии и препятствия. Эти величины — условия примера; для реального пилота их определяют по сложности проверки.
Продление. Дополнительная неделя допустима для конкретного незавершённого сценария, если среда готова, причина задержки понятна и стороны согласовали новые часы. При отсутствии необходимых ресурсов команда ставит работу на паузу и фиксирует условия возобновления.
Итоговая встреча. Участвуют технический ответственный, владелец задачи и руководитель, согласующий расходы. Они получают протокол испытаний и записку с исходным состоянием, результатом, ограничениями и оценкой стоимости следующего этапа. Положительный итог пилота даёт основание рассмотреть внедрение, но не заменяет это решение.
Как посчитать полезность без обещания вымышленной экономии
Продолжим условный пример. Если заказчик подтвердит, что ежемесячно выполняет 20 сопоставимых заданий, разница между 40 и 10 минутами даёт 600 минут, или 10 часов потенциально высвобождаемого времени в месяц: (40 − 10) × 20 / 60.
Это оценка трудоёмкости для выбранной операции. Чтобы перенести её на рабочий контур, заказчик проверяет сопоставимость заданий, стабильность результата и дополнительные действия: обслуживание системы, обработку исключений, контроль отчётов. Пилот на двух системах не устанавливает результат на всех остальных.
Даже подтверждённые десять часов не равны сокращению денежных расходов. Люди могут использовать время на другую работу при прежнем фонде оплаты труда. Для денежной оценки нужно отдельно согласовать стоимость часа и механизм получения выгоды: например, сокращение сверхурочных или отказ от дополнительного найма. Расходы на лицензии, внедрение, инфраструктуру, обучение и сопровождение учитываются отдельно.
Для проектов безопасности полезность может включать контролируемость доступа, полноту аудита и соблюдение принятого порядка работы. Необязательно выражать каждое изменение в рублях. Снижение вероятности инцидента нельзя рассчитать по одному успешному испытанию без данных о риске и согласованной модели. В обосновании стоит показать измеренное изменение, допущения и то, что ещё предстоит проверить.
Как завершать пилот
На итоговой встрече стороны отдельно фиксируют технический результат и решение о дальнейшей работе. Продукт может пройти испытания, а закупка — остаться без бюджета. Он может не пройти важный сценарий, хотя потребность заказчика сохранится. Эти исходы требуют разных следующих действий.
Для управления достаточно явно описать принятое решение: переход к согласованию закупки; ограниченная дополнительная проверка с новым вопросом и сроком; пауза до указанного события; отказ с зафиксированной причиной. Формулировка «клиент думает» не объясняет, кто должен что сделать.
В CRM продавец сохраняет ссылку на паспорт и протокол, результат сценариев, принятое заказчиком решение, причину паузы или отказа и следующий шаг. Технический руководитель подтверждает завершение работ и освобождение ресурсов. Если в пилоте участвует интегратор, стороны заранее определяют, кто получает итоговую обратную связь от заказчика и передаёт её остальным.
Что руководителю смотреть на разборе пилотов
Начать можно с нескольких завершённых и нескольких зависших проверок. Сопоставьте первоначальный вопрос, вложенные часы, технический итог и коммерческое решение. Выясните, на каком переходе возникла остановка: подготовка среды, испытания, принятие результата, согласование бюджета или закупка.
Полезны длительность активной работы и ожидания по отдельности, инженерные часы, доля пилотов с зафиксированным решением, причины продления и переход к закупке. Для конверсии заранее определите, какие пилоты входят в расчёт и какой срок наблюдения считаете достаточным. Незавершённые свежие пилоты нельзя механически считать проигранными. Сравнение продавцов также требует учёта продуктов, клиентов и сложности сделок.
Паспорт стоит проверить на ближайших реальных сделках и убрать поля, которые никто не использует для решения. Его ценность видна в работе: участники понимают вопрос испытаний, заказчик предоставляет ресурсы, команда вовремя завершает проверку, а результат доходит до людей, принимающих решение о покупке.
На следующем разборе действующего пилота задайте один вопрос: какое решение заказчик сможет принять по его результатам и кто поможет подготовить это решение? Если ответа пока нет, начните с этой договорённости.