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

Хахарев Иван - спикер доклада

Коллеги, большое спасибо за рецензии, всегда приятно услышать конструктивные дополнения и примеры :-)

Хочется сразу ответить на общий вопрос и ваше наблюдение.

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

п\я -> система тикетов и т.д.

По поводу наблюдения о типе обращения "Инцидент" и других типах работ.

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

Поэтому я оставил лишь один тип обращений - Инцидент - и показал развитие системы вокруг него.

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

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

Ответы на вопросы от Кудряшова Алексея.

1. В ходе презентации было явно сказано, что большая часть пользователей находится в Китае и имеет другой часовой пояс, в отличие от РФ. 
Почему изначально не была включена вторая линия на стороне Китая при условии установленного SLA в 1 час?

Потому что так было сделать дешевле. Для того чтобы подключить 2-ю линию, необходимо было провести их обучение.

Для обучения китайской 2-й линии:

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

• Выделить сотрудников в китайском офисе - это тоже не самая простая задачка.

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

2. Почему в презентации вторая линия указана как RU и CH, а третья как РФ?

Если вопрос к обозначению, то я опечатался, и третью линию нужно было указать как RU.

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

По поводу дополнения от Рохлиной Валерии по FAQ и базе знаний:

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

Тут скорее обратная история получилась, так как база знаний большая, и иногда поиск может быть долгим, мы дополнительно придумали FAQ для суппорта, который в несколько вопросов приводит к определенному решению проблемы. Так называемая визард - где 2-3 ответа дал и получил нужное решение :-)