Решением проблемы стало создание тщательно продуманного клиентского портала. У каждого заказчика были логин и пароль, которые они использовали для входа. На портале они находили подробную информацию о своем проекте. Можно было ознакомиться с образцами дизайна и предварительной версией сайта, а также заглянуть в календарь, где были отмечены основные этапы реализации проекта. В «журнале работ» ежедневно появлялась информация о задачах, выполненных в каждый конкретный день. Большая часть реального общения сводилась к специальным встречам, которые были приурочены к конкретным этапам проекта. По итогам каждой встречи составлялась памятка, в которой указывалось, какие решения были приняты. И мы просили клиентов подписать эти памятки, чтобы выразить свое согласие. (Поскольку поняли, что это снижает вероятность того, что клиент впоследствии передумает, когда мы уже будем в процессе разработки.) У нас была возможность прикрепить сканы подписанных памяток на портал.
Мы никогда не объясняли клиентам, что необходимость в портале возникла потому, что мы целый день в школе (хотя, я полагаю, они и сами об этом догадывались). Мы просто организовали рабочий процесс таким образом, чтобы наше отсутствие не вызывало проблем. Сегодня разработчики часто жалуются, как много времени им приходится тратить на электронную переписку. Мы в свое время занимались примерно такой же работой, но при этом электронной почтой не пользовались совсем.
Разумеется, мы не были единственными, кто придумал умную систему общения с клиентами. В главе 1 я рассказывал историю Шона, который реорганизовал работу в своей маленькой технологической компании. В его случае наиболее раздражающим фактором была чрезмерно активная коммуникация с клиентами, которая и стала для него переломным моментом. События стали стремительно развиваться, когда особенно требовательный клиент потребовал доступ к их каналу в Slack, предназначенному для внутреннего общения. В результате звук уведомлений этого мессенджера стал постоянным шумовым фоном, а каждое сообщение от клиента приносило новую головную боль. Неудивительно, что в итоге Шон решил заменить гиперактивный коллективный разум какими-то более оптимальными рабочими процессами. И одной из сфер его внимания стало общение с клиентами.
Сотрудники компании стали добавлять в каждое техническое задание раздел под названием «Коммуникация». «Мы хотим, чтобы клиент был в курсе до начала работы над проектом», — пояснил Шон. В этом новом разделе описывались правила коммуникации клиента и сотрудников компании, в том числе — и на этом Шон сделал акцент — как вести себя, если возник срочный вопрос. В большинстве случаев стандартная процедура предусматривала еженедельную телефонную конференцию с заказчиком по заранее согласованному расписанию. После этого в письменном виде кратко подводились итоги конференции, и документ отправляли заказчику. Бизнес-партнер Шона, который отвечал за взаимоотношения с клиентами, был обеспокоен этим нововведением. «Он боялся, что заказчики будут недовольны. Ведь работа нашей компании построена на общении с пользователями, и это общение должно быть высокопрофессиональным, — объяснил Шон. — Но уровень удовлетворенности клиентов существенно вырос. Весь секрет в управлении ожиданиями».
И Шон, и я в своей компании в 1990-е использовали оптимизированный протокол коммуникации, чтобы управлять обменом информацией между клиентами и сотрудниками компании (хотя мы и не использовали именно такую терминологию). Благодаря этому нам удалось существенно снизить средние затраты на координацию работы. Я изучил и другие примеры протоколов общения с клиентами и хочу дать несколько рекомендаций, которые помогут сделать взаимодействие успешным.
Прежде всего, стремясь сократить затраты, думайте не только о собственных ресурсах, но и о ресурсах клиента. Ключевой фактор, который помогает клиентскому протоколу работать, — снижение когнитивных затрат или устранение неудобств, в том числе для клиента. На самом деле немногие из них любят бесконечно отправлять вам сообщения. Часто они вынуждены это делать, поскольку не знают, как еще можно с вами связаться или убедиться в том, что работа будет выполнена. По опыту Princeton Web Solutions я понял, что структурированный интерфейс портала не раздражал клиентов. Наоборот, они успокаивались, поскольку им не приходилось тратить когнитивную энергию, переживая, будет ли выполнена работа. И напротив, если вы внедрите такую схему коммуникации, которая упростит жизнь вам, но усложнит ее вашим клиентам, вам будет намного сложнее продавать свои услуги, и не без причины. (Приведу яркий пример: каждый раз, когда заказчику что-то нужно, вы требуете, чтобы он направил вам подробный запрос по факсу.)
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
Еще один важный момент — ясность. Сотрудники компании Шона добавляли подробное описание протокола общения с клиентами в каждое техническое задание, а заказчик его подписывал. Очень разумно. Если бы сотрудники просто предлагали клиентам еженедельные конференции в качестве варианта коммуникации, высок шанс, что заказчики при малейших проблемах автоматически вернулись бы к гиперактивному общению. Когда же все предусмотрено договором, клиент, скорее всего, немного пострадает из-за незначительных неудобств. Но со временем он осознает все преимущества, связанные с более низкими средними затратами более жесткой системы.
И наконец, несмотря на все ваши усилия, всегда найдутся клиенты, для которых определенные протоколы просто не работают. Я общался с консультантом по коммуникациям в Вашингтоне, округ Колумбия. Она работала в магазине, где трудились 12 человек. Она рассказала, что при работе со многими клиентами они использовали подход, похожий на метод Шона: еженедельный созвон, по итогам которого составлялся письменный отчет. Однако общение с другими клиентами проходило по иной, «антикризисной» схеме. С ними необходимо было незамедлительно связываться, если рекламная кампания шла не по плану. Именно поэтому протокол общения с ними выглядел просто: «Если что-то случилось — сразу звоним клиенту». Другими словами, от характера работы зависит, какой именно протокол будет использоваться.
Разработанные вами процедуры также могут не подойти для отдельно взятых людей, и это обусловлено не характером работы, а их индивидуальными особенностями. Иначе выражаясь, я говорю о тех выродках, которым нравится ко всему придираться, чтобы почувствовать собственную важность. Подобную ситуацию описал Тим Феррис в своем бестселлере «Как работать по 4 часа в неделю». Описывая преобразования, которые он осуществил в своей дочерней компании BrainQuicken, Тим рассказал, как «дал отставку» одному из наиболее воинственных и вгоняющих всех в стресс клиентов. Идея, что можно прекратить работу с токсичным клиентом, задевает за живое. «Этот абзац меня шокировал», — вспоминает Тоби Лютке, генеральный директор IT-компании Shopify, в кратком очерке о Феррисе, который появился в журнале Inc. «Если вы пойдете в бизнес-школу и предложите там избавиться от клиента, вас просто выгонят. Но, исходя из своего опыта, могу сказать, что предложение очень разумное. Такая политика позволяет определить, с кем из клиентов вы действительно хотите работать»[158]. Идеи Клода Шеннона помогают понять логику подобной стратегии. Разумеется, в краткосрочной перспективе вы потеряете деньги. Но зато вы избавитесь от существенных когнитивных затрат. Как только вы начнете воспринимать такие затраты более серьезно, вам станет проще отказаться от работы с клиентами, которые наносят существенный урон вашей психике и не компенсируют его ростом дохода вашей компании.
Подводя итоги, могу сказать: если вы работаете с заказчиками, для отказа от гиперактивного коллективного разума необходим оптимизированный клиентский протокол.
Обезличенные электронные адреса
Некоторые сферы нашей жизни уже настолько привычны, что нам сложно представить, что может быть по-другому. Один из таких примеров — стандартный формат электронного адреса: фамилия@название_компании. В нем есть нечто элегантное. Когда вы отправляете электронное послание, лежащий в основе работы сервиса протокол направляет его в ту организацию, которая указана в электронном адресе. Когда письмо попадает в сеть организации, почтовый сервер доставляет его адресату, указанному слева от символа @. И именно такую систему — что в адресе должен быть указан конкретный сотрудник — мы принимаем как должное. Но если мы несколько отстранимся и посмотрим на ситуацию свежим взглядом, возникает интригующий вопрос: почему получатель — всегда конкретный сотрудник? Почему бы не указывать в адресе какой-то отдел, команду проекта или вид деятельности?
