В этом материале мы расскажем на примере нашей компании, как организовать техническую поддержку клиентов. Для удобства как клиента так и самой компании, мы организовали ИТ-поддержку EFSOL по принципу «единого окна» – все обращения стекаются в одну точку и далее обрабатываются. Такой точкой является Ticket-система Абонцентр. Данный продукт является собственной разработкой компании, построенной на базе конфигурации 1С 8.3 «Управление торговлей». Инциденты в системе обрабатываются следующими способами (иллюстрация показана на рисунке 1):
Рисунок 1 – Схема регистрации инцидента
Постановка задачи клиентом
Web-интерфейс. Нужно заполнить форму на сайте. Здесь же возможно увидеть все свои задачи, статусы по ним, комментарии исполнителя и прочую информацию.
Email. Просто нужно отправить письмо на адрес Абонцентра с почты, которая указана при регистрации контрагента. По адресу отправителя будет происходить идентификация компании и конкретного ее сотрудника и далее инцидент будет передан закрепленному за клиентом ИТ-инженеру.
По телефону. Данный способ связи актуален для срочных обращений, когда нет возможности подать заявку другим способом. В этом случаи инцидент будет зарегистрирован сотрудником EFSOL. В рабочее время обращения принимают клиент-менеджеры, в остальное время работает круглосуточная служба поддержки.
Проактивное реагирование на инцидент
С целью обнаружить проблему ранее чем о ней сообщит клиент, в компании EFSOL организована система проактивного реагирования на базе системы мониторинга Zabbix. В случаи срабатывания критического триггера в Абонцентре автоматически открывается инцидент. Данный механизм в ряде случаев позволяет не только среагировать, но и разрешить инцидент до обнаружения проблемы клиентом. Основная сложность заключается в правильной настройке системы мониторинга – нужно сделать так, чтобы система с одной стороны отслеживала наступление всех критических событий, а с другой стороны не создавала ложных инцидентов. В первое время после запуска системы у нас было просто огромное количество ложных срабатываний, так как система была настроена очень чувствительно.
За каждым клиентом закрепляется личный ИТ-инженер, который обрабатывает обращения клиента в рабочее время компании. В случае возникновения обращения на выходных с инцидентом работает дежурный ИТ-инженер, а в ночное время – служба круглосуточной поддержки. Если у дежурного инженера или круглосуточного оператора возникают трудности с разрешением инцидента – к его решению привлекается закрепленный инженер. Далее, если инженер не может разрешить инцидент, он поднимается на уровень руководителя модуля поддержки (TeamLead), то есть происходит горизонтальная эскалация. Если же у ТимЛида не достаточно организационных полномочий или ресурсов для решения задачи – происходит вертикальная эскалация инцидента и его разрешениям занимается руководитель ИТ-отдела. Схема показана на рисунке 2.
.svg "Как организовать ИТ-поддержку клиентов - EFSOL")
Рисунок 2 – Схема разрешения инцидента
Удовлетворенность клиента решением его задачи является важнейшей задачей работы ИТ-отдела, поэтому инцидент закрывается только после соответствующего подтверждения клиента. Если заказчик не доволен решением – инцидент возвращается на доработку. В случае если клиент вернул на доработку задачу более 2-х раз – она возвращается не инженеру, а руководителю ИТ-отдела. Схема показана на рисунке 3.
Рисунок 3 – Схема закрытия инцидента
Можно кратко описать основные преимущества повышения качества ИТ-обслуживания, которые мы получили от внедрения нашей тикет-системы и механизмов описанных выше:
1. Фиксирование 100% обращений от клиента. Клиент может поставить задачу любым удобным способом, а также в любое время суток может обратится за помощью к сотруднику нашей поддержки. Поскольку система функционирует по принципу «единого окна», исключена ситуация когда клиент нам позвонил, а наш сотрудник сказал что вопрос не в его компетенции и кто его может решить он не знает или попросит перезвонить позднее.
2. Отслеживание всех инцидентов. Все инциденты фиксируются в системе и не теряются. В любой момент времени клиент может посмотреть статус всех своих инцидентов. В случае невозможности решить инцидент, происходит его эскалация. Также происходит информирование руководителя ИТ-отдела о затянутых и некачественно разрешенных инцидентах.
3. Гарантия качественного разрешения инцидента. Клиент обязательно подтверждает закрытие инцидента, таким образом исключена ситуация когда задачу клиента закрыли, а он остался недоволен.
4. Снижение количества критических инцидентов. Благодаря проактивному реагированию более половины критических инцидентов удается либо предотвратить заранее, либо среагировать на них быстрее, чем их обнаружит клиент.
