УправлениеПереговоры

Главный вопрос на первой встрече с заказчиком 

Одна из задач первой встречи — понять, ваш ли это клиент и стоит ли браться за проект. Наверняка, есть множество способов это сделать, я поделюсь своим.

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

На решение войти в проект или нет, влияет несколько моментов:

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

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

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

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

Есть контакт. Вам должно быть приятно общаться с заказчиком. Это должен быть ваш человек, с которым вам легко и просто. Часто этот момент упускают из вида, а он, вероятно, самый тонкий и сложный.

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

Чтобы понять, ваш ли это человек, достаточно после первой встречи задать себе один вопрос: «Хочу ли я встретиться с этим человеком ещё раз? А десять раз? Готов ли я делать с ним проект, где мне придётся вести переговоры, объяснять детали и нюансы, предлагать решения? Хочу ли я сделать с ним два проекта? А пять? «

Самый главный вопрос на первой встрече с заказчиком: «Хочу ли я встретиться с этим человеком ещё раз?»

Если ответ «возможно», это не ваш клиент. Если ответ «нет», значит это не ваш клиент. И только если ответ «да, мне было приятно с ним общаться, готов видеться с ним регулярно», это ваш клиент. Звучит банально, но, чёрт возьми, работает.

Восемь секретных знаний о продажах: запрещённый список ★ 

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

А как тогда продавать, если не называть цену, ведь всё равно, в конце концов, выбирают по цене?

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

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

  1. Никаких продаж на первой встрече, в первом сообщении или письме. Пока вас не знают, пока вы не сформировали доверие, в мире этих людей вы — никто. Не надо прикладывать презентации, сыпать эпитетами и обещать золотые горы, нахваливать себя или свой продукт. Лучший способ завоевать доверие — сразу приносить пользу.
  2. Действовать надо как при знакомстве в жизни. В жизни мы знакомимся, рассказываем о себе, но ничего не продаём. Те, кто так делают, довольно быстро попадают в жесткий игнор и обламываются. Вспомните назойливых консультантов в магазине. Если не хотите, чтобы вас мысленно или вслух послали нахуй, не ведите себя как они.
  3. Цель первой встречи, первого письма или сообщения — начать диалог, познакомиться и понять, есть ли вообще запрос, нужна ли вообще людям ваша помощь. Здесь всё как на приёме у врача: нельзя лечить абстрактную болезнь. Врач даёт таблетку, когда знает, с чем имеет дело, когда он понимает, что с вами и какая таблетка вам нужна.
  4. Когда приходишь к кому-то с предложением что-то улучшить, нужно понимать, что это за человек, его систему ценностей и контекст, в котором он находится прямо сейчас. Люди не любят, когда их кто-то оценивает. Если открывать дверь с ноги, учить жизни и писать что-то вроде «у вас тут слабые решения и плохой дизайн», это лишь вызовет сопротивление. Такие ребята обычно идут нахуй строевым шагом.
  5. Нельзя продать что-либо человеку, не понимая, нужно ли ему то, что вы предлагаете и имеет ли это хоть какую-то ценность в его мире. Часто люди знают о проблемах, про которые вы им рассказывает, но эти проблемы не критичны для их бизнеса и не влияют на прибыль. В мире сотни тысяч компаний с древними сайтами, которые не обновлялись с начала 2000-х. Они продают услуги на личных встречах в офисе. Предлагать таким компаниям редизайн сайта нет никакого смысла.
  6. Допустим, что у заказчика всё же есть для вас работа. Но продавать всё ещё рано. Сначала стоит понять, сможете ли вы в целом работать вместе, сходитесь ли вы по ценностям и подходу к работе. Тут лучше всего работает встреча или созвон. Узнайте, как заказчик формирует задачу и представляет себе возможное решение. Расскажите, как будете строить работу, обсуждать замечания, согласовывать результат и пр.
  7. Презентуйте план работ и смету лично. Проведите клиента за ручку по всем этапам и цифрам, покажите, что он получит в итоге. Клиенты не заказывают дизайн или тексты каждый день, они не знают, как устроена ваша работа, из чего она состоит. Только на этом этапе стоит говорить про деньги. Не на первом шаге и не в письме, а лично, когда у вас и заказчика сложился общий, единый контекст, который вы и он понимаете одинаково.
  8. Иногда вам будут отказывать. Возможно, сейчас ваша помощь не нужна. Возможно, ваши цены завышены. Возможно, вы плохо презентовали свой подход и не смогли завоевать доверие человека напротив. Важно помнить, отказ — это не конец отношений, а часть диалога. Это «нет» именно сейчас, в текущий момент времени и в текущем контексте. «Нет» — это сигнал, который сообщает новое знание о вас, ваших услугах и подходе. Используйте его, чтобы улучшить ваш процесс.

Как двигать проект вперёд и не страдать 

Ситуация в проекте с клиентом прямо сейчас:

  • — Нам нужно собрать совещания и обсудить ситуацию с командой.
  • — А зачем нам команда?
  • — Ну, чтобы найти решение.
  • — Давайте решим сейчас, вдвоём. Есть такие-то варианты: раз и два. А вот тот вариант, что мы хотели изначально, не годится, потому-то и потому-то.
  • — Тогда идём с вариантом номер один.
  • — Супер, завтра пришлю результаты по нему.

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

Какие тут можно сделать выводы:

  1. Есть клиенты, которые любят посовещаться. Собрать людей из трёх отделов и что-нибудь обсудить. Это затягивает проект и совершенно не помогает найти решение. От такого надо открещиваться всеми правдами и неправдами.
  2. Пять человек никогда ни о чём не договорятся. Договариваются двое, и из них всегда кто-то один принимает финальное решение. Созвоны и встречи на два человека — ОК, на три и более — трата времени и дорожка в ад.
  3. Вы не обязаны соглашаться на условия клиента, если они вам не подходят. Если процесс затягивается, сделайте всё, чтобы принять решение сейчас. Не завтра, не послезавтра. Здесь и сейчас. Потому что завтра — это ещё через неделю.
  4. Старый добрый звонок на телефон — всё ещё отличный способ быстро решать вопросы. Главное, чтобы у него была чёткая и конкретная цель. Без возни и прелюдий. Чётко: контекст, проблема, решение, что делаем дальше, получить ОК.

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

Разреши себе быть глупым 

Иногда собеседник на встрече выглядит таким крутым и опытным, что страшно задать лишний вопрос. Боишься показаться глупым и невнимательным, и начинаешь додумывать. Может, он уже про это сказал, и если я спрошу, он подумает, что я не слушал. Или он уже и так всё разжевал два раза, а я всё никак не пойму. Наверное, после этого вопроса они просто откажутся со мной работать…

Ситуация скверная: выглядеть дураком страшно, но уйти со встречи, ничего не поняв, ещё страшнее. Хотя некоторые так и делают, а потом у них «всё не то», «надо всё переделать» и «начальник — мудак». Сплошь и рядом такое.

Задавать глупые вопросы мне помогает установка: будь самым глупым на этой встрече.

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

Умение задавать глупые вопросы — ключ к решению проекта. Но для этого нужно разрешить себе быть самым глупым и не стесняться этого. К тому же глупый вопрос задаётся лишь раз. И главное, что после ответа вы уже не так глупы, как до. Теперь у вас есть новые знания, которые вы можете использовать для решения задачи.

Если мне надо задать глупым вопрос, я так и говорю: «Возможно, я сейчас задам глупый вопрос, но я не понимаю, как…» Или если у заказчика сложная сфера, про которую я ничего не знаю, например, буровые вышки, я предупреждаю его в начале встречи: «Мы ничего не знаем про ваш бизнес, поэтому сегодня будем задавать много глупых вопросов. Без них мы не сможем разобраться в задаче…»

И плевать, кто и что подумает обо мне. Да, возможно, когда я задам свой вопрос, кто-то и правда подумает: «Вот тупица!» И пусть. Вспомнит ли он об этом, когда проект будет закончен? Вряд ли. Люди не помнят, что они ели сегодня на завтрак и какого числа день рождения у их лучшего друга, не то что чей-то вопрос на одном из десятков созвонов.

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

Легко, там работы на денёк! ★ 

Одно из правил, которого я придерживаюсь в проектах и переговорах: не говорить о чём-либо «это легко» и не оценивать чью-либо работу этим словом. Ни свою, ни чужую. Особенно, если я никогда не делал то, о чём говорю.

Я понимаю, почему люди используют это слово. Они заискивают перед клиентами, хотят произвести впечатление, понравится. И не замечают, что роют яму сами себе.

Легко — это контракт с клиентом, что вы соглашаетесь выдать безупречный результат в короткий срок и без права на ошибку. Хуже только работать без договора или по бартеру. Именно поэтому «легко» так убийственно для проекта. Оно создаёт завышенные ожидания и не учитывает, что что-нибудь обязательно пойдёт не так. А что-нибудь всегда идёт не так.

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

Легко — это бомба замедленного действия, отложенный конфликт в проекте. И эту бомбу невозможно обезвредить. Нельзя прийти на следующий день и сказать: «Ой, знаете, там вообще не легко оказалось». В глазах клиента это выглядит так, что вы или наврали или не разбираетесь в своём деле.

Не спешите давать оценки. Возьмите время оценить задачу, учитывая все детали и контекст. Особенно, если работу будете делать не вы, а кто-то другой. И уж точно не говорите о своей работе: «Ой, легкотня!» Каждый раз, когда я думал так, случалось ровно наоборот.

Действуйте от обратного. Мне помогает такой приём: «Скорее всего это будет непросто и даже сложно, но я попробую найти красивое и элегантное решение. Как я могу решить эту задачу за день? Какое решение даст результат уже сегодня?»

Ошибка на старте. Наврать клиенту про опыт ★ 

Читаю рассылку одного агентства и вижу такой совет:

Не говорите, что у вас нет опыта. Мы считаем, что, если вы хотя бы теоретически знаете, как решить задачу, не стоит говорить клиенту, что никогда этого не делали. Иначе отношение к вам может быть снисходительное и настороженное, клиент подумает, что за вами придется сто раз перепроверять. Много денег с таким подходом заработать, скорее всего, не получится.

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

Вдобавок, такой подход лишает заказчика права на обдуманное решение. Исполнитель ничем не рискует, кроме своего времени, а заказчик рискует всем: деньгами, временем и иногда бизнесом.

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

Это если в общем. Теперь по фактам. Вот как я советую поступать, если нет опыта.

Совет № 1. Снизить ожидания от результата

Скажите честно, что вы никогда не решали такие задачи и объясните, как планируете действовать. Клиент будет понимать, что вы с ним честны, будет платить тем же и доверять вам.

— А вы раньше писали статьи о коммерческой недвижимости?
— Пётр Алексеевич, знаете, нет, я прежде не писал на эту тему. Я понимаю, что, возможно, вам нужен автор с опытом в этой сфере. Но если у нас будет эксперт по теме, то вот как бы я решал вашу задачу… Можем для начала написать первую статью и посмотрим, как пойдёт. Если будет не очень, то расстанемся.
— Эксперты у нас есть. Давайте пробовать.

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

Совет № 2. Опыт и цена никак не связаны

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

Цена — это про договорённости с самим собой и заказчиком, а не про опыт, часы, знаки или что-то там ещё. Если мне комфортно сделать работу за Х денег и заказчика это устраивает, то я её делаю. А если нет, то не делаю. Всё просто.

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


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Не сообщать о проблемах
  3. Наврать клиенту про опыт — вы здесь

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Ошибка на старте. Не сообщать о проблемах ★ 

Частый косяк исполнителей, который иногда встречается даже у опытных и зрелых ребят — пропадать без предупреждения. Это всех бесит и хреново влияет на результат. В проекте возникает напряжение, пропадает доверие, всё скатывается в говно и мочилово.

Ниже инструкция о том, как не быть мудаком и пропадать правильно.

Кратко

Как только вы поняли, что у вас проблема, сообщите о ней руководителю или заказчику. Предупредите, что у вас что-то идёт не по плану, и нужен новый. Хорошо, если вы не просто придёте со словами «у меня проблема, помогите», но ещё и предложите решение и возьмёте на себя ответственность. Иначе пользы от вашего предупреждения мало.

Подробно

Бывает, что человек заболел или в проекте затык, и работа встала. Уже ясно, что к дедлайну не успеть. Как обычно действуют люди в таких ситуациях:

  1. Не сообщают никому о ситуации.
  2. Пропадают с радаром и не выходят на связь.
  3. Не отвечают на сообщения и звонки.
  4. Появляются в день дедлайна с оправданиями.

Чаще всего они мямлят что-то вроде:
— У меня заболела бабушка, прорвало трубу, я заболел…
— Мне казалось, что я успею…
— Я не хотел тебя тревожить по мелочам…

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

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

  1. Сообщить о проблеме. Расскажите коллеге, руководителю или клиенту о проблеме в тот же момент, как она возникла. Не надо ждать завтра или пока всё разрешится само собой. Дайте знать, что есть ситуация, которая может навредить проекту, если ничего с ней не делать.
  2. Описать ситуацию и предложить решение. Если работаете в команде — делегировать задачу кому-то, кто может подменить вас на время жопы. Такая опция есть не всегда, поэтому скорее всего придётся проявить смекалочку и найти решение самому.
  3. Сформировать ожидания. Сообщите клиенту и остальным коллегам, сколько времени вас не будет, как с вами связаться и к кому обратиться, пока вас нет. Большая часть проектной работы с заказчиком или в команде — это управление. Не обязательно самим проектом или людьми, а, в первую очередь, собой, своим процессом, задачами и ожиданиями других людей.
  4. Отвечать на сообщения и звонки. Гасятся только мудаки. Ну и все эти отмазки про «не было связи» звучат смешно в 2023 году, когда связь есть уже в любой деревне.
  5. Решить проблему. Без спешки и с чистой совестью перед командой и клиентом. Помните: спешка ебёт горячку.

Ситуаций, когда что-то идёт не так, в каждом проекте — десятки. Если научиться их решать и предупреждать о проблемах заранее, то ни вы, ни клиент их даже не заметите. А если забить и продолжать мириться с хуйнёй, то каждый проект будет похож на новый круг ада. Выбор за вами.


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Не сообщать о проблемах — вы здесь
  3. Наврать клиенту про опыт

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Не правки, а замечания и вопросы 

Правки — это хотелки заказчика, которые следует безропотно принять и согласиться на любые доработки. Те, кто принимают правки, обычно так и мыслят: ну раз пришли правки, мы их сейчас внесём, чего спорить-то. Хотя, возможно, всё уже достаточно хорошо и ничего никуда вносить не надо.

Замечания и вопросы — это ход мысли, приглашение к разговору. Замечания требуют обсуждения: можно задать вопросы, уточнить, поспорить, предложить другое решение. Вопросы — сигнал, что заказчик что-то понимает иначе, чем мы, и нам надо разобраться, как именно он это понимает и почему.

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

Что мы не делаем ★ 

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

Отложить что-то на старте проекта значит освободить время и место в голове для более важных задач, без решения которых проект не запустится. Чем больше задач вы пытаетесь упихнуть в единицу времени, тем дальше вы от цели. И, наоборот, чем меньше объём работы, тем выше вероятность создать работающее решение и запуститься в срок. На практике все это знают, но когда находишься в проекте, очень легко закопаться и согласиться на дополнительную неоплачиваемую работу.

Не сделать лишнего помогает такой приём — добавить в понимание задачи пункт «Что мы не делаем». Не просто обсудить с клиентом, мол, да-да, вот эту интеграцию с ЦРМ пока делать не будем, а прям записать в документ в отдельный пункт с деталями. Многим это кажется странным, мол, я-то точно не забуду. Забудете.

Люди всё забывают и очень быстро.

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

Вот план действий на случай, если клиент пришёл с задачей, которую вы отложили:

  1. Не бросать текущие задачи и не бежать сломя голову чего-то там делать, рисовать и писать.
  2. Пойти посмотреть, что вы писали в понимании задачи и о чём договорились.
  3. Вернуться к клиенту с ответом: «Да, Иван Иваныч, понимаем, но мы с вами решили пока это не делать. Можем взять в следующий спринт, цикл, вынести в отдельный проект, когда закончим текущий».

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

Не знаешь, что делать — не делай ничего 

Свежий пример из редакторской практики:

Автор присылает на провереку пост, где есть перечень из четырёх пунктов. Три пункта — хорошие, с примерами и фактурой, а четвёртый — дохлый, на одну строчку. Рядом с остальными пунктами перечня он выглядит неуверенно, неполноценно.

Я пишу комментарий, что так не пойдёт: все пункты перечня должны быть равноценны между собой. Автор берёт и доливает в слабый пункт «воды». Становится ещё хуже: теперь у нас в перечне три полезных пункта и один — с притянутыми за уши фактами и обтекаемыми формулировками.

Снова пишу комментарий. Автор начинает двигать слова, но это не помогает. Так продолжается какое-то время, пока я не задаю вопрос: «А какую проблему ты пытаешься этим решить?» Оказалось, автор был уверен, что должен перебрать как можно больше решений. Это частое заблуждение.

Работа исполнителя не в том, чтобы сделать больше: написать больше текста или подвигать пиксели в макете. Иногда работа в том, чтобы не делать ничего. Иногда нужно перестать искать новое решение, и пересмотреть проблему, изменить её, переформулировать.

Вот несколько примеров:

  1. В списке появился куцый пункт, и вы не знаете, что туда дописать — уберите этот пункт. Это лучше, чем оставить прежний список с дохлым пунктом.
  2. В макете есть экран с плохой компоновкой, запуск уже через неделю, и вы понимаете, что со всеми согласованиями разработчики не успеют выкатить эти изменения в срок. Передоговоритесь с клиентом о том, чтобы запустить сайт без этого экрана. Это лучше, чем отложить пуск.
  3. Вы сели писать письмо другу, но слова не складываются в текст. Значит, сегодня явно не тот день, чтобы страдать над белым листом. Отложите письмо, займись другими делами. Это лучше, чем отправлять вымученное письмо.

Если не можете найти решение, возможно, вы решаете не ту проблему. Смените фокус и убедитесь, что дело именно в решении, а не в чём-то ещё. Возможно, лучший вариант — это отступить от намеченного плана и не делать ничего и дать решению созреть.