Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Ожидание ответа клиента в SLA

Ожидание ответа клиента в SLA

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

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

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

Приведу пример.

Клиент: “У меня очень сильно тормозит почтовый клиент”.
Ответ инженера: “Пришлите версию вашего почтового клиента. Запрос переведен в ожидание ответа”.
Клиент (спустя 30 минут): “Я не знаю как это сделать!!!”.
Ответ инженера: “Нажмите туда-то и туда-то. Запрос переведен в ожидание ответа”.
Клиент: “Версия такая-то”.
Ответ инженера: “Посмотрите диспетчер задач и пришлите скриншот. Запрос переведен в ожидание ответа”.
Клиент (спустя 30 минут): “Что такое скриншот, что такое диспетчер задач?”
Ответ инженера: “Нажмите вот это, появится такое-то окно, потом нажмите вот это и сделайте вот это. Запрос переведен в ожидание ответа”.
Клиент (спустя 30 минут): “Прислал”.
Ответ инженера: “У вас запущено 100500 проигрывателей видео, закройте их. Проблема решена?”.
Клиент: “Да гори ты в аду, инженер!”.

Простейший запрос решен формально за 15 минут. Реально же клиент ждал решения около 2 часов.

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

Так может быть вводить в договор пункт о том, что допустимо не более N “ожиданий ответа”? Ну или после стольки-то ожиданий необходимо совершить активные действия (звонок) со стороны аутсорсера?

Хотя правильный ответ — это работать с персоналом и прививать клиентоориентированность. Но это никакими формальными процедурами не сделаешь.

А вы сталкивались с такой проблемой? Как решали?

Дополнительные материалы

Вам понравился материал? Подпишитесь на RSS. А также следите за нами в Facebook, ЖЖ или других социальных сетях.

Комментарии (14)

  • Аватар

    Бычков Валерий [vbychkov], 14 октября 2010, 12:42

    0
    А вы пробовали выключить и включить? Ну по крайней мере лишние 100000 видеопроигрывателей убивает сразу
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 14 октября 2010, 12:59

      0
      Пример с 100000 видеопроигрывателями не из реальной жизни. Привел его с целью аллегории.
      • Аватар

        Бычков Валерий [vbychkov], 14 октября 2010, 13:19

        0
        Это вопрос канала коммуникации. Локализовать проблему и решить вопрос за 2 часа с использованием только электронной почты - это очень хороший результат. Переписка с тех. поддержкой вполне может и несколько дней продолжаться. И совсем другая ситуация - телефонный звонок, когда можно получить непосредственную обратную связь. Собственно в этом сценарии - а кто виноват, что клиенту требуется 30 минут на ответ? И опять же время ответа тех. поддержки тут равно нулю.
  • Аватар

    Серёдкин Иван Валерьевич [sivan], 14 октября 2010, 13:33

    0
    Актуальная проблема для нашей службы поддержки. Решили пока только с помощью внутреннего показателя, который влияет на премию сотрудников. Показатель отражает количество переводов обращения в режим ожидания. Для себя приняли, что идеальное обращение должно решаться не более чем за 2 перевода в режим ожидания, т.е. идеальный сценарий решения выглядит так: 1. Приняли обращение от клиента, например, письмо. 2. Запросили уточнение (первый перевод в режим ожидания). 3. Пришел ответ от клиента с запрошенной информацией. 4. Выдали рекомендацию (второй перевод в режим ожидания). 5. Пришел ответ от клиента, рекомендации помогли. 6. Закрыли обращение. Показатель внедрили в работу относительно недавно, в SLA пока его не вынесли.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 14 октября 2010, 15:17

      0
      хороший вариант премию завязать на частые переходы. Ну а если больше 2 раз переводили -- не автоматом премии лишать, а разбираться. Главное чтобы случаев таких не много было, а то отдельного человека нанимать придеться:).
  • Аватар

    Яковлев Андрей Михайлович [swtws], 14 октября 2010, 13:41

    0
    Никаких таких пунктов не надо, тут все на отношениях за пределами SLA. А вот работа с первой линией нужна, особенно если учесть высокую текучку. Вообще, поставщик отвечает только за себя, а не за клиента, третьих лиц или форс-мажор. Также и клиент отвечает за себя. У серьезной компании есть служба контроля качества сервиса, пользователь может отправить жалобу, ее как особый запрос на обслуживание рассматривают.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 14 октября 2010, 14:00

      0
      да, пожалуй к SLA это отношение имеет опосредованное. Внутренняя кухня. Поставщик отвечает не за себя, а за качество сервиса. И покупать сервис у поставщика будут в том случае, если ЛПР со стороны покупателя доволен. Если сервис, который вы предоставляете, затрагивает 10-20 человек, то информация от простых пользователей легко доходит до ЛПР и имеет для него значение. Ну и соответственно, имея даже службу контроля сервиса и адрес типа claim@company.com, вы не сможете гарантировать того, что письма с жалобами от пользователей туда будут приходить. Будут копить обиду и все. Да и в приведенном примере формального повода для жалобы нет, а значит далеко не каждый пользователь сможет сформулировать, чем он не доволен. Эх, если б клиентоориентированность можно было привить на курсах или лекциях:).
      • Аватар

        Яковлев Андрей Михайлович [swtws], 14 октября 2010, 16:12

        0
        Вот тут как раз нюанс - качество зависит от всех сторон. Насчет жалоб. При хорошей организации пользователи все делают по рабочим инструкциям (как и сотрудники сервис-провайдера) и кому и как эскалировать в курсе. Я видел еще более дикий вариант - если в сабджекте письма или в вэбе или даже устно добавить "RFS Complain" это автоматически передавало человеком или машиной запрос сервис-контролеру. Потом сервис-менеджер, разбирает - в чем дело. К сожалению, у сотрудника деска должен быть определенный характер (трехзначный IQ и любовь к другим людям - Роб Инглунд), а постоянные звонки недовольных нервную систему не укрепляют. Хорошая практика на мой взгляд - высокая з/п десков, но и постоянная угроза потери места, хороший FAQ облегчающий работу с клиентами. С рассмотрением случаев все тяжко - нужен пользователь, а его во внутренние разборки не втянешь.
    • Аватар

      Серёдкин Иван Валерьевич [sivan], 14 октября 2010, 14:05

      0
      Про пункт в SLA согласен, возможно, в нём нет необходимости, но контролировать этот показатель внутри группы необходимо.
  • Аватар

    Серёдкин Иван Валерьевич [sivan], 14 октября 2010, 16:05

    0
    Кирилл, а у вас осуществляется контроль переводов в режим ожидания? Как в вашем понимании выглядит идеальная, но совместимая с реальностью картина решения обращения?
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 14 октября 2010, 16:15

      0
      в плане учета времени простоя во времени решении запроса? да, используемая система в СЦ это все считает. Количество фактов перевода запроса в состояния "ожидание" считается, но никаких ограничений пока на этот счет нет. Причина в специфике работы. Мы же поддерживаем системы, которые сами внедряли на наших продуктах. Запросы бывают разноплановые (далеко не только инцидентные), поэтому количество ожиданий может быть и 10. Вообще учитывать количество ожиданий имеет смысл только у инцидентов. И допустимое количество ожиданий должно быть привязано к критичности инцидента. В случае самой высокой критичность я б вообще ожидание запретил (только в случае, если у клиента тариф предусматривает лишь дистанционную поддержку, а удаленный доступ по каким-то причинам упал).
      • Аватар

        Яковлев Андрей Михайлович [swtws], 14 октября 2010, 16:50

        0
        Не так. Вина третьей стороны при P-1? Рвать когти, но сделать? В 2007 в Королевстве Нидерланды натовский "Апач" врезался в опору ЛЭП. Более 150 000 зданий остались без электроэнергии. Но причем тут провайдер ИТ сервиса? Третья сторона вмешалась. Второй пример - отказал свитч, это явный Р-1, но беда в том, что свитч находится на газодобывающей платформе, а погода просто кошмар, спасатели готовы рискнуть ради спасения гибнущего судна, но вертолет компании не повезет техника - перебьются, это форс-мажор. Ожидание должно отражать реальное событие - всегда четкое объяснение причины, она должна быть уважительной. Хотя при налаженых отношениях спокойно относятся к "отложено" с соображением "позвонили, никто не взял трубку, перезвоним через час".
        • Аватар

          Рубинштейн Кирилл [krubinshteyn], 14 октября 2010, 16:57

          0
          в договорах на поддержку эксплуатации внедренных нами ИС мы прописываем, что обязательным условием должно быть наличие удаленного доступа (и не мы являемся компанией, которая этот доступ обеспечивает). Поэтому в нашем случае разумно откладывать запрос до тех пор, пока доступ не будет восстановлен. Мы повлиять не это никак не можем.
  • Аватар

    Стояннидис Никос Эдуардос [odminko], 18 ноября 2010, 16:27

    0
    p { margin-bottom: 0.21cm; }

    Ситуаций много, но думаю если описать эти формальности в договоре или предложении, клиент отдаст предпочтение штатному сисадмину...