Одна заявка — десятки версий: как работает техподдержка Parsec

Обычно система контроля доступа напоминает о себе в самый неподходящий момент: сотрудник не может попасть в офис, у посетителя не оформляется пропуск, а на проходной выстраивается очередь. В техподдержку в этот момент уходит короткое и не слишком информативное сообщение: «Не работает».

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

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

— Расскажите о себе и своей работе в Parsec.

— Меня зовут Кирилл Баранов, я руковожу отделом технической поддержки Parsec. Компания разрабатывает оборудование и программное обеспечение для систем контроля и управления доступом — СКУД.

В Parsec я работаю с июня 2024 года. До этого тоже управлял сервисными подразделениями, но в другой отрасли. Сегодня моя задача вместе с командой — помогать клиентам и организациям, которые эксплуатируют наше оборудование и ПО, разбираться с техническими вопросами и поддерживать работоспособность систем на объектах.

— Какая главная задача у техподдержки?

— С точки зрения клиента — помочь обеспечить стабильную работу системы на объекте. С точки зрения руководителя поддержки — сделать так, чтобы обращения не накапливались и проблемы решались в понятные сроки.

— Почему СКУД вообще может работать нестабильно? Кажется, что это просто считыватель, карта и, скажем, замок.

— На самом деле СКУД — сложный программно-аппаратный комплекс. В ней есть оборудование на объекте, сеть, серверная часть, программное обеспечение, настройки прав доступа, графиков и учёта рабочего времени, интеграции с другими системами.

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

— С какими проблемами клиенты обращаются чаще всего?

— Есть две классические ситуации.

1. Первая: «Мы что-то настраивали, запускали — и у нас не заработало». Обычно это происходит на новых объектах, при расширении системы или подключении нового функционала.
2. Вторая звучит наоборот: «Мы ничего не трогали, но всё сломалось». Здесь уже нужно разбираться, что изменилось в инфраструктуре, настройках или на самом объекте.

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

— Что чаще всего тормозит решение проблем?

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

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

— Как у вас устроена работа с такими обращениями?

— Мы собираем все обращения в одном месте, независимо от того, как клиент с нами связался: написал на почту, в Telegram, через портал, форму на сайте или позвонил.

В Parsec для этого используем Okdesk. Там заявка фиксируется, получает ответственного, историю переписки и сроки. Это нужно не ради отчётности, а чтобы ни один вопрос не потерялся и команда видела общую картину.

— Что происходит с заявкой после регистрации?

— Сначала она попадает на первую линию. Специалисты принимают звонки, регистрируют обращения, отвечают на типовые вопросы и помогают с известными инцидентами.

Если вопрос решается по инструкции — клиент получает ответ сразу. Если нужна диагностика, обращение передаётся инженеру.

— Что делает инженер второй линии?

— Он уже разбирается с самой проблемой: уточняет детали, просит прислать скриншоты, проверить настройки, собрать диагностическую информацию. Затем анализирует результаты и предлагает решение.

Задача инженера — не просто написать клиенту ответ, а понять, что именно привело к проблеме: оборудование, сеть, сервер, настройки или логика работы системы.

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

— Что позволяет не терять контекст по клиенту и объекту?

— В заявке и карточке клиента хранится всю история взаимодействия с привязкой к конкретному объекту и клиенту. Если однажды нам уже рассказали, что это за объект, какое оборудование там установлено, какие были настройки и проблемы, эту информацию можно поднять при следующем обращении.

Это сильно экономит время. Клиенту не нужно каждый раз начинать с рассказа о своей системе, а инженеру — собирать базовые данные с нуля.

— Как вы понимаете, что команда справляется с нагрузкой?

— Я ежедневно смотрю на очередь заявок: сколько их открыто, как они меняются, с какой скоростью решаются. Хорошая динамика — когда команда успевает закрывать поступившие обращения и не переносит их бесконечно «на завтра».

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

Мы оцениваем обращения по разным параметрам:

• количество поступивших и решённых заявок,
• скорость реакции,
• сроки решения,
• распределение нагрузки,
• качество ответов.

Заявки регулярно просматриваются: важно не просто дать клиенту ответ, а действительно помочь ему продвинуться к решению.

— Бывают периоды, когда обращений становится заметно больше?

— Да, у нас есть сезонность. Летом нагрузка обычно ниже: часть компаний и учебных заведений работает менее активно, люди уходят в отпуска.

Осенью начинается новый учебный год, появляются новые сотрудники и студенты, нужно выдавать идентификаторы, настраивать права доступа, запускать процессы на объектах. После Нового года часто стартуют новые проекты — появляются бюджеты, начинается внедрение, а вместе с ним и вопросы.

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

— Можно ли сократить число повторяющихся вопросов?

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

— Что изменила для вас выстроенная система управления заявками?

— Работа стала прозрачнее. Видно, сколько обращений приходит, чем заняты сотрудники, какие вопросы повторяются, где возникают задержки.

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

— Что для вас самое сложное в работе руководителя техподдержки?

— Наверное, работа с мотивацией сотрудников. Это непростая тема для любого руководителя. Можно создавать условия, объяснять задачи, давать обратную связь, выстраивать процессы. Но в конечном счёте многое зависит от внутренней мотивации самого человека.

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

Идеальная ситуация — когда у клиента и техподдержки совпадают ожидания. Клиент понимает, какую информацию нужно подготовить и какую помощь он может получить. А специалисты поддержки быстро включаются, помогают найти причину и вернуть систему в рабочее состояние.

Интернет-газета от разработчика Okdesk «Заявка закрыта»
Автор
Марина Титова