Как вы организовывали работу техподдержки?  Публичный пост

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

Как можно оптимизировать работу техподдержки с такими кейсами? Где и как вести базу знаний по типовым вопросам? Какими инструментами пользоваться?

Мне в частности интересно узнать про техподдержку конечных пользователей, но если вы можете рассказать про любой другой вид техподдержки и как она у вас организована -- буду рад почитать

13 комментариев 👇
Dmitry Kiryukhin, Technical support team leader 19 апреля в 11:11

Рецепт приготовления службы поддержки 📝

Ингредиенты:

  1. Причины и обоснования
  2. Ресурсы: люди, деньги, время и методология
  3. Регламентация процессов
  4. Методика измерения процессов
  5. Автоматизация процессов
  6. Реклама о себе
  7. Развитие и улучшение

Кому и зачем нужна служба технической поддержки? 👨‍💻

Компания растёт и развивается, растёт численность сотрудников.

Проблемы подачи обращений:

  • отдельные ИТ-подразделения, существует 'пинг-понг' обращений пользователя;
  • отсутствие единого окна для обращений;
  • обращения напрямую к экспертам;
  • отсутствие информации о статусе обращения;
  • отсутствие нормативных сроков;
  • отсутствие каталога ИТ-услуг;
  • отсутствие ключевых показателей (KPI); насколько качественно и своевременно; контроль исполнительной дисциплины;
  • отсутствие единой системы ИТ

Перестройка IT, чтобы решить вышеперечисленные проблемы.

Какие нужны ресурсы:

  • Люди в СТП и пользователи
  • Деньги (ПО, зарплаты)
  • Время
  • Методология (MOF, COBIT, ITIL, DevOps)

Какие процессы и функции адаптировать? 🛠

Начинать с базовых процессов:

  1. [Организация Service Desk]: создать единое окно, прописать регламенты, желательно их автоматизировать, завести кадровые ставки согласно штатному расписанию, выпустить приказ и т.д.
  2. [Управление инцидентами]: незапланированное прерывание или снижение качества IT-услуги. Регистрация абсолютно всего, даже если обратились не по IT-части. Понять спрос.
  3. [Выполнение запросов на обслуживание]: нормальная работа IT-сервиса, консультация и информирование пользователя, типовые настройки.
  4. [Управление каталогом услуг]: определение услуг, назначение ответственных, определение приоритетов и времени выполнения услуги, правила эскалации и эксплуатации, правила для внутренних сотрудников и внешних клиентов;
  5. [Управление уровнем услуг]: SLA разное время предоставления услуг для разных групп пользователей;
  6. [Управление удовлетворённостью]: получить обратную связь от пользователя путем отправки письма с оценкой и комментарием после решения его запроса. Что конкретно не устроило и как мы можем изменить ситуацию? Сохранять лояльность пользователей.

Схема обращения:

Пользователи —> СТП (диспетчеры) —> 2-я линия (более квалифицированные специалисты) —> 3-я линия (разработчики, администраторы).

Метрики службы технической поддержки:

  1. Своевременность обработки запросов на обслуживание и устранение инцидентов. Еженедельная рассылка с зеленой и красной зоны сотрудникам по текучке
  2. Удовлетворенность пользователей качеством IT-услуг
  3. Существует множество метрик, например - время до первого отклика, среднее время первого ответа, общее количество заявок, количество просроченных заявок, среднее время обработки заявки и т.д. (кол-во обращений закрытых с помощью пользовательской документации, снимать видео)

Что делать дальше?

  1. Улучшать текущую службу поддержки
  2. Расширять службу поддержи новыми сервисами и за пределами ИТ
  Развернуть 1 комментарий

Документировать типовые запросы и отвечать линками на документы, постепенно приучатся читать + поддержка будет иметь четкий чеклист/типовой ответ. Посчитать время на обработку запросов с тегами по typical/nontypical, наиболее затратные соответственно документируем.
Инструмент имеет смысл выбирать из доступного и легко интегрируемого для вас.
Базово - статичный markdown сайт (систем множество), либо что-то вроде wiki или confluence. Доступ регулировать по группам пользователей/продуктам.

  Развернуть 1 комментарий
Liliya Goncharova, Делаю техподдержку 19 апреля в 12:10

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

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

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

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

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

  Развернуть 1 комментарий

Вы имеете ввиду внутреннюю техподдержку, или техподдержку для пользователей продукта/услуги?

  Развернуть 1 комментарий

@svk, вообще мне сейчас больше интересна поддержка конечных пользователей, но и про внутреннюю тоже бы почитал

  Развернуть 1 комментарий

Могу сказать как пользователь: мне всегда приятнее позвонить и пообщаться с человеком, чем с роботом-ботом.

  Развернуть 1 комментарий

@Olga_FLY, позвонить и пообщаться? ух...

  Развернуть 1 комментарий

@n3akr, да-да :) Вот реальный пример: мне МТС по 15 р. в день списывал на какие-то услуги. Робот постоянно говорил, что никакие услуги у меня не подключены... я и так и сяк его спрашивала... бестолку... в итоге только живой человек спас и отключил за 5 минут эту подписку :))

  Развернуть 1 комментарий

@Olga_FLY, а пообщаться текстом в чате, но не с роботом, а с живым человеком?

  Развернуть 1 комментарий

@svk, можно и в чате. Просто роботы дурацкие. Если у меня простой вопрос - я итак могу на сайте ответ найти, а когда вопрос сложный - они тупят и по кругу водят... бесит :))))

  Развернуть 1 комментарий

Вопрос про техподдержку, и ни одного коммента про ITIL...

  Развернуть 1 комментарий

@gramlin, ну тут конкретные вопросы, ITIL на такие не ответит.

Мне кажется, полезно будет почитать описания практик из ITIL4: Service Desk, Service Request Management, но на практические вопросы там ответов не найти. Там больше про концепции и идеи.

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

  Развернуть 1 комментарий
Захар Кириллов, Амбассадор ЕРАМ в Клубе 14 июля в 08:45

В своё время был офигенный подкаст на Подлодке про организацию клиентской поддержки на примере Мейл.ру: https://podlodka.io/156 — рекомендую к прослушиванию.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб