Как объяснить клиенту, что он неправ

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

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

«Я бы кое-что изменил»

Клиент всегда убежден, что его идея действительно хороша – это вполне понятное поведение человека. Особенно часто такое встречается у небольших заказчиков.

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

Клиент всегда прав (с)

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

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

В нашем биллинге, когда мы знаем, что имеем дело с одним и тем же Иваном Ивановым, все данные по нему сводятся в одну сущность «клиент», но есть и системы, где все не так. Был случай, когда клиент, переходивший с такого продукта на наш, настойчиво просил сделать из одного такого Ивана Иванова несколько абонентов – по одному на каждый договор или услугу (интернет, телевидение, телефония и т.п.). В какой-то момент мы «плюнули» и сделали, как нас просили, однако это привело к проблемам – логика работы системы была сломана. Корректно вести статистику и строить отчеты по таким «раздвоенным» или даже «растроенным» абонентам очень сложно.

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

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

Как объяснить клиенту, что он неправ…

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

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

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

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

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

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

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

Не давайте сомневаться в своей экспертизе

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

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

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

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

Нужно снижать «трение»

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

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

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

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

Главное: не надо спорить

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

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

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

Материалы по теме:

Как из хобби вырастить полноценный бизнес

15 непрофессиональных email-привычек, из-за которых вас могут отправить в спам

8 технических навыков, за которые в Кремниевой долине платят более $110000 в год

Scrum – это не для всех

Фото на обложке: Pixabay