Сделай сам: менеджер шаблонных ответов на любые письма – Журнал «Код» программирование без снобизма

Проблема с доставкой: что делают продавцы, когда логистика подводит

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

У нас пока не было ни одного идеального доставщика. Все когда-то долго доставляли заказ или теряли его. Например, одному клиенту с Чукотки заказ шел больше месяца. Раньше я не знал, но оказалось, что до некоторых чукотских городов посылки доставляют вертолетом раз в неделю, поэтому приходится так долго ждать. Что я мог сделать в этой ситуации? Только написать логистическому партнеру и узнать, не потерялась ли посылка и как скоро она придет. Я даже не могу вернуть клиенту деньги, потому что, пока он не получит заказ, не могу их вывести. К сожалению, логистика редко на 100 % зависит от продавца, даже если у вас личный курьер: он может заболеть и не доставить заказ.

С чего все начинается

Итак, традиционно, начнем с основ. Попробуем ответить на вопрос:

что есть служба поддержки и для чего она нужна?

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

Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:

Call-центр

которые позволяют пассажирам решать возникающие сложности.

А в компании – производителе мы имеем:

Очевидно, что попытка целиком перенести подходы в организации работ «службы поддержки», принятые в одном типе компаний, на компанию другого типа – занятие, как минимум, не умное, а зачастую и вредное.

Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.Давайте попробуем разобраться несколько подробнее.

Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает.

Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления бизнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?

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

Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.

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

И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.

Едем дальше, а как же оценивать работу сотрудников этой службы? Скоростью решения проблемы? Скорее нет, чем да, поскольку они не могут, да и не должны лезть вовнутрь конфигурации или платформы учетной системы. Поэтому немного утрируем, и получается, что их задачи тоже вполне очевидны — удостовериться, что:


Последний пункт встречается, к сожалению, все еще редко, но он весьма желателен в реальной жизни.

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

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

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании.

ремонт автобусов

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

сама решать

большинство проблем. Понимаете разницу?

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

Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.Резюмируя, мы получаем следующую картину:

Служба поддержки пользователей

Служба технической поддержки

Заказчик (потребитель услуг отдела)

Конечные пользователи

Отдел разработки/тестирования

Задачи сотрудника

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

Требования к сотруднику

Очевидно, что в реальной жизни нам приходится использовать некий компромисс и смешение этих двух противоположностей, но, тем не менее, зная эти «ингредиенты» руководитель уже сможет подготовить свой собственный рецепт, наиболее полно соответствующий условиям конкретной организации, выстроить соответствующие процессы и подготовить SLA, которые будет отвечать интересам всех заинтересованных сторон (включая отдел поддержки/сопровождения).

К чему обычно приходим

Ну и в качестве бонуса, небольшой список неудачных подходов к организации работы службы поддержки.

  1. Использование чат-ботов. Последнее время эта тенденция набирает силу и многим кажется, что это отличный способ сэкономить на количестве сотрудников. При этом никто даже не задумывается о том, с какой целью люди обращаются в отдел поддержки и сопровождения. Так вот, чат-боты и прочие поисковые возможности строго необходимы, когда пользователь не может (при плохо структурированной или сложной и запутанной организации так называемой «базы знаний») или не хочет (в силу чрезмерной занятости или лени) искать информацию самостоятельно. Иными словами, только в случае, если пользователь не понимает или не может найти нужную информацию в онлайн-документации достаточно быстро, то ему в этом поможет расширенное средство поиска или чат-бот. Никаких нестандартных или технических проблем чат-бот касаться не должен. Этого, к сожалению, мало кто понимает. Конечно, есть огромное желание заставить пользователей, наконец, пользоваться документацией и статьями, размещенными на соответствующем портале, а не обращаться к сотрудникам отдела по уже расписанным и простым вопросам. Однако правильнее и проще это решается административными методами, а не попыткой все ухудшить. И второй момент, подключение службы поддержки на помощь «по каждому чиху» пользователям не самое коммерчески выгодное решение. С одной стороны, компания берет на себя ответственность за предоставляемые решения, а с другой – это ни как не компенсируется. Иными словами, такой подход отбирает хлеб у отделов внедрения/professional service.
  2. Экономия на сотрудниках. Очень популярно разделение сотрудников по квалификациям на уровни поддержки, и набор «самых тупых» (то есть самых дешевых) на первые линии поддержки. Хотя изначально подразумевалось, что деление на уровни поддержки носит функциональный а не квалификационный характер. Получается как вариант предыдущего пункта с чат-ботами. Управляющий персонал просто не в состоянии правильно организовать взаимодействие сотрудников отдела с пользователями, и пытается решить проблемы в лоб – набором большего количество сотрудников за цену, которая имеется в распоряжении. В результате качество обслуживание просто падает, и, к полной неожиданности менеджеров, нагрузка на «квалифицированных» сотрудников только возрастает.
    Я уже молчу про специальное обучение сотрудников поддержки.
  3. Использование телефона как основного способа обращения за поддержкой. Вообще, довольно странно видеть, что зачастую при организации отделов поддержки/сопровождения отдается предпочтение созданию call-центров. Если мы говорим про поддержку IT систем, то один телефонный звонок требует примерно столько же ресурсов, сколько обработка 2-3 инцидентов, поданных через портал, форум или email. Звонки иногда нужны и важны, но далеко не всегда такой дорогой (для отдела) вид коммуникации рационален и удобен именно с точки зрения организации поддержки пользователей и/или заказчиков. Даже если не вдаваться в подробности мониторинга качества продукта и/или услуг, организации комфортной коммуникации с пользователями/заказчиком, то даже вопросы доступности и распространения опыта и знаний внутри коллектива, при телефонных коммуникациях, требуют дополнительных усилий и затрат.
  4. Использование службы поддержки в роли секретариата. Иными словами, когда первая линия поддержки играет роль своего рода отдела диспетчеризации и направляет пользователей к нужным сотрудникам, в зависимости от имеющихся вопросов и возникших проблем. На самом деле это тревожный «звоночек», что в компании «что-то пошло не так». Служба поддержки хоть и является составной частью CRM (Customer Relationship Management) — системы управления взаимоотношениями с заказчиком, но является именно ее частью, а не ее подменой. Поэтому, когда заказчик обращается в службу поддержки с проблемой, что у него закончился период действия лицензии на продукт, то это значит что аббревиатура CRM в компании для галочки, а профильные отделы (в данном случае, отдел продаж) занимаются чем угодно, кроме своей прямой работы. И поэтому сотрудники поддержки/сопровождения будут работать «передастами» между заказчиком с одной стороны и коммерческим отделом, отделом лицензирования, fulfillment департаментом – с другой.
  5. Имитация «персонального» сопровождения, когда сотрудники отделов поддержки подписываются только именем, например «Мария», «Иван» и т.д. Я, конечно, понимаю, что за рубежом это рядовое явления и, с одной стороны, намекает на «теплые дружеские отношения», а с другой — несколько тешит самолюбие западных пользователей (слуги не имели фамилий), но даже там это имеет смысл только в очень редких случаях. В практике IT поддержки это создает только трудности. Простейшая ситуация: в отделе четыре человека носят имя «Алексей» (реальный случай), при этом в силу обстоятельств в офисе присутствует только один из них (второй — в отпуске, третий — заболел, четвертый — в командировке) и возникает проблема по одному из инцидентов, который обслуживался неким «Алексеем». Как положено, тот, кто в офисе, понятия не имеет о чем идет речь. Что делать супервайзеру/лидеру или начальнику отдела, если заказчик ссылается на некие устные рекомендации, полученные от «Алексея»?

    С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
    Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкретному инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.

  6. Создание отделов «Customer Success», «Technical Enablement» и прочих «Fulfillment». Опять же, это мода последнего времени, в основном связанная с восторгом от «Agile» методов ведения разработки и является попыткой наладить обратную связь, что называется, «в лоб». К сожалению, в реальности это обычно является показателем того, что потерпев неудачу в организации нормальной работы как отделов внедрения, обучения, сопровождения/поддержки пользователей в частности, так и во внедрении CRM методов – вообще, люди начали лепить рядом с кое-как уже работающими отделами, новую дублирующую службу. Увы, довольно часто с тем же успехом.
  7. «Карго-культ» ITIL/ITSM. По факту — это самая большая проблема организации работы служб поддержки. Артефакты фреймворка требуют достаточно глубокого анализа перед их внедрением и четкого понимания, что мы делаем, ради чего, как и почему именно так. Для примера, возьмем CMDB – базу данных конфигурации/настроек и истории их изменений. Рассмотрим простой вопрос: какую информацию/атрибуты и их изменения нам нужны в случае, если мы осуществляем поддержку некой бизнес-платформы (допустим, учетной системы)? Есть соблазн туда добавить все, что только можно, но для компаний уровня «1С», с десятками тысяч заказчиков – это превратит систему в могильник никому ненужных деталей.

    Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.

    Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.

  8. «Кривые» KPI. Этот пункт идет «вне конкурса», как и все метрики эффективности вообще. То, что они нужны – теперь уже понимают все. Но вот вопросы: «для чего?» и «какие именно?» – являются уже «вопросами на засыпку» для подавляющего числа управленцев. Так же обстоит дело и в случае оценки эффективности работы отделов поддержки/сопровождения. Простейший пример: как оценить полезность отдельно взятого сотрудника отдела? Количеством обработанных инцидентов? Если да, то значит ли это, что 100 решенных проблем за неделю лучше, чем 10? В реальной жизни – далеко не значит. Эти 10 инцидентов могут быть настолько сложными и важными, а та сотня – просто самыми легкими, что сравнивать в лоб количества – просто бессмысленно. К огорчению, мало кто вспоминает, что сутью KPI является численная характеристика для рутинных, повторяющихся и однотипных работ/процессов. Поэтому в числах отобразить вклад сотрудников поддержки не так уж и легко, как кажется на первый взгляд и он будет выражаться некой интегральной метрикой.

    Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.

Как сделать на сайте поддержка онлайн (online)

Содержание страницы

Как сделать на сайте – Поддержка онлайн

Описание файлов в архиве

Сначала создадим у себя на сервере в главной директории (где главная страница) новую папку с названием – webim. Затем в эту папку необходимо закачать из нашего online.zip архива – mibew164.zip. Далее мы здесь же на сервере распакуем (разархивируем) наш закачанный архив, и в результате чего у нас в папке webim образуются 7 папок и 16 файлов.

База данных для – Поддержка Online

Наши дальнейшие действия

Изменения в config.php

<?php 
    $mysqlhost = "localhost";
    $mysqldb = "webim_db";         //изменяем на имя вашей базы данных
    $mysqllogin = "webim_lite";    //изменяем на ваше имя пользователя
    $mysqlpass = "123";            //изменяем на ваш пароль
    $mysqlprefix = "";

    $webim_mailbox = "webim@yourdomain.com"; //изменяем на ваш e-mail
    $mail_encoding = "utf-8";

    $home_locale = "en";          //изменить на "ru"
    $default_locale = "en";       //изменить на "ru"
>

Теперь переходим к инсталляции нашего скрипта. В адресной строке браузера напишите вот этот адрес:

http://ваш_сайт/webim/install/

и перейдите по этому адресу, нажав ввод. На открывшейся странице нажмите на “

Next step

“, а точнее на ссылку – “

Create required tables

На этой странице мы можем уже войти в админ панель, НО не спешите. Внизу страницы у нас выделенный красным цветом текст – Обязательно удалите папку “install”, что мы сейчас в первую очередь и сделаем. После того, как эту папку удалили, переходим на страницу для входа в админ панель. В правой её части проставляем Логин: admin, Пароль – оставляем пустым и нажимаем на Войти.

Перед тем, как будем рассматривать Админ панель, зайдите:

Папка webimПапка locales.

Настройки в Админ панели для – Поддержка Online

Заполнение данных

Описание функций

Сделай сам: менеджер шаблонных ответов на любые письма - Журнал «Код» программирование без снобизма

стрелка вниз Скачать скрипт Поддержка онлайн ( online )

Настройка на волну пользователя

Представьте ситуацию: вы админ, и произошла трагедия – упал важный сервер, вам каждые 5 минут названивает начальник и все сотрудники по очереди, чтобы выяснить, когда же все починится. В этой стрессовой ситуации внезапно выясняется, что восстановление бэкапа на новое железо не работает.

Вы звоните в техподдержку программы, ответственной за восстановление, и достаточно эмоционально и быстро (сроки-то поджимают) объяснять свою проблему. На том конце провода вы слышите медленный размеренный голос специалиста, который флегматично следует заученным шаблонам и для начала спрашивает ваш идентификационный номер клиента (поддержка-то платная) и очень медленно начинает выяснять детали проблемы.

Что же произошло? Клиент позвонил с крайне важной для него проблемой, он возбужден и ему необходимо соответствующее отношение. Специалист же не попытался войти в положение и просто следовал стандартным шаблонам, произнося все фразы медленно, размеренно, как он привык, без учета настроения клиента. Здесь важна именно интонация голоса и общий настрой. Например (К=клиент, С=специалист):

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

Неправильный ответ:

С: Сообщите, пожалуйста, ваш идентификационный номер клиента. Мне необходимо занести его в базу данных для корректной обработки обращения. Если проверка пройдет успешно, то мы сможем приступить к решению проблемы.

Клиент сразу же замечает, что для специалиста проблема не важна, а важен в первую очередь формальный процесс. Плюс клиент обращает внимание (подсознательно) на то, что, несмотря на очевидно критическую проблему, специалист продолжает общаться все в том же нейтральном тоне, как будто ему все равно.

Правильный ответ:

С: Окей, я понял срочность проблемы, и мы попытаемся ее решить как можно скорее. Мне понадобится ваш идентификационный номер клиента для того, чтобы правильно обработать ваше обращение, но мы можем пропустить этот этап с учетом важности проблемы. Расскажите, пожалуйста, симптомы.

Специалист сразу дает понять, что ему не все равно, и он это показывает не словом, но делом. Важно, чтобы данная фраза произносилась опять же не нейтральным тоном, а следуя интонации клиента. Конечно же не нужно сразу возбужденно кричать и бить себя левой пяткой в грудь, но смещение интонации в сторону более эмоциональной жизненно важно.

Начните с себя

Если вы специалист, вам периодически будут попадаться элементарные (с вашей точки зрения) вопросы, которые кроме раздражения (ведь ответ давался уже 100500 раз) ничего не вызывают. Это отношение нужно менять — люди, достучавшиеся до специалиста, ждут помощи и действительно не знают ответа на какие-то вопросы, пусть даже ответ выдается в первой строке поиска в Google.

Уважение к клиенту — основополагающий принцип, следуя которому, можно успешно вести диалог с лицами любого уровня образованности и компетентности (даже с гопниками на улице уровня «Э, слыш, сюда иди да!»). Это уважение идет в первую очередь изнутри, даже если вы не показываете его напрямую, по косвенным признакам (интонация, обороты речи) клиент всегда будет ощущать реальное отношение к себе.

Пример из жизни: В воскресенье в 8 утра после бессонной ночи ехал на машине (спал 3 часа, так что вид соответствующий), и меня остановил товарищ в погонах с красно-синей мигалкой на борту. Говорит, дескать, что-то вы плохо выглядите. Давайте откроем багажник, произведем внешний осмотр и, если не возражаете, проедем на освидетельствование. Какие у меня были варианты?

1) Отказаться, настоять на присутствии понятых (в общем, полезть в бутылку и пойти на эскалацию конфликта)2) Позволить произвести внешний осмотр, пусть даже и не совсем законный без присутствия понятых.

Войдя в положение сотрудника нашей доблестной полиции, я мог его понять – какой-то странный чел за рулем, весь помятый, глаза красные, руки дрожат. И я постарался донести до него свое уважение и понимание.

– Да, я вас прекрасно понимаю, выгляжу я не очень – слишком мало спал, но нужно было ехать по делам, несмотря ни на что. Сейчас еду домой поспать. Если хотите, я могу с вами проехать до медицинского центра на освидетельствование, я не возражаю, т.к. действительно мой вид вызывает подозрения.

На что получил ответ:

– Действительно, выглядите вы не слишком хорошо, но общаетесь вполне здраво, поэтому я вас отпущу. Езжайте домой, поспите. Счастливой дороги!

События, в зависимости от моих ответов, могли пойти по совершенно другому сценарию, ведущему к лишним нервам и потере времени. Но, избегая раздражения на сотрудника полиции (уважая его решение и выводы), понимая его «проблему», мне удалось избежать эскалации ситуации и свести диалог к успешному окончанию.

Некомпетентные сотрудники

Некомпетентные сотрудники — это, на первый взгляд, главная причина проблем с технической поддержкой. Неприемлемо, когда ты ждёшь решения своей проблемы или хотя бы корректного перенаправления на специалиста, а получаешь полное игнорирование сути вопроса и немножко рекламы в придачу. Однако не стоит бросаться обвинять специалистов службы поддержки — как правило, корень этой проблемы лежит гораздо глубже.

Подбор неквалифицированных кадров — первая ошибка компаний. Понятное дело, что если вы не DevOps-аутсорсер с приличными предложениями соискателям, к вам не пойдут высококвалифицированные системные администраторы и инженеры. Но и набирать «студентов 1 и 2 курса в свободное время» чревато. Это лотерея: вы можете взять своего будущего начальника саппорта или даже главного разработчика, а можете студиоза, которому и на учёбу-то плевать — всё время свободное.

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

Бестолковые сотрудники — огромная проблема многих компаний, вне зависимости от размера и сферы деятельности. Говоря о бестолковых, мы имеем ввиду неграмотных, неквалифицированных и самое главное, не желающих что-то менять в квалификации и обучаться. Так почему компании раз за разом нарываются на таких ребят? Всё просто: довольно часто в саппорт набирают не тех, кто умеет и знает, а тех, кто подешевле, «а там научим».

Это критическая ошибка, которая приводит и к текучке кадров («не моё», «ой, какие вы все злые», «учёба важнее»), к ошибкам в работе («я ещё не научился», «ну ещё учиться, да за такие деньги я ещё и вредить вам должен!»), к бесполезным попыткам обучить («что за фигня, говорить с клиентами, я не для этого менеджмент заканчивал, хочу быть руководителем»).

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

Эти три нехитрых и честных части собеседования дадут вам представление о том, кто те люди, кого вы нанимаете на передовую, и как они представляют себя внутри вашего бизнеса.

Отсутствие обучения

Отсутствие обучения — ещё одна проблема. Да, в компании, где есть техническая поддержка (ну или просто любой customer service) всегда проводится формальное обучение: где-то это курс молодого бойца, где-то лекция на пару часов, где-то строгий начальник, который 15 минут грубо вещает о том, что компанию нужно называть исключительно Астросервис Технолоджис Групп Элэлси Компани, а имя клиента в разговоре упомянуть не менее 7 раз, остальное не столь важно.

  1. Идеальный вариант. После набора группы специалистов за каждыми 2-3 саппортёрами закрепляется наставник из числа опытных сотрудников, который проводит подробное кабинетное обучение и сразу же закрепляет знания на практике. Так информация усваивается максимально быстро и удаётся избежать разночтений.
  2. Приемлемый вариант. Аудиторное обучение проводится в несколько заходов, а старший специалист лишь отвечает на возникающие вопросы и периодически постфактум анализирует звонки/письма/чаты с новичками. В этой ситуации вероятность того, что новичок накосячит, выше.
  3. Вариант «ну хоть что-то». Как и в двух предыдущих случаях у вас сформирована база знаний, в которой содержаться типовые случаи и проблемы (ну или просто есть доступ к старым тикетам) и новый сотрудник пару недель самостоятельно разбирает ситуации, а затем сдаёт что-то вроде экзамена. Конечно, в голове что-то останется, но по эффекту похоже на прочтение книги Страуструпа без компьютера и IDE перед носом и зачётом на листочке. А потому джуниор видит компилятор и пугается его. Так и тут — телефонная гарнитура или письмо введут оператора-новичка в ступор. 


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

Примеры вежливых английских фраз для техподдержки

У меня в быстром доступе браузера всегда висел гугл-док с прозаичным названием “Вежливые фразы” — в ситуациях, когда надо было написать развёрнутое извинительное письмо он убирал всю боязнь белого листа, так как сначала набрасывался вежливый каркас, потом писались сами объяснения, почему компания поступила так, а не иначе, потом часть изначальных шаблонов убиралась.

Также видела, что ребята из моего отдела забивали некоторые фразы в макросы Zendesk, чтобы при необходимости быстро подставить. Понятно, что если будешь в каждом письме шлёпать “please accept our apologies for the inconvenience”, то скоро деградируешь всей командой, но для шаблонных ситуаций выручает. Да и отправить фоллоу-ап “привет, расскажите, попробовали ли вы предложенный нами метод и решилась ли проблема” можно в пару кликов (side note: про функционал автоматических фоллоу-апов в тикет-системах знаю, но мы у себя в отделе практиковали ручную рассылку фоллоу-апов).

Сначала ссылки на источники, где можно подсмотреть и выучить приёмы деловой переписки:

А теперь сами фразы, разделённые по категориям. Здесь стоит отметить, что я не претендую на абсолютную красоту и/или правильность своего английского, а также на всеохватность выборки — это просто шаблоны, которые помогают нам в работе.

Follow-up:

Если надо как-то представиться в первом письме и это не делает тикет-система:

Спасибо за хорошее детальное описание того, что именно не работает:

“First, I wish all our customer is as self-reliance as yourself. Your detailed description of the issue you are encountering, the tests you ran to isolate the root cause, their results and conclusions are most helpful.”

Спасибо, пишите нам ещё:

Если по какой-то причине долго не отвечаю я или долго не было новостей по задаче:
“Please accept my apologies for being silent lately, everyone in the office is up on their toes because of the upcoming huge release of the SOFTWARE NAME, this is very important event for us. Still, we haven’t forgotten about you and the task to compile a new version of SDK is still with the highest priority. We’ll get back to it as soon as we make the release in MONTH.” (здесь чуть более неформально и для круга избранных, всё-таки про внутреннюю кухню компании должен знать не каждый клиент).

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

Если мы делаем исключение из нашей политики:

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

Если это факап компании и тех.поддержке надо извиниться, посыпать голову пеплом, пр:

Ну и юмор про истинный контекст деловой переписки:

Есть старый мем про русско-английский словарь деловой переписки, вот ссылка . “Это опять вы…. “ — именно та фраза, которую иногда думаешь при набивании “Thank you very much for your email.” 🙂

Уверенность в собственных силах

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

Рассерженный клиент может применять аргументы и требования абсолютно из любой области, даже не относящейся к области его изначальной проблемы: «соедините меня с менеджером», «что за чушь вы несете», «ваши продукты ужасны» и т.д. Даже если вы не полностью знакомы со всеми аспектами обсуждаемого вопроса – это не проблема, т.к. невозможно знать все.

Пример: Новичок садится на телефон и принимает первый звонок. Клиент задает технический вопрос, на который новичок не знает ответа. Неправильный вариант развития событий (одна из типичных ошибок):

Новичок говорит, что на данный момент он не располагает данной информацией и спросит совета у более опытного специалиста.

Что произошло с точки зрения клиента: «Ага, значит он не знает ответа и хочет выяснить информацию у коллеги! Почему бы мне не поговорить именно с этим коллегой, который даст мне нужные ответы из первых рук? Зачем мне нужно, чтобы на мне тренировался какой-то новичок?»

В данном диалоге специалист тех поддержки теряет доверие клиента (пусть даже на подсознательном уровне), что вытекает в предвзятое отношение ко всему, что будет обсуждаться далее.

Правильный вариант:

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

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

Реакция конечно не самая лучшая, зато нейтральная, и это лучшее, что можно получить в такой заведомо проигрышной ситуации. Тем не менее, специалист не теряет достоинства перед клиентом и может продолжать вести с ним диалог на том же уровне доверия. Заметим, что я не призываю специалиста врать (правильный вариант честен на 100%) и симулировать компетенцию.

Шаг 1. собираем данные для написания запроса

1. Если сервер недоступен

Специально для этой ситуации мы написали наш чек-лист, который может снять половину вопросов на эту тему, может быть, и запрос в техподдержку не понадобится. Перед тем, как составлять запрос, рекомендуем хотя бы кратко ознакомиться с этим чек-листом по двум причинам.

  • Есть ли пинг до сервера?
  • Сайт открывается не только по домену, но и по IP-адресу? В ином случае см. пункт 2.
  • Панель управления открывается? Есть SSH/FTP-доступ?
  • Нет ли проблем с вашим интернет-соединением? Попросите друга попробовать зайти на сервер и узнать, будет ли проблема у него.
  • Баланс лицевого счета положительный и услуги не остановлены? Нет запроса о блокировке или уведомления в личном кабинете о каких-либо работах?
  • Сервер доступен через VMmanager по VNC или Shell-доступ(OVZ)? Если да, см. пункт о проблемах сети.

2. Если сайты недоступны (но сервер доступен, в ином случае см.п. 1)

Лучше всего собрать ответы на следующие вопросы и кратко описать их в тексте запроса:

  • Как давно сайты перестали открываться?
  • Не делали ли вы что-либо с сайтом, прежде чем проблема возникла?
  • Нет ли проблем с вашим интернет-соединением? Попросите друга попробовать зайти на ваш сайт и узнать, будет ли проблема у него.
  • Проблема возникла впервые или уже такое было? Как разрешилась проблема в прошлый раз? Сколько времени сайты не работали?
  • Какой у вас браузер, его версия? Может быть, вы недавно сменили браузер? Как работают сайты с другого браузера?
  • Какая ошибка возникает при открытии сайта? Пишет ли браузер «Превышен интервал ожидания запроса?» Или может возникает серверный код ошибки, например ошибка 502?
  • Возможно, вы уже обращались в техподдержку по этому же вопросу ранее? Что вам ответили?
  • Пример имени сайта, который не открывается? Не открываются все сайты? Или только один? Или только несколько?

Шедевры команды поддержки вконтакте

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

Очень увлекательную статью о новой поддержке ВКонтакте опубликовала на ресурсе Slon.ru Злата Николаева. Если в двух словах, то набирая новых сотрудников команды поддержки социальная сеть ВКонтакте хочет уничтожить сложившиеся относительно техподдержки стереотипы, сделав взаимодействие пользователей с поддержкой максимально комфортным.

Особенно ярко демонстрируют революционность нового подхода к поддержке пользователей ВКонтакте некоторые ответы на нетривиальные вопросы. Последнее время я собирал скриншоты с подобными вопросами. Получилась небольшая коллекция:










А сейчас я предлагаю и вам испытать новую службу поддержки ВКонтакте. Спросите у агентов поддержки всё, что вас интересует. Если вы получите интересный необычный ответ, то обязательно сделайте скриншот вопроса с ответом и опубликуйте на этой странице в комментариях. Тем самым вы поможете пополнить мою коллекцию, которую я подумываю назвать “Шедевры команды поддержки ВКонтакте”:)) Быть может, самые интересные вопросы/ответы, из присланных в комментариях, я затем опубликую отдельным постом.

А сейчас вы можете попробовать задавать вопрос команде поддержке ВКонтакте>>

Эскалация проблемы

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

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

Тем не менее, простыми словами картину не исправишь и необходимо иметь собственно путь решения изначальной проблемы пользователя, что в данных случаях является приоритетом. Когда он видит, что проблема действительно начинает решаться, в то время как с предыдущим специалистом решения не было видно даже в перспективе – это моментально настраивает на положительный лад.

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

Еще бывают ситуации, когда решение оказывается совсем уж тривиальным, и это только еще больше расстраивает клиента: «Как так, вы поставили одну галочку и оно заработало через 2 минуты, а предыдущий специалист со мной общался целый час в пустую?!». Здесь уже все зависит от вашей компетентности – как вы сможете объяснить сей факт.

В данных случаях можно более подробно рассказать про продукт, как данная галочка относится к проблеме, почему вы ее поставили. Другими словами, нужно рассказать подробности вашего решения. Чем больше подробностей вы расскажете, тем больше клиент будет вам доверять («Этот специалист действительно знает свой продукт – ему можно доверять»).

Важный момент: ни в коем случае нельзя дискредитировать своих коллег, говоря клиенту, что предыдущий специалист не был достаточно опытен/работает у нас всего месяц/мы его вообще скоро уволим. Этот путь не приводит ни к чему, кроме как к потере доверия к компании в целом и к вам в частности (Русские на войне своих не бросают )

Ещё про Yota:  Йота контакты: контактный телефон центра Yota

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector