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

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

Прежде всего, стремясь сократить затраты, думайте не только о собственных ресурсах, но и о ресурсах клиента. Ключевой фактор, который помогает клиентскому протоколу работать, — снижение когнитивных затрат или устранение неудобств, в том числе для клиента. На самом деле немногие из них любят бесконечно отправлять вам сообщения. Часто они вынуждены это делать, поскольку не знают, как еще можно с вами связаться или убедиться в том, что работа будет выполнена. По опыту Princeton Web Solutions я понял, что структурированный интерфейс портала не раздражал клиентов. Наоборот, они успокаивались, поскольку им не приходилось тратить когнитивную энергию, переживая, будет ли выполнена работа. И напротив, если вы внедрите такую схему коммуникации, которая упростит жизнь вам, но усложнит ее вашим клиентам, вам будет намного сложнее продавать свои услуги, и не без причины. (Приведу яркий пример: каждый раз, когда заказчику что-то нужно, вы требуете, чтобы он направил вам подробный запрос по факсу.)

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

И наконец, несмотря на все ваши усилия, всегда найдутся клиенты, для которых определенные протоколы просто не работают. Я общался с консультантом по коммуникациям в Вашингтоне, округ Колумбия. Она работала в магазине, где трудились 12 человек. Она рассказала, что при работе со многими клиентами они использовали подход, похожий на метод Шона: еженедельный созвон, по итогам которого составлялся письменный отчет. Однако общение с другими клиентами проходило по иной, «антикризисной» схеме. С ними необходимо было незамедлительно связываться, если рекламная кампания шла не по плану. Именно поэтому протокол общения с ними выглядел просто: «Если что-то случилось — сразу звоним клиенту». Другими словами, от характера работы зависит, какой именно протокол будет использоваться.

Разработанные вами процедуры также могут не подойти для отдельно взятых людей, и это обусловлено не характером работы, а их индивидуальными особенностями. Иначе выражаясь, я говорю о тех выродках, которым нравится ко всему придираться, чтобы почувствовать собственную важность. Подобную ситуацию описал Тим Феррис в своем бестселлере «Как работать по 4 часа в неделю». Описывая преобразования, которые он осуществил в своей дочерней компании BrainQuicken, Тим рассказал, как «дал отставку» одному из наиболее воинственных и вгоняющих всех в стресс клиентов. Идея, что можно прекратить работу с токсичным клиентом, задевает за живое. «Этот абзац меня шокировал», — вспоминает Тоби Лютке, генеральный директор IT-компании Shopify, в кратком очерке о Феррисе, который появился в журнале Inc. «Если вы пойдете в бизнес-школу и предложите там избавиться от клиента, вас просто выгонят. Но, исходя из своего опыта, могу сказать, что предложение очень разумное. Такая политика позволяет определить, с кем из клиентов вы действительно хотите работать» [158] . Идеи Клода Шеннона помогают понять логику подобной стратегии. Разумеется, в краткосрочной перспективе вы потеряете деньги. Но зато вы избавитесь от существенных когнитивных затрат. Как только вы начнете воспринимать такие затраты более серьезно, вам станет проще отказаться от работы с клиентами, которые наносят существенный урон вашей психике и не компенсируют его ростом дохода вашей компании.

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

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

Ответ на этот вопрос мы получим, обратившись к истории электронной почты, вернее, к одному из ее первых прототипов. В начале 1960-х компьютеры всё еще были громоздкими и дорогими агрегатами. Для них требовались отдельное помещение и бригада по их обслуживанию. Приходилось ждать своей очереди, чтобы воспользоваться этой махиной в надежде на то, что нужная программа (в виде перфорированных карточек, вероятнее всего) сработает, пока ваше время еще не вышло. Инженеров Массачусетского технологического института существующая ситуация раздражала, и они решили, что должен быть более оптимальный способ совместного использования оборудования. Предложенное ими решение было запущено в вычислительном центре Массачусетского технологического института в 1961 году и называлось «Совместимая система с разделением по времени» (CTSS). Оно предлагало нечто революционное в сфере информационных технологий: многочисленные пользователи могли одновременно работать, подключившись к главному компьютеру с помощью терминальных машин. Это не означает, что пользователи в буквальном смысле использовали ресурсы главного компьютера. Во время работы совместимая система с разделением по времени быстро переключалась между пользователями, производя вычисления для одного из них, затем для другого и так далее. Но у пользователей возникало ощущение, что они используют компьютер единолично.

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