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

Обычно система контроля доступа напоминает о себе в самый неподходящий момент: сотрудник не может попасть в офис, у посетителя не оформляется пропуск, а на проходной выстраивается очередь. В техподдержку в этот момент уходит короткое и не слишком информативное сообщение: «Не работает».
Для клиента это одна проблема. Для инженера – десятки возможных причин: от неверной настройки и ошибки в базе данных до сбоя оборудования, сети или сервера. Чтобы не искать их вслепую, поддержке нужен не только технический опыт, но и понятный процесс работы с обращениями.
О том, как этот процесс устроен в Parsec и почему для руководителя техподдержки важнее не число закрытых заявок, а отсутствие растущей очереди, рассказал Кирилл Баранов, руководитель отдела технической поддержки Parsec.— Расскажите о себе и своей работе в Parsec.
— Меня зовут Кирилл Баранов, я руковожу отделом технической поддержки Parsec.  Компания разрабатывает оборудование и программное обеспечение для систем контроля и управления доступом – СКУД.
В Parsec я работаю с июня 2024 года. До этого тоже управлял сервисными подразделениями, но в другой отрасли. Сегодня моя задача вместе с командой – помогать клиентам и организациям, которые эксплуатируют наше оборудование и ПО, разбираться с техническими вопросами и поддерживать работоспособность систем на объектах.
— Какая главная задача у техподдержки?
— С точки зрения клиента – помочь обеспечить стабильную работу системы на объекте. С точки зрения руководителя поддержки – сделать так, чтобы обращения не накапливались и проблемы решались в понятные сроки.

Парадоксально, но хорошая техподдержка – это не та, у которой постоянно много работы. Наоборот: в идеале клиенты редко обращаются, потому что система стабильно работает, типовые вопросы закрываются документацией, а на объекте есть люди, которые понимают, как с ней работать.
— Почему СКУД вообще может работать нестабильно? Кажется, что это просто считыватель, карта и, скажем, замок.
— На самом деле СКУД – сложный программно-аппаратный комплекс. В ней есть оборудование на объекте, сеть, серверная часть, программное обеспечение, настройки прав доступа, графиков и учёта рабочего времени, интеграции с другими системами.
На каждом этапе могут возникнуть ошибки. Например, оборудование могут неправильно подключить, сеть неверно настроить, подобрать сервер без запаса под будущую нагрузку. Бывает и человеческий фактор: кто-то меняет настройки, не до конца понимая последствия.
Многое закладывается ещё на этапе запуска. Качественный монтаж – это не только аккуратно смонтированное оборудование. Это понятная коммутация, подписанные линии, доступная документация. Когда через год или два возникает проблема, специалисту гораздо проще понять, что происходит на объекте, если система собрана и настроена аккуратно и прозрачно.
— С какими проблемами клиенты обращаются чаще всего?
— Есть две классические ситуации.Первая: «Мы что-то настраивали, запускали – и у нас не заработало». Обычно это происходит на новых объектах, при расширении системы или подключении нового функционала.Вторая звучит наоборот: «Мы ничего не трогали, но всё сломалось». Здесь уже нужно разбираться, что изменилось в инфраструктуре, настройках или на самом объекте.Кроме инцидентов, есть ещё запросы информации. Иногда человек хочет уточнить настройку, которая описана в документации. А иногда приходит действительно нестандартный вопрос, который нельзя решить готовой инструкцией. Тогда специалисты собирают информацию, проверяют гипотезы и ищут решение вместе с клиентом.
— Что чаще всего тормозит решение проблем?
— Недостаток информации. Клиент пишет: «Не работает система, помогите». Но за этим может скрываться проблема с идентификатором, контроллером, настройками, сетью или серверной частью.
Нам важно понять, какое оборудование установлено, какой именно результат человек хотел получить, что получилось в итоге и что уже проверяли. Чем точнее исходные данные, тем быстрее можно перейти от уточняющих вопросов к решению.
— Как у вас устроена работа с такими обращениями?
— Мы собираем все обращения в одном месте, независимо от того, как клиент с нами связался: написал на почту, в Telegram, через портал, форму на сайте или позвонил.
В Parsec для этого используем Okdesk. Там заявка фиксируется, получает ответственного, историю переписки и сроки. Это нужно не ради отчётности, а чтобы ни один вопрос не потерялся и команда видела общую картину.
— Что происходит с заявкой после регистрации?
— Сначала она попадает на первую линию. Специалисты принимают звонки, регистрируют обращения, отвечают на типовые вопросы и помогают с известными инцидентами.
Если вопрос решается по инструкции – клиент получает ответ сразу. Если нужна диагностика, обращение передаётся инженеру.
— Что делает инженер второй линии?
— Он уже разбирается с самой проблемой: уточняет детали, просит прислать скриншоты, проверить настройки, собрать диагностическую информацию. Затем анализирует результаты и предлагает решение.
Задача инженера – не просто написать клиенту ответ, а понять, что именно привело к проблеме: оборудование, сеть, сервер, настройки или логика работы системы.
Когда мы понимаем, что вопрос связан с внутренней логикой продукта и не решается на уровне инженера – обращение переводится на третью линию поддержки – команде разработки.
Но разработчикам не передают заявку в формате «у клиента что-то не работает». До эскалации нужно собрать фактуру: как проявляется проблема, можно ли её воспроизвести, что уже проверили, какие причины исключили. Тогда разработчик сразу работает с сутью задачи, а не начинает диагностику заново.
— Что позволяет не терять контекст по клиенту и объекту?
— В заявке и карточке клиента хранится всю история взаимодействия с привязкой к конкретному объекту и клиенту. Если однажды нам уже рассказали, что это за объект, какое оборудование там установлено, какие были настройки и проблемы, эту информацию можно поднять при следующем обращении.
Это сильно экономит время. Клиенту не нужно каждый раз начинать с рассказа о своей системе, а инженеру – собирать базовые данные с нуля.
— Как вы понимаете, что команда справляется с нагрузкой?
— Я ежедневно смотрю на очередь заявок: сколько их открыто, как они меняются, с какой скоростью решаются. Хорошая динамика – когда команда успевает закрывать поступившие обращения и не переносит их бесконечно «на завтра».
Также важна равномерность нагрузки. Не должно быть ситуации, когда один инженер закрывает почти все заявки, а остальные загружены меньше или заняты чем-то непрозрачным для руководителя.
Мы оцениваем обращения по разным параметрам:количество поступивших и решённых заявок,скорость реакции,сроки решения,распределение нагрузки,качество ответов.Заявки регулярно просматриваются: важно не просто дать клиенту ответ, а действительно помочь ему продвинуться к решению.
— Бывают периоды, когда обращений становится заметно больше?
— Да, у нас есть сезонность. Летом нагрузка обычно ниже: часть компаний и учебных заведений работает менее активно, люди уходят в отпуска.
Осенью начинается новый учебный год, появляются новые сотрудники и студенты, нужно выдавать идентификаторы, настраивать права доступа, запускать процессы на объектах. После Нового года часто стартуют новые проекты — появляются бюджеты, начинается внедрение, а вместе с ним и вопросы.
Пока у нас не было ситуаций, когда поток обращений полностью парализовал работу. В периоды повышенной нагрузки может увеличиться время ответа, потому что заявки идут в порядке очереди. Но критических задержек на недели или месяцы не возникало.
— Можно ли сократить число повторяющихся вопросов?
— Да. Для этого важны документация, база знаний и понятные инструкции. Если решение типовой проблемы один раз хорошо описано, клиент сможет использовать его повторно, а не каждый раз начинать диалог с поддержкой с нуля.
При этом инструкция должна быть удобнее, чем обращение в техподдержку. Если человеку проще написать или позвонить, чем открыть документ и найти ответ, значит, с документацией что-то не так, её надо дорабатывать.
— Что изменила для вас выстроенная система управления заявками?
— Работа стала прозрачнее. Видно, сколько обращений приходит, чем заняты сотрудники, какие вопросы повторяются, где возникают задержки.
Без такой системы многое держится на памяти людей, личных переписках и ручном контроле. Когда все обращения, сроки и история объекта собраны в одном месте, поддержкой проще управлять, а клиенту проще получать помощь.
— Что для вас самое сложное в работе руководителя техподдержки?
— Наверное, работа с мотивацией сотрудников. Это непростая тема для любого руководителя. Можно создавать условия, объяснять задачи, давать обратную связь, выстраивать процессы. Но в конечном счёте многое зависит от внутренней мотивации самого человека.
Но при этом важно помнить: на другом конце обращения всегда человек, который часто находится в стрессе, потому что у него на объекте что-то не работает.
Идеальная ситуация – когда у клиента и техподдержки совпадают ожидания. Клиент понимает, какую информацию нужно подготовить и какую помощь он может получить. А специалисты поддержки быстро включаются, помогают найти причину и вернуть систему в рабочее состояние.