Александр Мармузевич

ex-CTO InData Labs

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

Рассказывает ex-CTO InData Labs Александр Мармузевич. 

Эксперт обладает более чем 30-летним опытом в ИТ. В его копилке — разнообразные проекты: от разработки аппаратного обеспечения для компьютерной телефонии и собственных продуктов в металлургии до сервисов в области data science.

Обратите внимание на другие статьи по теме:

Чек-лист для сейлз-менеджера по подготовке к переговорам
Как продавать на рынке США в узкой нише на $500k+ в год. Кейс Ant Robotics на примере HardTech-продукта
Как IT компаниям зайти к мидсайз и энтерпрайз клиентам, продав Discovery Phase. Примеры кейсов
Как наладить поток клиентов и делать 100+ сайтов в год командой в 15 человек. Кейс веб-студии TravelLine

В статье прочитаете: 

• Что нужно для эффективного общения между командой и клиентом?
• Как распределяются роли во время митинга?
• Как элегантно заложить основы быстро продажи экспертизвы вашей ИТ компании
• Инструменты и советы, которые пригодятся техническому специалисту, чтобы быстро показать решение потенциальному клиенту
• Шпаргалка по рассчету цикла сделки-продажи

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

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

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

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

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

Затем, по окончании созвона, привести несколько примеров аналогичных решений. Важно сделать это в течение этого же дня (или завтра).

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

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

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

Что нужно для эффективного общения между командой и клиентом?

Заранее подготовьтесь и соберите материалы, которые соответствуют “болям” клиента. 

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

В целом ключевую роль тут играют несколько факторов:

1. Разведка. Проведите тщательный анализ компании. К вам пришел стартап с одним сотрудником, азиатская компания или крупная организация? Продавать услуги придется долго. RFP тоже всегда предполагает длительные сроки.
2. Формулировка запроса. Здесь нужен опыт сейлза, включающий знание подобных ситуаций и компаний, а также понимание, кто пишет запрос и кто принимает решение.
3. Опыт технического специалиста. Он должен уметь работать с подобными запросами с технической точки зрения и быстро идентифицировать проблемы клиента.
4. Готовые решения. Если компания ранее уже выполняла подобные проекты и маркетинговые данные это подтверждают, то стоит заранее подготовить демо-материалы и всегда иметь их под рукой. Это минимизирует затраты времени и повышает шансы на успех.

Как распределяются роли во время митинга?

Продавец.

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

Технический специалист.

Внимательно слушает потенциального клиента.

Лучше задавать минимум уточняющих вопросов.

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

В случае Generic Development это часто срабатываетв плюс. 

С проектами в области Data Science всё сложнее.

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

И только потом задавать вопросы. А затем и предложить соответвующее решение. 

Так как продавать быстро? 

Я вывел для себя алгоритм такой алгоритм действий.

Что нужно, чтобы быстро показать решение потенциальному клиенту 

Разновидность демонстрации решения — “начинаем рисовать диаграммы”. 

В офлайн-формате это можно делать на доске или планшете, а в онлайн — с помощью инструментов, таких как draw.io, Miro или Whiteboard. 

Рисовать нужно быстро и не обязательно слишком точно — главное, показать ключевые моменты.

Быстрое прототипирование на ChatGPT подходит для задач в области Data Science, особенно связанных с обработкой языка. 

Быстрое прототипирование с помощью Jupyter Notebook или Google Colab эффективно для различных задач Data Science  в области computer vision, NLP, задачи обработки табличных данных. 

Ключевое замечание: не стремитесь сделать что-то идеально — показывайте максимально быстрый результат в течение 5-10 минут без ожиданий. 

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

Совет по Generic Development: Визуалы (диаграммы, мокапы, интерактивные прототипы) — в идеале их следует создавать непосредственно в процессе общения, что производит сильное впечатление на заказчика.

Совет по Data Engineering: Диаграммы, BI dashboard. Идеальная схема — взять какие-то данные у заказчика (или просто открыть Excel, добавить пару строк), запустить обработку и показать изменения на BI-решении.

Совет по Data Science: Jupyter/Colab — быстро набросать ноутбук с графическими элементами (графиками, результатами распознавания, сегментации, детектирования и анализа данных). ChatGPT-подобные решения позволяют быстро проработать сценарий работы системы.

Кроме того, отлично работают решения, уже размещённые на сайте компании. 

Например, в случае InData Labs хорошо демонстрировал принципы использования ИИ для поиска нужной информации на сайте, созданный компанией чат-бот Аврора.

Шпаргалка по рассчету цикла сделки-продажи 

Обычная продажа (не RFP):

• первый созвон (IC)
• подготовка предложения – 3 – 5 дней (PP)
• второй созвон (защита решения) (SC)
• пауза на обдумывание – 3 – 5 дней (DP)
• третий созвон (принятие решений) (FC)
• подписание договора – зависит от компании и юристов (3-15 дней)
• старт работ

Длительность (от начала первого созвона до подписания договора): 

•  IC (1) + PP (3-5) + SC (1) + DP (3-5) + FC (1) = 9 -13 дней

Трудоёмкость:

• Команда продаж – 6-18 часов
• Тех команда (подготовка предложения) – 8-24 часа

Что хорошо:

• Не нужна жёсткая фокусировка компании
• Можно пробовать что-то новое (увеличивая время на подготовку предложения с 3-5 до 5-7 дней

Что плохо:

• Длительность (2-3 недели)
• Сложно удерживать знания о пресейле (всё забывается)
• Впечатления клиента об экспертизе вашей компании начинают забываться

Swift продажа

• первый созвон (IC)
• письмо-follow-up с ценой (FU)
• пауза на обдумывание – 1-2 дня (DP)
• подписание договора – зависит от компании и юристов (3-15 дней)
• старт работ

Длительность (от начала первого созвона до подписания договора): 

•  IC + FU (1) + DP (1-2) = 2-3 дня

Трудоёмкость:

• Команда продаж – 2-3 часа
• Тех команда – 2-3 часа (подготовку решений/инструментов исключаем из затрат на пресейлы)

Что хорошо:

• Длительность (2-3 дня)
• Быстрое принятие решения и реаллокация пресейловых ресурсов
• Не во всех случаях, но может быть автоматизировано (кастомизация при помощи решений, основанных на AI)

Что плохо:

• Нужна жёсткая фокусировка компании
• Не все пресейлы могут быть быстрыми
• Нужна тренировка команды
• Надо вкладываться в инструменты/решения, чтобы уметь что-то быстро демонстрировать (с другой стороны, это способ ре-утилизации бенча)