Чтобы не сел на голову: как объяснить клиенту, что он не прав, и выстроить коммуникацию с ним

Утверждение «клиент всегда прав», конечно, верно далеко не всегда. И если еще в b2c-секторе, например, в ресторане быстрого питания, продавцу проще улыбнуться и извиниться, чем спорить, доказывая правоту и задерживая очередь, то в b2b сомнительное мнение клиента лучше оспорить заранее, чем «разгребать» последствия потом. В том числе это касается ИТ-сферы. Как работать с клиентом продуктивно, не следуя бездумно его рекомендациям и требованиям, но и не навредив при этом делу — своим опытом делится руководитель отдела маркетинга ИТ-компании SoftTeco Алексей Зубель.

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

---

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

Как выстроить коммуникацию с клиентом

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

1. «Разведка» — именно с нее начинается процесс построения коммуникации с клиентом. Хорошо проведенная подготовка на фазе продажи и качественный бизнес-анализ помогают выстроить процессы таким образом, что риск конфликтных ситуаций будет минимизирован. Нельзя переходить на следующий этап, пока не будут четко ясны ожидания клиента.

Что такое разведка? Прежде всего это сбор информации о клиенте. В Беларуси такая практика не распространена. Однако в Америке и Европе это абсолютно нормально, когда не только клиент узнает информацию о компетенциях подрядчика, но и подрядчик собирает и анализирует информацию о клиенте. Это можно делать через социальные сети или, если это более-менее крупная компания, проконсультироваться у прошлых ее подрядчиков. Можно с ними связаться и спросить, как проходило их сотрудничество.

На фазе продажи считается нормой спросить у клиента «а почему ты считаешь, что ты будешь для нас хорошим клиентом?». Узнать, как он платит, как решает конфликтные ситуации, работает с изменениями.

Это поможет сделать выбор, стоит ли в принципе работать с этой компанией.

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

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

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

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

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

Составление контракта

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

1. Соглашение о «непереманивании сотрудников». Обычно оно заключается на срок порядка 5 лет. Часто этот пункт распространяется в том числе на сотрудников, которые сами от нас ушли. Клиент не имеет права нанимать их на работу еще год.

У нас был такой случай: мы проработали с клиентом год. Он открыл в соседнем здании офис и стал переманивать к себе сотрудников, которые работали на этом проекте.

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

2. Еще один важный пункт контракта — условия оплаты. Акты выполненных работ должны подписываться на каждом этапе. Хотя эта практика не совсем широко распространена на рынке Западной Европы и Северной Америки. У них часто в контракте указано, что если в течение определенного срока заказчик не предъявил претензий, значит работа считается выполненной удовлетворительно. Но мое мнение — на время этого срока все равно нужно подписывать какой-то документ. Специфика нашего бизнеса такова, что проект пишется частями, частями же идет и оплата. И если заказчик захочет потом вернуться и оспорить что-то, без документов нелегко будет это что-то доказать. Акт нас защищает.

3. Также в контракте должно быть четко прописано, как мы работаем с изменениями. Каким путем информация о переделке к нам должна поступить, сколько времени нам дается, чтобы обработать запрос, как должно выглядеть дополнительное соглашение. Лучше эту процедуру не игнорировать, а сделать ее как можно более формальной. Чтобы заказчик «не сел на шею».

Клиент может сказать: «Мне тут нужно немного изменить». Мы можем это сделать и даже не брать с него денег. Но нужно, чтобы процедура была формально выполнена. Потому что потом он может так же попросить вернуть все обратно.

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

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

Часто на фазе продажи мы используем в контракте инфографику. Контракт нужно не только составить, но и сделать понятным, легко читаемым, чтобы клиент был проинформирован о самых важных пунктах. В наше примере инфографика включает 5–6 страниц. Обычно она показывает общую архитектуру проекта, стоимость, как происходят платежи, график нашей работы, команду, контакты, гарантии и условия поддержки и иногда включает в себя маркетинговые материалы о компании. Презентация о компании нужна для того, чтобы сотрудник клиента мог показать это своим коллегам или партнеру. И они могли бы в течение 5−7 минут ознакомиться с нашим предложением и компанией. Визуализация все же более понятна, чем куча букв. И она легче запоминается.

Вот пример такой графики:

Распределение ролей на проекте

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

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

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

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

Проектный менеджер — это связующее звено между командой и клиентом, а аккаунт-менеджер — между компанией и клиентом.

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

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

Мы работаем в системе Scrum: в режиме 2-х недельных спринтов. И это очень удобно.

О системе менеджмента качества

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

СМК относится к основным составляющим работы с клиентом — фазе анализа и грамотному распределению ролей на проекте. Внедренная нами СМК описывает два основных процесса:

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

2. Внутренний процесс управления персоналом.

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

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

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

СМК регламентирует три главных момента:

1. Описание процессов компании. В нашем случае 2 основных наших ресурса — наши инженеры и наши отношения с клиентом. Для других компаний они будут иными.

2. Процедуры — мини-процессы, которые не всегда могут измеряться. Это что-то мелкое повседневное. Например, закупка инвентаря.

3. Управление рисками. Компания выявляет, какие у нее основные риски. И как она будет с ними работать.

Плюсы от внедрения СМК. Она помогает расти. За прошлый год мы, например, выросли на 30%. И сохранили эту тенденцию в этом году. Наш главный ресурс — это люди. А СМК помогает быстро вводить сотрудников в курс дела, координировать их работу, применяя меньше усилий. Есть четкие инструкции, которые помогают им работать, избегая рисков и проблем. Более того, так мы демонстрируем клиенту серьезность нашего подхода в ведении бизнеса и регламентируем действия проектной команды и компании в целом. Это не означает, что до этого мы работали безалаберно. Просто сейчас у нас есть документ, система, которой легко следовать. И с заказчиком мы строим отношения, исходя из этих процедур: так, чтобы приносить пользу и нам, и ему.

Если клиент говорит вдруг, что хочет по-другому — например, позвонить разработчику в 12 ночи и сообщать ему о своих уникальных идеях — в таком случае мы или предусматриваем особый контракт, или не работаем с этим заказчиком вовсе. Серьезные клиенты ценят такой подход. Часто в тендере наличие системы менеджмента качества идет основным пунктом. И подрядчики, которые ее не имеют, даже не рассматриваются в качестве исполнителей.