Продажа разработки: как получать доверие заказчика и проекты при большом цикле сделки

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

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

Продажу мы воспринимаем как часть проекта – первый его этап, когда за определенное время нужно прийти к намеченному результату. Для нас такое восприятие обусловлено стратегией развития компании: мы нацелены на долгосрочные контракты с LT от трех лет. Чем раньше начнем выстраивать партнерские отношения с клиентом, тем проще его выращивать – все на доверии.

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

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

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

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

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

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

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

Такой шаг мы делали, например, для Emex – анализировали их существующую систему, чтобы в дальнейшем заняться масштабной переработкой. У нас есть материал об этом проекте. За 5 недель мы провели подробный анализ и наметили курс улучшений для продукта.

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

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

Например, как-то к нам обратился один из крупнейших дистрибьюторов 1С в РФ. Запрос – создать большущий маркетплейс для бизнесов, которым необходим 1С – что-то вроде узкопрофильной фриланс-биржи. Мы начали копать и поняли, что маркетплейс ребятам делать рано – нужно сперва понять, будет ли такой продукт востребован и набрать клиентскую базу. Поэтому мы не стали сразу оценивать разработку и требовать денег. Вместо этого помогли заказчику запустить процесс проверки гипотезы. Прошло время, и сейчас заказчик к нам вернулся. Гипотеза подтвердилась, и теперь можно обсуждать маркетплейс.

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

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

Многие компании просто напоминают о себе, но находятся в пассивном режиме ожидания. Наш подход – проявить активность и здесь.

Вот пример. Сейчас мы делаем крупный сервис для заказчика, который в дальнейшем хочет растить свое ИТ-подразделение. Когда мы обсуждали, на каких технологиях будем делать фронтенд, ребята долго не могли определиться: React или Vue выбрать. Они рассуждали, отталкиваясь от того, на чем проще писать. Мы же предложили другой вариант: посмотреть, кого проще нанять.

Мы провели быстрое исследование рынка соискателей и поняли, что резюме на React процентов на 20% больше. Платят разработчикам React и Vue примерно одинаково, но вакансии на React закрываются быстрее. К тому же, на нем пишут в ряде крупных компаний из смежных отраслей – это значит, что можно будет нанимать с рынка специалистов с нужной отраслевой экспертизой. Через день после презентации этой информации заказчик выбрал нас как исполнителей и выбрал React для реализации фронтенда

На последнем этапе продаж, когда заказчик «готовенький», и уже кажется, что до контракта рукой подать, велик соблазн согласиться на то, что рискуем не выполнить. Приходит заказчик и говорит «Ребята, все классно, а можем еще вот это и вот это прикрутить?». Всей командой радостно отвечаем: «Ну конечно, какие проблемы?» – все, лишь бы подписаться уже и начать работу.

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

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

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

У заказчика свои процессы, у нас – свои. Баланс между этими двумя сущностями стоит находить, отталкиваясь от пользы для заказчика.

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

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

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

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

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