Все, что касается поддержки в Teachbase
S-2. Решение поступивших обращений
Определяет: ответственных, линии техподдержки, классификацию решаемых обращений, порядок решения, приоритеты реагирования, порядок распределения специалистов по линиям техподдержки, инициатора процесса, итоговый результат.
Глоссарий терминов, используемых в документе
Инициатор (процесса)
Лицо, триггер или действие, которое запускает выполнение процесса.
Итоговый результат
Однозначный конечный результат, закрывающий процесс. Может быть началом следующего процесса.
Процесс
Описанный в документе набор определенных действий, которые необходимо выполнить, чтобы решить одну конкретную задачу самым оптимальным образом. Может состоять из вспомогательных подпроцессов.
Подпроцесс
Тоже самое что и процесс, только является составной его частью. Также может использоваться сразу в нескольких процессах.
Начать изучение
Описание процесса
Перед тем, как новое обращение взять в работу, необходимо его классифицировать. После чего, решение происходит на одной из линий технической поддержки — в соответствии с типом обращения и в зависимости от канала, на которое оно поступило.
Инициатор: S-1. Прием входящих обращений
Триггер/Действие: принятое специалистом техподдержки обращение на один из каналов для общения.
1. Классификация обращений
Инструктаж по системе
Консультация по функционалу платформы. Например: «Как создать тест?», «Как создать курс» и т.п.
Предложение по доработкам
Не целевое обращение
Вопрос в другой отдел (стоимость, продление подписки, получение бух. документов и т.п.), вопрос, не связанный с системой (ученик спрашивает про контент и т.п.)
Сообщение об ошибке
Баг, Blowhole
Запрос информации
Выгрузка данных, файлов, кастомных отчетов, записей вебинаров и т.п. из системы.
Специальная задача
Брендирование, подключение фичей, помощь в загрузке данных на платформу, запрос на обучение работе с системой, просьбы восстановить удаленные данные
Консультация по интеграции
API, Webhook Tilda, Active Directory и прочее
2. Линии технической поддержки
Позволяют самым оптимальным образом принимать и решать все поступающие обращения в техническую поддержку, основываясь на их классификации и специфике самих каналов обращений.
## 1 линия — каналы живого общения (онлайн-чат, телефон)
Ключевые задачи и порядок обработки обращений
1
Классификация обращения
Получить от пользователя всю информацию, по его вопросу, чтобы определить к какому типу относится обращение
2
Решить «на месте» обращения, которые не требуют подробного анализа ситуации
Ориентировочное время решения займет не больше чем ~ 5 - 10 мин.

К ним относятся:

  • Инструктаж по системе Объяснить, показать как работает, прислать ссылку на инструкцию в Базе Знаний;
  • Предложение по доработкам Передать информацию об: инициаторе, критичности и текст самого предложения в канал #pb;
  • Не целевое обращение Передать обращение соответствующему сотруднику другого отдела в компании или сообщить инициатору, где он может найти контакты, чтобы связаться с нужным человеком или организацией.
3
Передать обращения на следующий уровень, которые нельзя решить оперативно "на месте" и которые требуют анализа ситуации. К ним относятся:
К ним относятся:

  • Сообщение об ошибке, Запрос информации, Консультация по интеграции 
Зафиксировать в Zendesk (создать тикет на email инициатора запроса) с информацией: в чем вопрос, дополнительная информация, которая поможет решить обращение (скриншоты, файлы, данные пользователей и т.п.);
Для ускорения, можно использовать автосоздание тикета через Slack (канал #support-operations).

  • Специальная задача: S-4. Выполнение специальных задач
Создать карточку в Trello, с подробной информацией по задаче и информацией об инициаторе (контакты для связи, аккаунт в системе и прочее).
Для ускорения можно использовать автосоздание тикета через Slack (канал#support-operations)
## 2 линия — каналы не живого общения (Zendesk)
Ключевые задачи и порядок обработки обращений
  1. Оперативное реагирование на входящие обращения в Zendesk в порядке классификации обращений и приоритета — концентрация на скорости первого ответа по тикетам:

Приоритет реагирования на тикеты в Zendesk (ниже в таблице)
2. Оперативно решить поступающие обращения в Zendesk — концентрация на скорости решения. К ним относятся:

  • Сообщение об ошибке Провести анализ ситуации (понять массовость, локализовать место (платформа или проблема пользователя), устранить последствия своими силами — усилиями всей командой техподдержки;
  • Запрос информации Получить усилиями всей команды техподдержки запрашиваемую информацию и передать ее инициатору запроса;
  • Консультация по интеграции Объяснить как работает, предоставить ссылки на всю нужную документацию;
  • Инструктаж по системе Объяснить, показать как работает, прислать ссылку на инструкцию в Базе Знаний;
  • Предложение по доработкам Передать информацию об: инициаторе, критичности и текст самого предложения в канал #pb;
  • Не целевое обращение Передать обращение соответствующему сотруднику другого отдела в компании или сообщить инициатору где он может найти контакты, чтобы связаться с нужным человеком или организацией.
3. Передать обращения на разработчиков, которые нельзя решить средствами и усилиями всей команды техподдержки. К ним относятся:
  • Сообщение об ошибке
  1. Подключить дежурного разработчика к решению — создать карточку с типом «Blowhole»;
  2. Повторить кейс, приводящий к ошибке: если кейс понятен, то создать карточку в Jira с типом «Баг», если кейс не понятен и повторить не удалось, то сформировать карточку с типом «Исследование»;
  3. По итогу выполненной задачи проинформировать инициатора о результате.
  • Запрос информации
  1. Подключить дежурного разработчика к решению — создать карточку с типом «Задача»;
  2. По итогу выполненной задачи проинформировать инициатора о результате.
  • Консультация по интеграции
  1. Подключить дежурного разработчика к решению — если требуется консультация, то достаточно только сообщения в #dev-duty, без создания карточки в Jira.
  2. По итогу выполненной задачи проинформировать инициатора о результате.
3. Распределение специалистов по линиям технической поддержки
Каждый специалист заранее распределяется на одну из основных для него линий техподдержки, на которой в приоритете занимается решением обращений от пользователей.
    Специалист подключается к решению на другой, не приоритетной для него линии поддержки, в случаях:
    1. Если на основной линии все запросы решены;
    2. Специалисты другой линии временно отсутствуют: по болезни, обед, отпуск, форс-мажор.
    Итог
    Обращение решено — все задачи, связанные с обращением, выполнены, а инициатор уведомлен и не осталось больше вопросов по теме на текущий момент.