Я занимаюсь разработкой ПО для бизнеса и иногда мне хочется пристрелить отдел продаж. Потом я беру себя в руки, вспоминаю, что именно эти ребята приносят в компанию деньги, а программисты, вообще-то висят на затратах. В этот момент приходит просветление: продавцы обладают другим мышлением, другими навыками и, чаще всего, другим образованием. И каждый день им приходится бороться с кучей возражений клиентов из серии «а один подрядчик из Индии пообещал разработать точно такую-же систему в два раза быстрее и дешевле».
Продажа – самое начало проекта и ошибки на этом этапе – самые страшные. Не проработаете ожидания клиента или промахнетесь с оценками и вас ждет «путь камикадзе». Перезаложите бюджет – потеряете клиента или у него сложится ощущение обманутости.
Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 25-30 человек, а директор – перегружен.
Альтернативный вариант – делегировать оценку техническому директору (CTO). Обычно, это второй по перегруженности человек в компании. Кроме того, у технического директора вагон и маленькая тележка других задач. Таскать его на каждый pre sales – не вариант. Я искренне убежден, что любой нетривиальный проект можно разрабатывать только итеративно и только с прототипами. Такой подход до сих пор сложно принять многим клиентам на территории СНГ. Все хотят на берегу зафиксировать сроки и бюджет. К сожалению, это желание не сопровождается техническим заданием, на основании которого можно было бы работать. Хотя с точки зрения клиента конечно задача поставлена чётко и ясно.
Данная статья – не совсем скрипт для продажи в привычном понимании слова. Скорее попытка построить мостик между «техническим» и «бизнес» — мышлением и помочь тем, кто испытывает сложности с презентацией и отстаиванием итеративного подхода к разработке.
На кликабельной для увеличения картинке ниже жизненный цикл проекта, каким его вижу я. Зелеными флажками обозначены этапы, за которые клиент вносит предоплату. Исключением является этап «подписываем акт». В этот момент клиент принимает работу и оплачивает оставшуюся часть.
В статье я буду использовать термин «проект», а не «продукт», даже если речь идет о стартапе или разработке коробочного, тиражируемого продукта, потому что «продуктовая» разработка подразумевает работу с внутренним, а не внешним заказчиком.
Задачи:
Неадекватность — понятие субъективное. Для меня клиент неадекватный, если он:
Любой из этих пунктов говорит о том, что эффективную коммуникацию выстроить не получится, а значит, проект ждет провал. Стоит отказаться от такого клиента, благо запросов на разработку ПО много.
Предположим, наш клиент – адекватный. На данном этапе нужно с одной стороны подготовить его к сложной работе, с другой – не слишком напугать и остаться на оптимистичной ноте.
Львиная доля всех проектов в IT не укладывается в сроки и бюджеты. Иные даже в релиз не выходят. Причины я описывал в статье «рентабельный код». Несмотря на это, все еще хватает в нашей сфереиндусов не опытных подрядчиков, пренебрегающих рисками. Эти горе-программисты не способны правильно оценить объем работы, зато способны пообещать золотые горы. Не квалифицированному клиенту сложно выбрать правильного подрядчика. Клиент оперирует терминами «стоимость» и «срок».
Чтобы лучше понять чувства клиента, выбрать правильные слова и донести свою мысль нужно поставить себя на его место.
Я могу разделить сложных клиентов на два типа:
Первые будут вам присылать кучу бесполезной документации, наставать на использовании определенных технологий или процессов, требовать каких-то специфических отчетов, потому что «им кто-то рассказал». В этом случае у меня есть четкая позиция: если ты знаешь, как сделать лучше – иди и делай сам. В этом вопросе нужно быть жестким. В противном случае команду разработки начинают продавливать говнокодить и заниматься культом карго. Это снижает мотивацию в команде и ведет проект прямо к обрыву. Кстати, когда проект провалится, вину возложат на команду разработки, аргументируя это тем, что «подрядчик не компетентный попался и принял не верные технические решения».
Со вторым типом клиентов все проще и сложнее одновременно. С одной стороны, вам не мешают, с другой – вас лишают обратной связи и велик риск того, что на этапе сдачи проекта вам скажут «мы ожидали совершенно иного». Чего ожидали они на самом деле не знают, что не является поводом включать дурочку стиле «клиент сам дурак, бе-бе-бе».
К этому моменту у нас на руках есть вся существующая документация по проекту и какая-то информация, преданная устно, в ходе встречи или звонка. К сожалению, это все еще очень ранний pre-sales. Желательно уклониться от оценки и продать прототипирование, потому что на данном этапе все еще правильно говорить «угадывать», а не «оценивать». Однако, если дать какую-то вилку все-же нужно, я использую «ресурсный метод» подсчета:
Типичные небольшие команды могут быть такими:
Вариант 1
Вариант 2
Вариант 3 (расширенный)
Вариаций может быть много, это базовые составы. Стоимость аренды подобной команды в месяц у российских аутсорсеров варьируется в диапазоне 500.000 рублей +- 100.000. Типичные проекты длятся от 3 до 12 месяцев.
Умножаем полмиллиона на от 3 до 12 и получаем от 1.5 до 6 миллионов рублей.
С одной стороны, клиент должен был к этому моменту составить представление за что он платит и какие опасности поджидают при обращении к студенту-племяннику или подрядчику из Калькутты. С другой, разброс цен слишком велик. В этот момент на сцене появляется волшебный термин «прототипирование». Под прототипами я понимаю mockup’ы, собранные а Axure или подобном софте, желательно, интерактивные.
Прототипирование можно посчитать по fixed-price схеме: клиент платит за концепцию (3-10 экранов). После утверждения концепции оплачивается разработка остальных экранов прототипов. Я считаю, что проектирование должен делать один UX/BA-специалист, консультируясь с «технарем», чтобы не нарисовать что-то слишком сложно реализуемое (этим грешат обычно в digital'е) или не подходящие для выбранной платформы разработки. Если такого специалиста нет, то надо завести в штат или на договоре подряда.
С прототипами на руках уже можно рассчитать проект по столь любимой клиентом fixed-price схеме. А может, уже и не придется этого делать и T&M подойдет. Когда вы продаете прототипирование вы говорите клиенту: «давай снизим наши общие риски, прежде чем с головой бросаться в омут разработки, еще раз хорошенько все обдумаем и нарисуем, чтобы ты смог потрогать».
После утверждения прототипов можно одновременно рисовать финальный визуальный дизайн и начинать разработку. Я предпочитаю Scrum для команды разработки и Kanban для поддержки. Организация работы команды по Agile и утверждение визуального дизайна выходят за рамки этой статьи. Остановлюсь лишь на том, что я рекомендую согласовать с клиентом несколько промежуточных демонстраций и процесс обработки change request’ов. На этих встречах необходимо рассказывать о проделанной работе и предлагать клиенту самому проверить выполнение целей спринтов. Таким образом, этап внедрения и интеграции начнется раньше сдачи проекта, что поможет не затягивать с подписанием финальных актов и оперативно реагировать на изменение внешней ситуации. Как говорится, аппетит приходит во время еды и уже после первой или второй демонстрации клиент может захотеть расширить функциональность и бюджет.
Суть проблемы
Продажа – самое начало проекта и ошибки на этом этапе – самые страшные. Не проработаете ожидания клиента или промахнетесь с оценками и вас ждет «путь камикадзе». Перезаложите бюджет – потеряете клиента или у него сложится ощущение обманутости.
Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 25-30 человек, а директор – перегружен.
Альтернативный вариант – делегировать оценку техническому директору (CTO). Обычно, это второй по перегруженности человек в компании. Кроме того, у технического директора вагон и маленькая тележка других задач. Таскать его на каждый pre sales – не вариант. Я искренне убежден, что любой нетривиальный проект можно разрабатывать только итеративно и только с прототипами. Такой подход до сих пор сложно принять многим клиентам на территории СНГ. Все хотят на берегу зафиксировать сроки и бюджет. К сожалению, это желание не сопровождается техническим заданием, на основании которого можно было бы работать. Хотя с точки зрения клиента конечно задача поставлена чётко и ясно.
Данная статья – не совсем скрипт для продажи в привычном понимании слова. Скорее попытка построить мостик между «техническим» и «бизнес» — мышлением и помочь тем, кто испытывает сложности с презентацией и отстаиванием итеративного подхода к разработке.
Первая встреча/входящий запрос
На кликабельной для увеличения картинке ниже жизненный цикл проекта, каким его вижу я. Зелеными флажками обозначены этапы, за которые клиент вносит предоплату. Исключением является этап «подписываем акт». В этот момент клиент принимает работу и оплачивает оставшуюся часть.
В статье я буду использовать термин «проект», а не «продукт», даже если речь идет о стартапе или разработке коробочного, тиражируемого продукта, потому что «продуктовая» разработка подразумевает работу с внутренним, а не внешним заказчиком.
Задачи:
- отсеять неадекватных клиентов
- подготовить адекватных к тому что с высокой вероятностью работа предстоит долгая и потребует хотя-бы частичного погружения в проект
- провести подготовительную работу, узнать текущий статус проекта запросить существующие материалы
- дать клиенту грубую оценку по срокам, стоимости и технологиям (обязательно уточнив, что такая оценка показывает лишь порядок сроков и цен, не является финальной и может измениться в любую сторону)
- презентовать клиенту итеративный подход и предложить работать именно так
Отсеять неадекватных клиентов
Неадекватность — понятие субъективное. Для меня клиент неадекватный, если он:
- хамит
- не слушает и перебивает
- ставит под сомнение любые аргументы или пытается уличить во лжи
- апеллирует тезисами, вроде «у меня у друга сын-студент написал программу…»
Любой из этих пунктов говорит о том, что эффективную коммуникацию выстроить не получится, а значит, проект ждет провал. Стоит отказаться от такого клиента, благо запросов на разработку ПО много.
Подготовить адекватных
Предположим, наш клиент – адекватный. На данном этапе нужно с одной стороны подготовить его к сложной работе, с другой – не слишком напугать и остаться на оптимистичной ноте.
Львиная доля всех проектов в IT не укладывается в сроки и бюджеты. Иные даже в релиз не выходят. Причины я описывал в статье «рентабельный код». Несмотря на это, все еще хватает в нашей сфере
Чтобы лучше понять чувства клиента, выбрать правильные слова и донести свою мысль нужно поставить себя на его место.
Однажды мне нужно было купить утюг. Я зашел в один крупный магазин бытовой техники. На меня смотрела целая полка утюгов. Самый дешевый стоил 800 рублей, самый дорого – больше 20.000 рублей. Я находился в растерянности, потому что на вид все утюги казались мне одинаковыми. Я попросил продавца-консультанта объяснить мне разницу. Девушка что-то начала рассказывать про дополнительные опции, режимы… Дивный голос продавщицы показался мне песней… на китайском языке. Я попросил ее посоветовать мне то, что она купила бы себе, взял эту модель и пошел домой, думая, как трудно моим клиентам. Ведь им нужно не просто выбрать из существующих «утюгов», а спроектировать и собрать свой собственный «утюг» с блэк-джеком и всем остальным.
Я могу разделить сложных клиентов на два типа:
- я расскажу вам, как делать вашу работу
- ну что вы ко мне пристали, вы программисты – вы и делайте
Первые будут вам присылать кучу бесполезной документации, наставать на использовании определенных технологий или процессов, требовать каких-то специфических отчетов, потому что «им кто-то рассказал». В этом случае у меня есть четкая позиция: если ты знаешь, как сделать лучше – иди и делай сам. В этом вопросе нужно быть жестким. В противном случае команду разработки начинают продавливать говнокодить и заниматься культом карго. Это снижает мотивацию в команде и ведет проект прямо к обрыву. Кстати, когда проект провалится, вину возложат на команду разработки, аргументируя это тем, что «подрядчик не компетентный попался и принял не верные технические решения».
Со вторым типом клиентов все проще и сложнее одновременно. С одной стороны, вам не мешают, с другой – вас лишают обратной связи и велик риск того, что на этапе сдачи проекта вам скажут «мы ожидали совершенно иного». Чего ожидали они на самом деле не знают, что не является поводом включать дурочку стиле «клиент сам дурак, бе-бе-бе».
Дать клиенту грубую оценку по срокам, стоимости и технологиям
К этому моменту у нас на руках есть вся существующая документация по проекту и какая-то информация, преданная устно, в ходе встречи или звонка. К сожалению, это все еще очень ранний pre-sales. Желательно уклониться от оценки и продать прототипирование, потому что на данном этапе все еще правильно говорить «угадывать», а не «оценивать». Однако, если дать какую-то вилку все-же нужно, я использую «ресурсный метод» подсчета:
- Программист, обладающий необходимый для моих задач квалификацией, стоит в регионах России (не Белокаменной)
60.000 – 120.000 рублей - QA – 30.000 – 80.000
- Менеджер 40.000 – 80.000
Типичные небольшие команды могут быть такими:
Вариант 1
- Team Lead (Старший разработчик + Менеджер)
- Разработчик
- QA
Вариант 2
- Разработчик
- Разработчик
- Менеджер (заодно и тестирует)
Вариант 3 (расширенный)
- Team Lead
- Разработчик
- Разработчик
- Разработчик
- QA
- UX
- Аккаунт-Менеджер
Вариаций может быть много, это базовые составы. Стоимость аренды подобной команды в месяц у российских аутсорсеров варьируется в диапазоне 500.000 рублей +- 100.000. Типичные проекты длятся от 3 до 12 месяцев.
Умножаем полмиллиона на от 3 до 12 и получаем от 1.5 до 6 миллионов рублей.
Именно на этом этапе у нас появляется пространство для переговоров
С одной стороны, клиент должен был к этому моменту составить представление за что он платит и какие опасности поджидают при обращении к студенту-племяннику или подрядчику из Калькутты. С другой, разброс цен слишком велик. В этот момент на сцене появляется волшебный термин «прототипирование». Под прототипами я понимаю mockup’ы, собранные а Axure или подобном софте, желательно, интерактивные.
Прототипирование можно посчитать по fixed-price схеме: клиент платит за концепцию (3-10 экранов). После утверждения концепции оплачивается разработка остальных экранов прототипов. Я считаю, что проектирование должен делать один UX/BA-специалист, консультируясь с «технарем», чтобы не нарисовать что-то слишком сложно реализуемое (этим грешат обычно в digital'е) или не подходящие для выбранной платформы разработки. Если такого специалиста нет, то надо завести в штат или на договоре подряда.
С прототипами на руках уже можно рассчитать проект по столь любимой клиентом fixed-price схеме. А может, уже и не придется этого делать и T&M подойдет. Когда вы продаете прототипирование вы говорите клиенту: «давай снизим наши общие риски, прежде чем с головой бросаться в омут разработки, еще раз хорошенько все обдумаем и нарисуем, чтобы ты смог потрогать».
Аргументы за прототипирование
- На основании можно более точно рассчитать стоимость. На основе прототипов клиент получит смету, с указанием технологического стека, платформы, которую действительно считали, а не взяли с потолка
- Прототипы можно прокликать и еще до разработки понять, удобно ли пользоваться системой и не упущены ли какие-то ключевые требования. Удобство использования – не пустой звук. Плохой интерфейс может стать узким местом бизнес-процесса, следовательно, причиной снижения дохода. Если интерфейс позволяет допустить оператору ошибку, это может привести к прямым убыткам
- Исправить ошибки на этапе прототипирования гораздо быстрее и дешевле, чем на этапе разработки
- Прототип – может использоваться как средство верификации работы подрядчика, он гораздо нагляднее и понятнее текста, отмазка в стиле «я так понял ТЗ» не пройдет
После утверждения прототипов можно одновременно рисовать финальный визуальный дизайн и начинать разработку. Я предпочитаю Scrum для команды разработки и Kanban для поддержки. Организация работы команды по Agile и утверждение визуального дизайна выходят за рамки этой статьи. Остановлюсь лишь на том, что я рекомендую согласовать с клиентом несколько промежуточных демонстраций и процесс обработки change request’ов. На этих встречах необходимо рассказывать о проделанной работе и предлагать клиенту самому проверить выполнение целей спринтов. Таким образом, этап внедрения и интеграции начнется раньше сдачи проекта, что поможет не затягивать с подписанием финальных актов и оперативно реагировать на изменение внешней ситуации. Как говорится, аппетит приходит во время еды и уже после первой или второй демонстрации клиент может захотеть расширить функциональность и бюджет.
Комментарии (9)
AlexTest
27.04.2015 03:16+2Не квалифицированному клиенту сложно выбрать…
Квалифицированных клиентов не бывает, что и подтверждает ваша история про утюг, где в этом месте:Я попросил продавца-консультанта объяснить мне разницу
вы попытались стать квалифицированным клиентом, и выяснили что это невозможноголос продавщицы показался мне песней… на китайском языке
Но дальше вы рассказываете, как вы сами, по сути пытаетесь сделать из «не квалифицированного» клиента — квалифицированного.
Но это ему не нужно, ему к примеру нужен интернет-магазин и он хотел бы знать пресловутые «стоимость» и «срок». На самом деле его интересует именно стоимость т.к. срок просто влияет на этот параметр.
Точно так же как и в гипермаркете с утюгами — продажник называет вилку цен вашей компании: к примеру от 2000 до 100000 USD. Клиент просит объяснить разницу и точно так же слышит «песню на китайском языке» — знакомо?
На самом деле квалифицированным должен быть продавец, а не клиент. Например, на вопрос о разнице в стоимости утюгов в гипермаркете, продавец мог бы просто ответить, что цена утюга обусловлена очень большим количеством факторов. Чтобы не тратить слишком много времени и обсуждать каждую конкретную модель из допустим сотни имеющихся в наличии, сначала надо уменьшить это количество на основании нужного вам функционала. Т.е. по сути он выясняет: что, как и в каких количествах вы собираетесь гладить? Далее, выясняется допустим, что вам надо гладить хб и шелк и обязательно иметь большой резервуар для отпаривания и высокую точность регулировки температуры. После чего продавец показывает вам уже всего пяток моделей удовлетворяющих вашим потребностям. Если же вы не знаете параметров своего белья и гардероба, то продавец вежливо просит вас уточнить их допустим по телефону у жены, ну или сначала посмотреть ярлычки на ваших изделиях где указаны допустимые режимы глажения и прийти в следующий раз с этой информацией.
Продавец разработки ПО точно так же должен уметь выяснять — что же на самом деле нужно клиенту, и если клиент этого не знает — объяснять как подготовить необходимую информацию.
Но к сожалению я попал на такого толкового продавца в гипермаркете только один раз за последние 30 лет, и именно в этом страшная правда. Таких квалифицированных продавцов на самом деле катастрофически мало! Так что ваше желание :пристрелить отдел продаж
скоре всего вполне обосновано.
marshinov Автор
27.04.2015 13:14+2Отвечу на оба ваших комментария здесь.
И как конкретно с этим возражением клиента борются продажники в вашей компании?
Основная цель моего переговорного процесса — не влезать в fixed-price разработку без стадии прототипирования. Самый хороший вариант перейти от обсуждения цены к обсуждению ценности и состава продукта. Если бюджет «другого подрядчика» ниже рыночной стоимости перед вами либо неадекватный заказчик, либо вас пытаются «продавить». Можно смело показывать рыночные рассылки и задать клиенту вопрос «как подрядчик собирается выполнить работу ниже рыночной стоимости? На чем он будет экономить? Либо на качестве, либо на составе выполненных работ». А собирается ли вообще подрядчик выполнять обязательства? Если заказчика это устраивает — отлично — мы не стали работать с неадекватным клиентом.
Если мы находимся в «зоне неопределенности» — те самые 3-12 месяцев — тоже хорошо. Можно привести аналогию с ремонтом, она почти всем знакома: можно поклеить обои, а можно стены под подкраску, плитку можно положить итальянскую, а можно российскую. И таких вот «мелочей» — 100500, давайте все подберем, то что подойдет именно вам. А когда все материалы (прототипы) подобраны можно и ремонт (разработку) начинать.
Не всегда эта аргументация помогает, но у меня было несколько случаев, когда клиент возвращался через 3-5 месяцев со словами: «ты был прав, не надо было экономить». Иногда человеку нужно получить собственный опыт, чтобы сделать выводы.
На самом деле квалифицированным должен быть продавец, а не клиент
Возможно, я употребил не самое удачное слово. По поводу квалифицированных продавцов я с вами полностью согласен. Под квалифицированным клиентом я понимаю, например, себя, когда мне требуются услуги аутсорсеров. На данный момент у меня уже есть пул надежных подрядчиков, но пока я его собирал каких откликов я только не получал.
Просто смешно, когда ты оставляешь очень четкое описание того, что тебе нужно, вплоть до указания конкретных технологий и чек-листов для сдачи-приемки работы и просишь предложить мне предложить готовое решение или разработку по fixed-price схеме, а в ответ: «вот наш скайп, давайте общаться». Да я не хочу с вами общаться, я просто собираю предложения, чтобы потом из них выбрать исполнителя, который гарантированно не нафакапит.AlexTest
28.04.2015 20:28+1Основная цель моего переговорного процесса — не влезать в fixed-price разработку без стадии прототипирования.
Вот в этом я полностью с вами согласен, fixed-price разработка без прототипа — это проблема как для заказчика так и для разработчика. Я смотрю на это в основном со своей «колокольни» вебразработки и давно уже понял, что без хотя бы fireframe макета сайта в fixed-price лучше не лезть! Вот написал недавно статью по довольно толковому инструменту, как мне кажется. Думаю нужно эту мысль (про предварительное прототипирование) всеми возможными способами продвигать т.с. в массы, как заказчиков так и исполнителей, показывая именно экономическую привлекательность такого подхода. Сейчас планирую написать еще одну статью по прототипированию вебсайтов именно с убеждающей логикой на примере прототипов в Google Презентациях. Хотел бы предложить вам ознакомится с черновиком статьи и дополнить его вашей аргументацией. Если у вас найдется на это желание и время — предлагаю продолжить общение в личных «диалогах» на хабре.
realbtr
27.04.2015 03:35+2С точки зрения продажника — все это очень сложно, нудно и, главное — вообще не интересно клиенту.
Все что нужно продажнику — это ясное сознание «боли клиента» и предлагаемой клиенту «таблетки».
Если у клиента есть не только «боль», но и осознание, что готовой таблетки нет, и нужен не просто доктор, а фармацевт, то обычно у такого клиента уже есть (и еще будет) опыт разной успешности лечения и самолечения.
И тогда «боль» клиента для продажника — это некомпетентность в процессах разработки, растерянность и четкое желание — чтобы его «вальсировали» и аккуратно выстраивали его ожидания (по срокам, бюджетам, возможным проблемам, рискам и всевозможным нетехническим решениям).
Тут клиент — как женщина. Хочет одновременно и безопасности, и чтобы об этой безопасности заботилась не она, а кто-то надежный.
Отсюда и «хаки» в продажах, связанные с правильными ухаживаниями, созданием ощущения надежности и защищенности, а потом долгом и счастливом браке, когда счастливый клиент и кормит, и поит, и одевает, да еще и радостно щебечет.
А без этих «хаков» — на одних классных разработчиках и менеджерах проектов «долго и счастливо» не бывает. Женщина (клиент) хочет быть уверенным. Причем сразу во всех (обязательно несовместимых и противоречивых) аспектах. И что навсегда, и что лучший, и что не уведут/не бросит, и что всегда будет любить…
Поэтому наилучший способ, это когда есть харизматичный продажник (который ухаживает и любит) и есть стойкий аккаунт (который разбирает все косяки и претензии) и есть инициативный (но слегка блаженный) техэнтузиаст (который сыпет идеями, как то колечко из десятого королества) и терпеливый внедренец (который все супер идеи аккуратно ужимает в рамки времени и бюджета и доводит их до конечного пользователя, пусть и не всегда до оргазма, но до влажной благодарности и уверенной надежды на следующий раз)
Прошу прощения за некоторую вульгарность в эпитетах…
prolis
27.04.2015 10:13+1Ставит под сомнение любые аргументы или пытается уличить во лжи
— потому, что часто приходят консультанты с богатой фантазией но слабой компетенцией.
AnnieOmsk
30.04.2015 20:51Отлично написано! Как директор компании, ограниченной 25-30 человеками в данный момент, через которого проходят все заказы, подписываюсь под каждым словом :-)
hamMElion
20.05.2015 18:12+1Спасибо за статью. Единственное уточнение: для развития бизнеса выгоднее перед блоком «До свидания» вклинить условие «У довольного, принесшего прибыль клиента есть еще проекты, которые мы могли бы сделать?». Если да — начинать с начала, если нет — печальное «До свидания».
AlexTest