Что отвечать на страхи и возражения ваших идеальных клиентов по разработке

Dmytro Rodenko, founder of SaaS Founders, walks through how software development companies should answer client fears about deadlines, quality, communication, IP rights, and support. He covers pricing concerns and how to build trust through better client conversations.
СПОКОЙНАЯ МУЗЫКА Всем привет. Меня зовут Дмитрий Роденко. Я основатель сообщества SaaS Founders. Помогаю фаундерам IT-компаний находить новых крупных клиентов с помощью лида генерации в LinkedIn. Давайте сегодня поговорим о том, что отвечать на страхи и возражения ваших идеальных клиентов по разработке. Для многих из нас с вами идеальный клиент по разработке Это человек, у которого есть бюджет. Человек, у которого есть автономный бюджет. Человек самостоятельно принимает решения. У человека есть потребность в разработке. Человек понимает, что да, нужно. не всегда понимает, что именно в каком объеме, но в целом говорит, да, мне есть четко необходимое. И это необходимость ограниченного времени. То есть мне это нужно в течение определенного времени. Да, там месяц, два, три, шесть, год и так далее, но мне это нужно. Соответственно, это наш идеальный клиент. Получить встречу с идеальным клиентом по разработке достаточно усилия. В частности, нужно, первое, найти этих людей, выстроить с ними минимально доверительное отношение, показать ценность, создать атмосферу, правильно? Потому что если этого нет, идеальный клиент не будет встречаться. Почему? Потому что идеальный клиент ценит свое время, что время этого человека стоит достаточно дорого. Я как-то считал, что если мы говорим о 3 миллиона долларов, то полчаса времени этого человека стоит порядка 700 долларов. Соответственно, когда мы говорим, давайте встречаться, давайте общаться, это значит следующее. Мы просим проинвестировать невозобновляемого ресурса на 700 долларов в наши отношения. Если клиент не понимает, как это работает, что это ему даст, он не будет это делать. инвестировать эту сумму. Соответственно, целевую, правильно реализируем профиль, выстраиваем правильные доверительные отношения, находим что-то общее, вырабатывается какая-то эмпатия, и хорошо, интересно, мы уже, соответственно, работаем со страхами и возражениями. Итак, Чего больше всего боятся клиенты по разработке? Боятся до проекта, во время проекта, ну и, соответственно, какое-то время после. Первое. Они боятся срыва сроков. Сроки связаны с определенными обещаниями другим людям. То есть, соответственно, если человек хочет разрабатывать больше времени, у этого человека нет. Через полгода должен быть сделан базовый проект. функционал. Поэтому если в рамках работы возникают какие-то неожиданные осложнения, замена персонала, это может привести к финансовым потерям. А продавщик не хочет и хочет минимизировать подобные вещи. Естественно, если сроки проекта увеличивают, time and material, вырастает стоимость, то есть превышается бюджет. Это тоже может стать проблемой для клиента, потому что клиент финансирует разработку либо, то есть какого-то бюджета выделенного, либо изъемных средств, либо средств инвесторов и так далее. Соответственно, сумма изначально превышается, несет клиент. Дальше клиенты боятся низкого качества, они боятся того, что то, что им было показано, соответствовать их ожиданиям. И здесь очень важная история. Мы сейчас отдельно обсудим, как работать с ожиданиями клиентов для того, чтобы не было того, что вы обещали мне дворец, а получился сарай с пристройкой. так, чтобы человек понимал, что окей, я задаю задачу. Клиенты боятся недостаточной коммуникации, недостаточно четкой коммуникации. Это очень важный вопрос, потому что многие разработчики, к сожалению, говорят, ну окей, у меня сейчас есть разработчики, с которым я ставлю задачи, аутсорсинговые разработчики, да, и которые, ну, отвечают так, как они считают нужным. Они классные, они хорошо-хорошо делают работу, я доволен результатом, но коммуникация с но, так сказать, хочет, потому что я хочу быть в курсе всех этапов разработки. Я могу какие-то задачи упростить. Могу сказать, окей, это мы делаем так, не так. Поэтому если коммуникация недостаточно регулярна и недостаточно эффективна, то это может вызвать вопросы к тому, что вообще делается и как делается. Дальше. Клиенты боятся проблем с интеллектуальной собственностью. В частности, я встречаю периодически такие возражения, когда вам полностью модель, мы даем вам полностью всю логику работы, вы ее за наши деньги реализовываете и через три появится клон нашего же решения, абсолютно точно такой же. Вот как мы гарантируем от подобных рисков. Поэтому проблемы тоже беспокоят. Кроме того, последнее, как это, the last but not the least, последний вопрос — это техническая поддержка после завершения проекта. И этот СЭС, он не должен останавливаться после окончания проекта. То есть, как минимум, есть фаза поддержки, фаза какой-то объяснения, доработки каких-то вещей, которые возникают при В контактах не просто QA-команда, не просто вас как клиента или клиента как кого-то, а большого количества пользователей. Пользователи тоже находят баги. Кто их будет решать? Какая команда это будет делать? Наверное, команда разработки. Поэтому после окончания Проекта, оно не заканчивалось. Когда мы говорим про возражения, отвечать на возражения так нужно. чтобы не задавали новых вопросов. Что я имею ввиду? Это не значит, что мы должны быть грубыми, жесткими, нет. Ответ на вопрос должен быть избыточным. Человек говорит, окей, я понял, хорошо, меня устраивает ответ, все, больше вопросов нет. Нам надо для того, чтобы отвечать на возражения, хорошо подготовиться. И это обычно один из самых важных вопросов, потому что у клиентов в голове так или иначе Список возражений примерно одинаковый. Это то, что я говорил. Сделаете ли вы работу вовремя? Почти 8 бюджет. Как вы гарантируете качество работы? Будут ли вы с интеллектуальной собственностью? Будут ли вы поддерживать миодаль? Сколько это стоит? Да? На какие игры? Отдельный вопрос. Почему цена такая высокая? Это один вопрос. И почему цена такая низкая? Это другой вопрос. На самом деле нужно быть готовым, потому что если кто-то говорит, что цена высокая, это окей. Человек хочет поторговаться, человек раньше не работал. Человек может стеснен в бюджете, может человека научили. Есть, кстати, практики, которые говорят о том, что вот особенно в ритейле это распространено, если клиент связан с коммерсом или с ритейлом, для них там 2-3% сэкономлены, это может быть достаточно большая часть их там. Привыкли торговаться, они обычно говорят, окей, а скидочку дадите? А на каком основании это нужно делать? Это отдельный вопрос. Потом нужно быть готовым к ответу на вопрос, почему цена такая высокая. И очень важно быть готовым к вопросу, почему цена такая низкая. Не все клиенты разбираются в ценах. И для кого-то цена, условно, долларов в час может оказаться, может показаться слишком низкой, потому что все зависит от урона. уровня нормы, назовем так. То есть, если клиент вокруг в своей технологии раньше видел цены 100 долларов, 120, 200, 250, и потом показывает все на 50, у него возникают вопросы, почему 50, почему это стоит 50, а не 200. Поэтому иметь ответ на вопрос, почему цена такая низкая, тоже к нему надо подготовиться. Очень важный момент в целом при подготовке к работе с возражениями – это проактивность, то есть эмпатия, вовлечение в разговор, убедиться в то, что клиент вообще понимает. То есть, первое, убедиться, что мы поняли правильно возражения. Может, человек вообще не об этом спрашивает. То есть, если мы не поняли, переспросить, уточнить. дали ответ и проверить вопрос, то есть есть ли еще какие-то вопросы, замечания. Это очень важно. Это абсолютно базовые вещи, независимо от того, с какими возражениями. Мы говорим про сроки, про конкретные примеры возражений и ответов. Но если мы говорим про срыв сроков проекта, что мы здесь можем сказать? Мы можем сказать, что мы работаем по определенной методологии. Раз, у нас есть стабильная команда. Почему могут возникать сроки выполнения проекта? Потому что возникли некие дополнительные сложности, которые были не предусмотрены в рамках процесса работы, и на них не заложено время, да, либо нет некой процедуры обработки этих сложностей. Вот. Соответственно, мы говорим следующее, что наша команда использует определенный подход, там, Agile метод, условно говоря, неважно, или подход, там, Scrum, у нас есть Scrum метод, да, у нас есть Scrum Manager, мы раз в две недели делаем спринты, собираемся, то есть есть четкие понятные параметры, есть точка входа, точка выхода, ну и мы, соответственно, достигаем. Более того, хорошо здесь работает эвеляция к прошлому опыту, когда вы показываете 5-10 проектов такого же плана с таким же уровнем компаний, с такой же, вы уже, скорее всего, на них научились, и вы знаете, что работает и как работает. И важно показать, что у вас есть метода по которой вы отслеживаете сроки выполнения тех или иных задач и вы всегда можете оценить задержки, которые будут возникать для того, чтобы своевременно их скорректировать и предупредить появление превышения бюджета. Очень важный момент. Смотрите, когда мы формируем бюджет С одной стороны, моя позиция состоит в том, чтобы при формировании бюджета мы апеллировали к некой дополнительной ценности для клиента. Что я имею в виду? Чтобы ROI, return on investment, смотри, возврат для клиента был в 5-7% вашей работы. Тогда, соответственно, вы работаете Вы можете просить справедливую цену. И в этом смысле превышение бюджета на 10% для клиента не будет критичным. Окей, хорошо, расширился функциональный проблема. Поэтому для того, чтобы не превышался бюджет, нужно сделать хорошо домашнюю работу. Что я имею в виду? Собрать, требовать критерии выполнения данных результатов. Как мы считаем, задача выполнена или нет? То, что вы проработали над задачей тысячу часов, это не значит, что задача выполнена. Правильно? Задача выполнена, когда достигнуты определенные показатели. Есть определенные свойства и так далее. Выполняется определенная работа, трансформируется ресурс, информация трансформируется из одной формы в другую. Ну, соответственно, получаются определенные результаты. Соответственно, это первый момент. То есть вы четко это планируете, вы показываете, что у вас есть методология и процесс планирования, который минимизирует подобные вещи. Более того, вы говорите, что любые изменения в проекте, которые могут повлиять на стоимость, будут предварительно согласованы с клиентом. Клиент говорит, окей, нормально, да, это хорошо. Про качество работы, когда клиенты боятся низкого качества работы. Здесь вы можете рассказать, опять же, о технологиях, о подходах, которые вы используете для обеспечения качества, включая код-ревью, автоматическое тестирование и так далее. Можете апеллировать, опять же, к своему опыту, к успешно завершенным проектам. Можете показать свою команду, показать их портфолио, показать, что это за люди, как они работают, какие у них результаты. Это обычная апелляция к низкому качеству работы. Опять же, важный момент, связанный с подменой команды, потому что бывают ребята, которые показывают топов, показывают синеров, говорят, они будут работать, а по факту их работу будут выполнять другие. Но на самом деле, если вы хотите масштабировать работу с клиентом, вы должны обеспечить то, что вы ему обещаете. Поэтому этот фокус любят определенные типы компаний. Да, у некоторых даже на больших проектах это получается. Но, опять же, самое важное в этом смысле, чтобы вы делали то, что вы обещаете. Это очень важно. Коммуникация. Это очень важный момент, который многие компании недооценивают. Почему? Дело в том, что мы — люди, наши клиенты — люди. Продукты и решения мы делаем для людей с помощью людей. То есть коммуникация и кооперация — наше всё. Без нормальной коммуникации и эффективной кооперации мы не можем сделать то, что мы пообещали. В части, в том числе оценка эффективности нашей работы Зависит и от коммуникации, и от кооперации с клиентом. У себя мы приняли такое решение. Мы делаем следующее. Мы делаем три уровня коммуникации для клиента. Первый уровень стратегический. Вот мы, например, с клиентом работаем в рамках года. Каждый месяц у нас есть некий статус-репорт, статус-код, так называемый, где собирается команда клиента, собираемся мы и обсуждаем там текущие показатели, что сделано, так сказать, где наш проект, согласно его плану. То есть двигаемся ли мы по плану, выше плана, ниже плана и что нужно сделать для того, чтобы улучшить ситуацию. Либо все окей. Это так называемый статус кол ежемесячный. Это стратегический кол, который показывает вообще, как мы двигаемся. Более того, у нас есть еженедельная коммуникация в виде статуса отчета. Каждую среду в 16.00 клиентам уходит сообщение, некий дашборд с результатами, KPI, и так далее. Что сделано, над чем работаем, что будем делать, какие вопросы надо обсудить и решить с клиентом. Это позволяет на раннем этапе, во-первых, информировать клиента, чтобы клиент понимал, окей, все в порядке, я вижу динамику, нормально, проект работает, есть обратная связь и так далее. И предупреждение каких-то проблем, которые могут возникнуть раньше. Чтобы не решать проблемы от месяца к месяцу, а чтобы позволить проблемам проявиться заранее. Пусть на уровне слабых сигналов или каких-то вопросов. Соответственно, у вас уже будет, как минимум, от одной до четырех недель для того, чтобы эту ситуацию проявить полностью, уточнить, в чем проблема, и начать ее исправлять. И оперативный уровень коммуникации, связанный с ежедневными задачами. Это может быть чат в Slack, это может быть канал, чат в Telegram, где участвует вся команда наша, которая работает над данным проектом, и команда клиента. Это связано с решением каких-то оперативных быстрых вещей, связанных с тем, ли пришел, не пришел, перенес. То есть какие-то буквально оперативные вещи, которые надо обсудить. И, соответственно, вот эти три уровня коммуникации снимают вопросы по качеству коммуникации. И это очень важно. Я вам рекомендую подобные вещи тоже делать так. По проблемам, связанных с интеллектуальной собственностью. Здесь вопрос доверия. Здесь многие компании даже не начинают общаться с вами до того, как вы подписали NDA, то есть соглашение о неразглашении, чтобы защитить идеи и технологии клиента. Нормальная история, я очень спокойно к этому отношусь. У нас масса клиентов, с которыми у нас подписана NDA, и о которых мы не сможем говорить никогда. Вот вообще в принципе. Потому что это очень крупные компании, ну и соответственно им не нужны там риски, связанные с утечкой информации о работе с ними. Поэтому есть базовые NDA у нас, которые мы подписываем, есть NDA, которые готовят клиенты сами. Окей, нормально. В принципе, я абсолютно спокойно отношусь к тому, чтобы это делать. Более того, мы предпринимаем определенные усилия для того, чтобы NDA по ним работал, то есть чтобы был ограниченный круг людей в курсе, ну и так далее, то есть NDA с сотрудниками. Поддержка после завершения проекта. Очень просто, как мы уже говорили, сразу предусмотреть в плане проекта, вообще даже в кейсах, вообще во всей своей истории, что вы не бросаете клиента, что вы с клиентом работаете дальше и у вас получается выстраивать дальнейшие доверительные отношения. Классическая эта история работает не только со стартапами, но и со всеми компаниями. Почему? Дело в том, что первый этап Разработки обычно ищут возможности как расширить взаимодействие с вами с такой же эффективностью. Соответственно, если, например, была автоматизирована одна операция или один процесс, может быть автоматизирован второй, третий, четвертый, пятый процесс и так далее. Это в обычном бизнесе. Со стартапами это еще интереснее. У стартапов вообще-то в плане через некоторый период поднять следующий раунд. И когда они будут поднимать следующий раунд, у них возникнет вопрос. А кто будет обеспечивать нам? Это будет in-house команда, которую надо нанимать, оплачивать, подбирать, готовить? Или это будет outsourcing команда, с которой мы уже сейчас работаем, с которой у нас есть хороший результат? У меня есть клиенты, которые работают 15 лет с другими стартапами, начинали с самого начала и повырастали до команд на проектах по 50-60 человек. Нормально работают уже годами. И в основном это было сделано за счет того, что они обещают. С другой стороны, за счет того, что они правильно коммуницировали и поддерживали клиента. Это позволило клиентам быть уверенными в том, что результаты будут вовремя и такие, какие они хотят. Для компании поставщика, для разработчика это обеспечило хорошие финансовые результаты. проекта, там 50 FTE, full-time employees. Вот, соответственно, если мы будем таким образом подходить к подготовке к работе, сранее будем понимать возражения клиента и готовиться к ним, это позволит вам выглядеть гораздо более уверенно и повысить конверсию из офферов в контракт. Клиенты видят вас первый раз, второй раз, третий раз, они должны доверить, не волноваться. Хорошо. Договор. Хорошо. То есть все это вместе должно быть на высоте. На высоте. И качество презентации, естественно. Если вам на данный момент Не хватает клиентов. Если вы хотите, чтобы у вас таких клиентов становилось больше, то, сейчас я размещу ссылочку, вы можете пообщаться с нашей командой лидо-генераторов для того, чтобы определить, сколько и каких клиентов, и когда вам надо. Дело в том, что крупные клиенты, они не приходят сразу. Им нужно определенное время. Они должны быть готовы к переходу на следующий уровень отношений. Поэтому начинать надо заранее. То есть хотя бы надо 2, 3, 4 месяца на развитие для того, чтобы выстроить минимальные доверительные отношения, провести первые переговоры и после этого уже на следующие уровни, на следующий этап. Вот поэтому, что я вам рекомендую? Первое, созвониться с нашей командой лидо-генератор. Покажу так вот красивее. Значит, ссылочка ниже. Что вы делаете? кликайте по ней, сейчас она будет в комментариях. Вы бронируете созвон с нашей командой, заполняете информацию о себе, кто вы, чем вы занимаетесь, к чему стремитесь. Наша команда готовится, ребята, что можно сделать, точнее, на встречу, нюансы, и в итоге дают вам некий план развития, то есть как можно ваши цели в разработке, в развитии бизнеса по разработке достичь за оптимальное время. Также вы смотрите Либо вы сами это делаете, что вполне окей, либо вы говорите, ребята, вы разбираетесь, вы даете финансовую гарантию, все, вперед, берите и делайте. И тогда, если нам это интересно, мы, соответственно, этим вопросом занимаемся уже. Поэтому желаю вам новых крупных клиентов. Если у вас их мало, вы знаете, кого спросить. Вот вам ссылочка, поэтому you are welcome. Ждем ваши заявки.
More from Dmytro

Лайфхак "Какие ошибки в лидгене убивают ваши шансы на сделку по IT разработке"









