Комментарии 10
Нда, заявки с “на отвали” заполненной инфой от сотрудников ― вот это база.
Вот поэтому компании рано или поздно задумываются, как собирать эту информацию без сотрудников.
Все же кажется, что сотрудник, которому требуется поддержка - не специалист в заполнении заявок, а заявочный комплекс и его шаблоны иногда кажутся заградительными - 10 раз подумаешь заводить ли заявку. Тут видится что на первом уровне (а может быть и на условном нулевом) должен быть специалист основная задача которого - классифицировать и дообогощать заявку данными, что довольно хорошо ложится в автоматизацию, особенно с потенциальным будущим внедрением ИИ на этом этапе (где еще не).
Проблема дополняется тем, что довольно часто поддержка сама работает «на отвали», но в основном из-за некорректных KPI (условная палочная система, а не стремление действительно помочь решить проблему сотрудника, решая таким образом проблему бизнеса).
А как быть, если в компании разное оборудование? Не только ПК, но и мобильные устройства, всякие сканнеры штрих-кодов и по ним тоже тикеты прилетают. Тут софт тоже может с них инфу собрать?
Согласен с автором. Закрывать заявки ― это важно, конечно. Но было бы лучше их вообще предотвращать максимально. Нет заявок ― нет проблем.
... Это единственный проверенный путь к идеальному SLA.
Вообще-то сторонники рыночной экономике уверены что основа любого дела-начинания есть рыночные отношения
Соответственно, зададимся вопросом - насколько срочность исполнения той или иной заявки влияет на прибыль/доход исполнителя?
Если такой зависимости просто нет - резонный вопрос а зачем напрягаться?
Ну а если есть - то исполнитель не дурак - он тоже оценивает свои затраты (трудозатраты, расход ресурсов и тд) - и, естественно, будет в первую очередь делать более вкусное ...
так что SLA - это не "святые заповеди" для техподдержки, данные моисеем-менеджером, а договор с тарифами за работу
Чет не очень корректный заголовок как по мне. В нем имеется ввиду общее, а пишите один пример решения вопроса. При этом после прочтения, закрадывается мысль, что тема вообще не раскрыта. Да и написание некоторых терминов некорректно вовсе. Например:
В техническую поддержку прилетает тикет ― отвалился компонент ключевого в компании ПО (например, nanoCAD). Специалисты берут заявку в работу, собирают с помощью софта данные, находят ошибку, устраняют проблему и закрывают заявку. Все отлично ― как говорится, закрыли и забыли.
Проходит примерно неделя ― прилетает тикет с той же самой проблемой. Повторили алгоритм. А затем эта ситуация повторяется с определенной периодичностью и становится регулярной. Это раздражает и сотрудников, которые не могут выполнять работу, и техподдержку.
По нашему опыту, именно после череды подобных проблем бизнес и задумывается о формировании подробной Базы знаний, которую держат в актуальном состоянии.
Как раз такие заявки на постоянной основе являются не ошибками и тем более не проблемами, а только инцидентами. А вот периодичность их возникновения должны перетекать в ЗИ. А проблема, это уже если вы не знаете как решить цепочки инцидентов и ЗИ.
Сбор технической информации о станциях пользователей, где-то в очень узкой направленности поможет, но вопрос на сколько?
По опыту, почти 90% заявок не требуют знаний о версии ПО или железе компьютера. А требуют чтобы специалист своими глазами взглянул на проблему:
не открывается excel - оказывается пользователь в другом файлике находится в режиме редактирования ячейки;
не включается компьютер - забыл включить монитор;
не открывается гос сайт - неверно введен адрес;
как в документообороте создать заявку;
не может подписать рабочей ЭЦП документ...
Интересны проблемы с SSD СМАРТ показывает оценку 80-90 баллов, а когда делаешь тест поверхности у тебя дикие провалы скорости чтения, хотя да, битых ячеек нет.
Отсюда вопрос бизнеса, а есть ли необходимость платить за оставшиеся 10%? Особенно если есть бесплатные решения.
Зашел на Ваш сайт толком не понял что к чему и зачем и самое главное отсутствуют цены, видно чтобы сразу не отпугивали посетителей.
Через тернии к SLA: как техподдержке быстрее закрывать заявки сотрудников