Яндекс.Метрика

    Песочница

    Увеличение эффективности службы поддержки

    Нет худа без добра.
    Но это добро надо найти и
    суметь им воспользоваться.

    На мысль написать эту статью меня навели очередные глобальные проблемы в Рунете, случившиеся в прошедшие выходные. Утром в субботу обнаружил, что лицо приятеля в скайпе дёргается, а голос дрожит и прерывается. Появились и другие признаки плохой связи. Естественно, прежде чем звонить в техподдержку, протрассировал подозрительные адреса и понял, – звонить бесполезно, проблема в Москве. Там в сети пробки, как на улицах. Скорее всего, опять чей-то кортеж пропускают.

    Как развернуть ситуацию в свою пользу?


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

    Но из этой, казалось бы, безвыходной ситуации есть простой выход. Надо дать в руки разъяренному абоненту возможность самому проверить, где находится «бутылочное горлышко», привлечь его к сотрудничеству.
    Понятно, что рекомендовать воспользоваться какой либо из стандартных программ вроде NetTest или Tracer нереально. На загрузку и установку программ нет времени. И тут на помощь приходит команда, которую 90% абонентов не знают, а остальные 10% не используют.

    Оператор поддержки должен научить обратившихся абонентов пользоваться имеющейся на каждом компьютере командой tracert, чтобы они сами могли трассировать проблемные маршруты и определять, где происходит задержка. Это легко сделать прямо по телефону.
     
    Алгоритм прост:
    Нажать «Пуск» – «Выполнить».
    В открывшемся окошке набрать cmd.exe и нажать «ОК».
    В открывшемся окне набрать tracert пробел проблемный адрес или URL и нажать «Enter».
    В худшем случае это занимает 1-2 минуты.
    В ответ в окне появляется трассировка:
     
    >tracert www.gmail.com
     
    Трассировка маршрута к googlemail.l.google.com [209.85.148.19]
    с максимальным числом прыжков 30:
     
      1     1 ms    <1 мс    <1 мс  Alpha.Home [192.168.1.1]
      2    27 ms    27 ms    26 ms  yek-blh50321-as3.foratec.net [84.254.192.10]
      3    27 ms    27 ms    27 ms  84.254.192.142
      4    26 ms    26 ms    26 ms  br2-10ge0-0-0-vl128.blh.yek.foratec.net [84.254.192.149]
      5    30 ms    27 ms    26 ms  EBG15.ebg29.transtelecom.net [217.150.38.26]
      6    81 ms    56 ms    91 ms  72.14.215.210
      7   100 ms   100 ms   101 ms  72.14.215.209
      8   102 ms   101 ms   101 ms  209.85.241.44
      9   111 ms   111 ms   111 ms  72.14.234.11
     10   107 ms   106 ms   106 ms  72.14.239.63
     11   113 ms   107 ms   106 ms  209.85.254.41
     12   111 ms   110 ms   111 ms  fra07s07-in-f19.1e100.net [209.85.148.19]
     
    Трассировка завершена.
     
    (Естественно, оператор в это время проделывает те же операции).

    Остаётся пояснить абоненту, что означают полученные строчки:

    Первая строка – путь от компьютера до ASDL модема, задержка меньше миллисекунды.

    2-я – путь от модема до сети провайдера, 27 миллисекунд – характерное для ADSL время отклика.

    3-я и 4-я – путь по сети провайдера (foratec) – дополнительных потерь времени нет, время передачи по сети провайдера – менее 1 миллисекунды (разница между строчками).

    5-я – выход на граничный маршрутизатор провайдера верхнего уровня (transtelecom). Здесь дополнительных потерь тоже нет, то есть провайдер не экономит на внешнем канале.

    С 6-й по 12-ю – путь до искомого адреса, здесь потери втрое больше, чем от ADSL и на два порядка больше, чем на сети провайдера.

    Что и требовалось доказать.

    Но главный эффект даже не в этом. За время совместной работы клиент не только остывает, но и в какой-то мере сближается с оператором.
     

    Знание психологии убивает четырёх зайцев


    Использование службой поддержки такого психологического по сути приёма позволяет не только разрешить конфликтную ситуацию и «закрепить» клиента за компанией, но и превращает аварийную ситуацию в своеобразную рекламную компанию.

    Одним выстрелом «убивается» даже не два, а сразу четыре зайца:

    • Клиент убеждается, что его провайдер не виноват в проблемах (агрессия сменяется некоторым чувством вины за первоначальную резкость);
    • Клиент убеждается, что провайдер внимательно относится к его нуждам (формируется положительный образ компании);
    • Клиент делится своим умением с друзьями, снижая тем самым нагрузку на службу поддержки (при этом показывает свои знания и растёт в своих глазах);
    • Клиент делится с друзьями положительным мнением о своём провайдере, по сути, бесплатно рекламирует компанию, причём самым действенным прямым способом (опять же при этом самоутверждается, мол, вот как разумно я выбрал провайдера).


    Описанный приём применяла служба поддержки фирмы, где я работал. Фирма работала под девизом: «Качество наших услуг стоит Ваших денег». Качество действительно было хорошим. Но и цены были в полтора раза выше, чем у конкурентов, что не помешало компании ежегодно удваивать объём услуг. Немалую роль в этом сыграла работа службы поддержки. В то время (лет 5-10 лет назад) проблемы в Рунете возникали часто – сетевые гранды воевали между собой, при этом Рунет разваливался на куски, связанные только через зарубежные каналы. И описанная «реклама» работала в полную силу. После каждого такого случая число новых клиентов заметно нарастало.

    Заключение


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