Чтобы получить метро, мало трамвай в землю закопать. Чтобы получить эффективный интернет-сайт, мало сделать набор скриптов и вывалить его в сеть. Интернет-сервис – это не просто цифровая логика «если – то», это ещё и большая работа по интеграции системы, проверке её надёжности и тщательный отбор формулировок, с помощью которых ведётся общение с пользователем. Давайте посмотрим, как бывает, когда об этом думают недостаточно.
Вернулся из Красноярска, где выступал на Второй Красноярской конференции по интернет-технологиям (К слову, привет «Веб-Альянсу» и спасибо за отличную атмосферу мероприятия!).
Летел туда и обратно бывшей «Сибирью», ныне «S7 Airlines». Вылет из Москвы утром, добираться до аэропорта долго, учитывая запас на регистрацию придётся встать совсем рано. Естественно – лень. И тут – о чудо, сервис! На сайте авиакомпании написано, что регистрацию можно пройти онлайн, начиная за сутки до вылета. Отличная новость!
И вот открываем сайт, вводим номер электронного билета, выбираем аэропорт отправления, видим свою фамилию, регистрируемся. Следующий шаг – распечатка посадочного талона. И тут связь с сайтом рвётся. Обновляем страницу, снова вводим номер билета – сайт надолго задумывается:
А потом неожиданно огорошивает:
Повторяем несколько раз, но результат не меняется. Не теряем бодрости духа, звоним в поддержку. В поддержке сообщают, что «видимо, на сайте сейчас какие-то работы ведутся», поэтому сайт недоступен и они тоже не могут туда зайти, чтобы выслать мне файл с посадочным талоном. Но ничего страшного – нужно приехать в аэропорт заранее и там регистрацию завершить.
Всего у меня ушло около трёх часов на разные попытки зарегистрироваться онлайн, включая несколько звонков в поддержку, т.к. после долгих расспросов и попыток зайти со своей стороны операторы рекомендовали «перезвонить попозже, может заработает». Плюс то время, которое в итоге так и не удалось сэкономить в аэропорту. В итоге заявленный сервис обернулся чем-то противоположным.
Впрочем, вся эта заметка вовсе не за ради пожаловаться. У нас же дидактические задачи, к ним и перейдём.
Итак, какие проблемы мы можем отметить в организации данного сервиса онлайн-регистрации?
Первое – по какой-то причине не удалось добиться стабильной работы сервиса. Либо глючило «само по себе», что беда, либо, как говорили операторы, «проводились работы», что вообще ни в какие ворота не лезет, т.к. белый день и вполне себе много посетителей.
Поэтому помечаем – если мы запускаем проект, который обеспечивает сервис нашим клиентам, он должен работать «при любой погоде». Иными словами – всегда, и всегда хорошо и стабильно. Проблемы с функционированием такого проекта стоит считать критическим событием, а не относиться к этому спокойно и расслабленно (полежит-полежит, да и встанет…). Соответственно, оператор, столкнувшись с проблемой, должен был сообщить о ней «группе быстрого реагирования», а та, в течение максимально сжатого срока проблему устранить. При этом, все другие операторы должны были получить уведомление о проблеме и прогнозе по восстановлению работоспособности, чтобы оперативно ориентировать клиентов.
В приведённом примере сервис был неработоспособен не менее 14 часов, специально проверил поздно вечером.
Второе. Из всех возможны способов сообщения об ошибке выбран самый, наверное, неудачный. Смотрите ещё раз:
Нас внятным человеческим языком уведомляют, что обработать запрос не могут. При этом, нет никаких пояснений или предположений о причинах. Просто «ну не шмогла». Что может думать пользователь? Например – что его электронный билет «вылетел» из базы. Почему бы и нет? Добавит ли такая мысль спокойствия клиенту?
Забавно, что любое неудобочитаемое техническое сообщение в данной ситуации оказалось бы лучше – оно сразу бы указывало на техническую проблему.
Записываем: Информационные сообщения сервиса должны быть максимально конкретны и не заставлять пользователя гадать и придумывать себе разные страшилки. В данном случае первая часть этой фразы могла звучать, например, так: «Ваш запрос не удалось обработать из-за технических причин». Но это ещё не вся фраза, поэтому дальше – третье.
Третье. Пользователь оставлен наедине с этим сообщением. Что ему делать дальше? «Мы не смогли обработать» – а что мне-то делать? Использованная формулировка звучит даже как-то апокалиптично – мы не смогли, и никто не сможет. И никогда. Пользователю предлагается единственно возможный вариант – уйти (кнопка «Выход») и больше не грузить «нас» своими непомерными запросами.
Фиксируем: Сообщение об ошибке должно обязательно содержать инструкцию по дальнейшим действиям. Например: «Ваш запрос не удалось обработать из-за технических причин, попробуйте повторить его через некоторое время. Если проблема сохранится, обратитесь в нашу службу поддержки.» И кнопки – «Повторить», возвращающая к начальной форме, «Поддержка», ведущая на страницу контактов, и «Выход», раз уж без него никак.
Четвёртое. В приведённой ситуации обе стороны – и клиент, и оператор техподдержки, имели общий инструмент, веб-ориентированное приложение, которое, заглючив, лишило первого возможности воспользоваться сервисом, а второго – помочь в этом вопросе. Представляется, что при организации подобного сервиса должны быть предусмотрены разделённые инструменты, дублирующие друг-друга, позволяющие «в ручном режиме» довести проблему до разрешения.
Итак, резюме.
В заголовке не случайно стоит слово «лояльность». Именно такие «мелочи», как глючные, недодуманные сервисы, в теории призванные облегчить жизнь клиента, а на практике создающие ему лишние проблемы и трудности, и влияют на последующее отношение.
Обломившийся в своих ожиданиях клиент становится негативно предвзятым и начинает интерпретировать в этом смысле все проявления компании. И транслировать своё неудовольствие дальше – в разговорах, в блоге, на форумах. Или в дидактических статьях по маркетингу :)
Поэтому помните, что, заявляя некий сервис, вы не просто делаете прикольную штуку. Вы создаёте новый тип отношений, берёте на себя новые обязательства, порождаете новый инструмент управления лояльностью. Пользователи, довольные вашим сервисом, будут становиться лояльнее. И рекомендовать другим. А наоборот – наоборот.
Вернулся из Красноярска, где выступал на Второй Красноярской конференции по интернет-технологиям (К слову, привет «Веб-Альянсу» и спасибо за отличную атмосферу мероприятия!).
Летел туда и обратно бывшей «Сибирью», ныне «S7 Airlines». Вылет из Москвы утром, добираться до аэропорта долго, учитывая запас на регистрацию придётся встать совсем рано. Естественно – лень. И тут – о чудо, сервис! На сайте авиакомпании написано, что регистрацию можно пройти онлайн, начиная за сутки до вылета. Отличная новость!
И вот открываем сайт, вводим номер электронного билета, выбираем аэропорт отправления, видим свою фамилию, регистрируемся. Следующий шаг – распечатка посадочного талона. И тут связь с сайтом рвётся. Обновляем страницу, снова вводим номер билета – сайт надолго задумывается:
А потом неожиданно огорошивает:
Повторяем несколько раз, но результат не меняется. Не теряем бодрости духа, звоним в поддержку. В поддержке сообщают, что «видимо, на сайте сейчас какие-то работы ведутся», поэтому сайт недоступен и они тоже не могут туда зайти, чтобы выслать мне файл с посадочным талоном. Но ничего страшного – нужно приехать в аэропорт заранее и там регистрацию завершить.
Всего у меня ушло около трёх часов на разные попытки зарегистрироваться онлайн, включая несколько звонков в поддержку, т.к. после долгих расспросов и попыток зайти со своей стороны операторы рекомендовали «перезвонить попозже, может заработает». Плюс то время, которое в итоге так и не удалось сэкономить в аэропорту. В итоге заявленный сервис обернулся чем-то противоположным.
Впрочем, вся эта заметка вовсе не за ради пожаловаться. У нас же дидактические задачи, к ним и перейдём.
Итак, какие проблемы мы можем отметить в организации данного сервиса онлайн-регистрации?
Первое – по какой-то причине не удалось добиться стабильной работы сервиса. Либо глючило «само по себе», что беда, либо, как говорили операторы, «проводились работы», что вообще ни в какие ворота не лезет, т.к. белый день и вполне себе много посетителей.
Поэтому помечаем – если мы запускаем проект, который обеспечивает сервис нашим клиентам, он должен работать «при любой погоде». Иными словами – всегда, и всегда хорошо и стабильно. Проблемы с функционированием такого проекта стоит считать критическим событием, а не относиться к этому спокойно и расслабленно (полежит-полежит, да и встанет…). Соответственно, оператор, столкнувшись с проблемой, должен был сообщить о ней «группе быстрого реагирования», а та, в течение максимально сжатого срока проблему устранить. При этом, все другие операторы должны были получить уведомление о проблеме и прогнозе по восстановлению работоспособности, чтобы оперативно ориентировать клиентов.
В приведённом примере сервис был неработоспособен не менее 14 часов, специально проверил поздно вечером.
Второе. Из всех возможны способов сообщения об ошибке выбран самый, наверное, неудачный. Смотрите ещё раз:
Нас внятным человеческим языком уведомляют, что обработать запрос не могут. При этом, нет никаких пояснений или предположений о причинах. Просто «ну не шмогла». Что может думать пользователь? Например – что его электронный билет «вылетел» из базы. Почему бы и нет? Добавит ли такая мысль спокойствия клиенту?
Забавно, что любое неудобочитаемое техническое сообщение в данной ситуации оказалось бы лучше – оно сразу бы указывало на техническую проблему.
Записываем: Информационные сообщения сервиса должны быть максимально конкретны и не заставлять пользователя гадать и придумывать себе разные страшилки. В данном случае первая часть этой фразы могла звучать, например, так: «Ваш запрос не удалось обработать из-за технических причин». Но это ещё не вся фраза, поэтому дальше – третье.
Третье. Пользователь оставлен наедине с этим сообщением. Что ему делать дальше? «Мы не смогли обработать» – а что мне-то делать? Использованная формулировка звучит даже как-то апокалиптично – мы не смогли, и никто не сможет. И никогда. Пользователю предлагается единственно возможный вариант – уйти (кнопка «Выход») и больше не грузить «нас» своими непомерными запросами.
Фиксируем: Сообщение об ошибке должно обязательно содержать инструкцию по дальнейшим действиям. Например: «Ваш запрос не удалось обработать из-за технических причин, попробуйте повторить его через некоторое время. Если проблема сохранится, обратитесь в нашу службу поддержки.» И кнопки – «Повторить», возвращающая к начальной форме, «Поддержка», ведущая на страницу контактов, и «Выход», раз уж без него никак.
Четвёртое. В приведённой ситуации обе стороны – и клиент, и оператор техподдержки, имели общий инструмент, веб-ориентированное приложение, которое, заглючив, лишило первого возможности воспользоваться сервисом, а второго – помочь в этом вопросе. Представляется, что при организации подобного сервиса должны быть предусмотрены разделённые инструменты, дублирующие друг-друга, позволяющие «в ручном режиме» довести проблему до разрешения.
Итак, резюме.
В заголовке не случайно стоит слово «лояльность». Именно такие «мелочи», как глючные, недодуманные сервисы, в теории призванные облегчить жизнь клиента, а на практике создающие ему лишние проблемы и трудности, и влияют на последующее отношение.
Обломившийся в своих ожиданиях клиент становится негативно предвзятым и начинает интерпретировать в этом смысле все проявления компании. И транслировать своё неудовольствие дальше – в разговорах, в блоге, на форумах. Или в дидактических статьях по маркетингу :)
Поэтому помните, что, заявляя некий сервис, вы не просто делаете прикольную штуку. Вы создаёте новый тип отношений, берёте на себя новые обязательства, порождаете новый инструмент управления лояльностью. Пользователи, довольные вашим сервисом, будут становиться лояльнее. И рекомендовать другим. А наоборот – наоборот.
