Новые принципы делового общения. Как сфокусироваться на главном в эпоху коммуникативной перегрузки
Шрифт:
Решением проблемы стало создание тщательно продуманного клиентского портала. У каждого заказчика были логин и пароль, которые они использовали для входа. На портале они находили подробную информацию о своем проекте. Можно было ознакомиться с образцами дизайна и предварительной версией сайта, а также заглянуть в календарь, где были отмечены основные этапы реализации проекта. В «журнале работ» ежедневно появлялась информация о задачах, выполненных в каждый конкретный день. Большая часть реального общения сводилась к специальным встречам, которые были приурочены к конкретным этапам проекта. По итогам каждой встречи составлялась памятка, в которой указывалось, какие решения были приняты. И мы просили клиентов подписать эти памятки, чтобы выразить свое согласие. (Поскольку поняли, что это снижает вероятность того, что клиент впоследствии передумает, когда мы уже будем в процессе разработки.) У нас была возможность прикрепить сканы подписанных памяток на портал.
Мы никогда не объясняли клиентам, что необходимость в портале возникла потому, что мы целый день в школе (хотя,
Разумеется, мы не были единственными, кто придумал умную систему общения с клиентами. В главе 1 я рассказывал историю Шона , который реорганизовал работу в своей маленькой технологической компании. В его случае наиболее раздражающим фактором была чрезмерно активная коммуникация с клиентами, которая и стала для него переломным моментом. События стали стремительно развиваться, когда особенно требовательный клиент потребовал доступ к их каналу в Slack, предназначенному для внутреннего общения. В результате звук уведомлений этого мессенджера стал постоянным шумовым фоном, а каждое сообщение от клиента приносило новую головную боль. Неудивительно, что в итоге Шон решил заменить гиперактивный коллективный разум какими-то более оптимальными рабочими процессами. И одной из сфер его внимания стало общение с клиентами.
Сотрудники компании стали добавлять в каждое техническое задание раздел под названием «Коммуникация». «Мы хотим, чтобы клиент был в курсе до начала работы над проектом», — пояснил Шон. В этом новом разделе описывались правила коммуникации клиента и сотрудников компании, в том числе — и на этом Шон сделал акцент — как вести себя, если возник срочный вопрос. В большинстве случаев стандартная процедура предусматривала еженедельную телефонную конференцию с заказчиком по заранее согласованному расписанию. После этого в письменном виде кратко подводились итоги конференции, и документ отправляли заказчику. Бизнес-партнер Шона, который отвечал за взаимоотношения с клиентами, был обеспокоен этим нововведением. «Он боялся, что заказчики будут недовольны. Ведь работа нашей компании построена на общении с пользователями, и это общение должно быть высокопрофессиональным, — объяснил Шон. — Но уровень удовлетворенности клиентов существенно вырос. Весь секрет в управлении ожиданиями».
И Шон, и я в своей компании в 1990-е использовали оптимизированный протокол коммуникации, чтобы управлять обменом информацией между клиентами и сотрудниками компании (хотя мы и не использовали именно такую терминологию). Благодаря этому нам удалось существенно снизить средние затраты на координацию работы. Я изучил и другие примеры протоколов общения с клиентами и хочу дать несколько рекомендаций, которые помогут сделать взаимодействие успешным.
Прежде всего, стремясь сократить затраты, думайте не только о собственных ресурсах, но и о ресурсах клиента. Ключевой фактор, который помогает клиентскому протоколу работать, — снижение когнитивных затрат или устранение неудобств, в том числе для клиента. На самом деле немногие из них любят бесконечно отправлять вам сообщения. Часто они вынуждены это делать, поскольку не знают, как еще можно с вами связаться или убедиться в том, что работа будет выполнена. По опыту Princeton Web Solutions я понял, что структурированный интерфейс портала не раздражал клиентов. Наоборот, они успокаивались, поскольку им не приходилось тратить когнитивную энергию, переживая, будет ли выполнена работа. И напротив, если вы внедрите такую схему коммуникации, которая упростит жизнь вам, но усложнит ее вашим клиентам, вам будет намного сложнее продавать свои услуги, и не без причины. (Приведу яркий пример: каждый раз, когда заказчику что-то нужно, вы требуете, чтобы он направил вам подробный запрос по факсу.)
Еще один важный момент — ясность. Сотрудники компании Шона добавляли подробное описание протокола общения с клиентами в каждое техническое задание, а заказчик его подписывал. Очень разумно. Если бы сотрудники просто предлагали клиентам еженедельные конференции в качестве варианта коммуникации, высок шанс, что заказчики при малейших проблемах автоматически вернулись бы к гиперактивному общению. Когда же все предусмотрено договором, клиент, скорее всего, немного пострадает из-за незначительных неудобств. Но со временем он осознает все преимущества, связанные с более низкими средними затратами более жесткой системы.
И наконец, несмотря на все ваши усилия, всегда найдутся клиенты, для которых определенные протоколы просто не работают. Я общался с консультантом по коммуникациям в Вашингтоне, округ Колумбия. Она работала в магазине, где трудились 12 человек. Она рассказала, что при работе со многими клиентами они использовали подход, похожий на метод Шона: еженедельный созвон, по итогам которого составлялся письменный отчет. Однако общение с другими клиентами проходило по иной, «антикризисной» схеме. С ними необходимо было незамедлительно связываться, если рекламная кампания шла не по плану. Именно поэтому протокол общения с ними выглядел просто: «Если что-то случилось — сразу звоним клиенту». Другими словами, от характера работы зависит, какой именно протокол будет использоваться.
Разработанные вами процедуры также могут не подойти для отдельно взятых людей, и это обусловлено не характером работы, а их индивидуальными особенностями.
Иначе выражаясь, я говорю о тех выродках, которым нравится ко всему придираться, чтобы почувствовать собственную важность. Подобную ситуацию описал Тим Феррис в своем бестселлере «Как работать по 4 часа в неделю». Описывая преобразования, которые он осуществил в своей дочерней компании BrainQuicken, Тим рассказал, как «дал отставку» одному из наиболее воинственных и вгоняющих всех в стресс клиентов. Идея, что можно прекратить работу с токсичным клиентом, задевает за живое. «Этот абзац меня шокировал», — вспоминает Тоби Лютке, генеральный директор IT-компании Shopify, в кратком очерке о Феррисе, который появился в журнале Inc. «Если вы пойдете в бизнес-школу и предложите там избавиться от клиента, вас просто выгонят. Но, исходя из своего опыта, могу сказать, что предложение очень разумное. Такая политика позволяет определить, с кем из клиентов вы действительно хотите работать» [158] . Идеи Клода Шеннона помогают понять логику подобной стратегии. Разумеется, в краткосрочной перспективе вы потеряете деньги. Но зато вы избавитесь от существенных когнитивных затрат. Как только вы начнете воспринимать такие затраты более серьезно, вам станет проще отказаться от работы с клиентами, которые наносят существенный урон вашей психике и не компенсируют его ростом дохода вашей компании.158
Первоначально компания называлась Princeton Internet Solutions. Однако мы с Майклом вскоре поняли, что аббревиатура получается не слишком удачная.
Подводя итоги, могу сказать: если вы работаете с заказчиками, для отказа от гиперактивного коллективного разума необходим оптимизированный клиентский протокол.
Некоторые сферы нашей жизни уже настолько привычны, что нам сложно представить, что может быть по-другому. Один из таких примеров — стандартный формат электронного адреса: фамилия@название_компании. В нем есть нечто элегантное. Когда вы отправляете электронное послание, лежащий в основе работы сервиса протокол направляет его в ту организацию, которая указана в электронном адресе. Когда письмо попадает в сеть организации, почтовый сервер доставляет его адресату, указанному слева от символа @. И именно такую систему — что в адресе должен быть указан конкретный сотрудник — мы принимаем как должное. Но если мы несколько отстранимся и посмотрим на ситуацию свежим взглядом, возникает интригующий вопрос: почему получатель — всегда конкретный сотрудник? Почему бы не указывать в адресе какой-то отдел, команду проекта или вид деятельности?
Ответ на этот вопрос мы получим, обратившись к истории электронной почты, вернее, к одному из ее первых прототипов. В начале 1960-х компьютеры всё еще были громоздкими и дорогими агрегатами. Для них требовались отдельное помещение и бригада по их обслуживанию. Приходилось ждать своей очереди, чтобы воспользоваться этой махиной в надежде на то, что нужная программа (в виде перфорированных карточек, вероятнее всего) сработает, пока ваше время еще не вышло. Инженеров Массачусетского технологического института существующая ситуация раздражала, и они решили, что должен быть более оптимальный способ совместного использования оборудования. Предложенное ими решение было запущено в вычислительном центре Массачусетского технологического института в 1961 году и называлось «Совместимая система с разделением по времени» (CTSS). Оно предлагало нечто революционное в сфере информационных технологий: многочисленные пользователи могли одновременно работать, подключившись к главному компьютеру с помощью терминальных машин. Это не означает, что пользователи в буквальном смысле использовали ресурсы главного компьютера. Во время работы совместимая система с разделением по времени быстро переключалась между пользователями, производя вычисления для одного из них, затем для другого и так далее. Но у пользователей возникало ощущение, что они используют компьютер единолично.
Затем естественным образом произошел переход от совместимой системы с разделением по времени к электронной почте. В основе CTSS лежала идея, что у каждого пользователя есть собственная папка с файлами и какие-то из них — личные, а другие доступны всем пользователям системы. Сообразительные первые пользователи системы догадались, что можно оставлять сообщения в чужих папках. К 1965 году эта операция была стандартизирована с помощью модуля MAIL, предложенного инженерами-программистами Томом Ван Влеком и Ноэлем Моррисом. С помощью этого модуля в папке каждого пользователя создавался файл под названием MAIL BOX. Когда один пользователь отправлял сообщение другому с помощью модуля MAIL, оно цеплялось к файлу MAIL BOX этого пользователя. С помощью специальных инструментов сотрудники могли читать и удалять такие сообщения.
Иными словами, первые электронные адреса ассоциировались с конкретными сотрудниками, поскольку пользовательские аккаунты в системе с разделением по времени изначально были спроектированы таким же образом. Такая практика укоренилась. Инженер Рэй Томлинсон, который, вероятно, и несет по большей части ответственность за появление адреса в формате фамилия@название_компании, ранее работал с более усовершенствованными программными модулями отправки сообщений, чем MAIL [159] .
159
Tom Foster, “Tim Ferriss’s 4-Hour Reality Check,” Inc., April 2, 2013, www.inc.com/magazine/201304/tom-foster/tim-ferriss-four-hour-reality-check.html.