Service Desk *

Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.

Привет, Хабр! В блоге ЛАНИТ хочу поделиться историей внедрения Service Desk, которая продолжается до сих пор, точно, как в анекдоте, что ремонт нельзя закончить, его можно только прекратить. Я не буду подробно описывать все этапы внедрения. Расскажу только, с какими проблемами мы сталкивались на этом пути и как мы их решали. Возможно, наш практический опыт внедрения окажется для вас полезным.

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

Вопрос качественной сервисной поддержки ИТ-инфраструктуры на нашем рынке стоит остро — большинство заказчиков привыкли получать прямую, быструю и высококачественную сервисную поддержку от вендоров. Сейчас эти задачи легли на наши плечи и мы стараемся не просто держать марку, а работать даже лучше. 

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

При работе с SIP-телефонией достаточно часто можно встретить проблему отсутствия слышимости. Ошибка может возникнуть как на сети, так и на стороне SIP-устройства или приложения.

Хотелось бы поделиться сбоем, вероятность воспроизведения которого крайне мала - настолько, что техподдержке проще будет сослаться на ошибку из-за космических лучей: в ТП одного крупного оператора SIP-телефонии за 3 года зафиксировано 6 обращений, в которых такая проблема зафиксирована (из ~300.000 всего - 0.002%).

Как мы помогли ГУП «Водоканал Санкт-Петербурга» улучшить работу с обращениями жителей самого северного мегаполиса мира.

Водоканал управляет почти 18 000 км водопровода и канализации. Каждый день предприятие делает более комфортной жизнь 5 миллионов человек, десятков тысяч предприятий и организаций Петербурга. Чтобы ускорять работу с обращениями внешних потребителей и заявками сотрудников для оказания качественного сервиса, нужна налаженная работа с обращениями. Для этого предприятию требовалось современное и удобное решение. Им стала автоматизированная система управления обращениями на базе Naumen, которую внедрила СИГМА.  

Меня зовут Женя, я руководитель проектов. Хочу поделиться с Хабром кейсом моей команды: мы автоматизировали работу с обращениями клиентов в холдинге «Русклимат».

Проблема была в том, что сотрудники компании работали с большими объёмами данных в нескольких программах (служба поддержки в Naumen, претензионный отдел в 1С, сервисные центры на старом портале), из-за чего обработать и передать обращение другому подразделению было сложно.

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

Всем привет! Мы (Олег Герцев и Лиля Кондратьева) работаем в сервисном центре Positive Technologies и отвечаем за поддержку MaxPatrol SIEM и MaxPatrol VM соответственно.

Мы не только обрабатываем более десяти тысяч заявок в год, но и активно развиваем экспертизу клиентов и партнеров: среди наших сотрудников есть активные участники комьюнити-чата в Телеграме, в прошлом году мы выступали с лекциями на ДОД, а также готовили материалы для разработки курса по траблшутингу.

Ранее коллеги, работающие с PT Sandbox и PT NAD, рассказывали, с решением каких вопросов сталкиваются инженеры. Мы решили не останавливаться и в этой статье хотим приоткрыть завесу тайны над буднями специалистов поддержки уже других продуктов, приведя несколько историй на основе реальных событий. Кстати, пока мы готовили этот текст, так вдохновились, что придумали несколько тематических ребусов, к которым перейдем в самом конце. Пока же ныряем в будни техподдержки!

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

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

Если компания большая и у неё много юрлиц и филиалов, с менеджментом помогают подрядчики. Например, консалтинговая компания ДРТ, для которой моя команда автоматизировала данный процесс. В этом кейсе я покажу, какое решение для управления комплаенсом мы создали.

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

Ответ простой: "Серебряной пули нет, задачу нужно разбивать на части и использовать разные инструменты для решения разных проблем".

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

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.

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

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

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

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

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

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

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

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

Это кейс бэк-офиса онлайн-школы «Академия Йоги». HR-специалисты, юристы, IT-поддержка, бухгалтерия обрабатывают ежемесячно более 240 заявок, и с помощью Kaiten смогли автоматизировать рутинные процессы и увеличить скорость обработки задач. 

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

ScanPC

Утилита сканирующая удалённый ПК и показывающяя версию ОС, информацию о дисках, железе, открытых портах из списка (22,445,80,8080,3389,5900,1112,2575,10050), установленных принтерах, пользователях вошедших в систему, список профилей пользователей в папке C:\Users, размер системных папок и фалов, папки с документами в профилях пользователей размером больше 100МБ.

Как правило управлять ИТ-активами предлагается с помощью методологии ITAM — IT Asset Management. Этот метод связывает ИТ-активы с договорной и финансовой информацией, чтобы компания могла учитывать общие затраты. 

Однако на практике ITAM может быть слишком трудозатратен для малого и среднего бизнеса, одна из главных задач которого — оказывать хороший сервис. Гибкая service desk система вполне способна закрыть задачи по управлению ИТ-активами без приобретения дополнительной системы ITAM. Я расскажу почему это так и поделюсь конкретными кейсами внедрения учёта ИТ-активов с помощью ITSM.

Привет, Хабр! В продолжении темы, связанной с внедрением Каталога ИТ-услуг в компании, хочу разобрать достаточно популярный вопрос (не знаю, как у других, но у нас так точно) – зачем нужно возиться с услугами, если все пользователи работают с системами? Логичнее же «идти от систем», чем каких-то «никому не понятных услуг». Давайте разбираться и взвешивать все «за» и «против». Пусть каждый сам для себя решит, как эффективно выстроить процесс управления ИТ в общем и, взаимодействие с бизнесом, в частности.

Всем привет! В этой статье я поделюсь четвёртым выпуском рубрики Открытый микрофон, в котором Иван Хахарев, ведущий аналитик Департамента системного анализа в Спортмастере, выступил с докладом про то, как создать службу поддержки, которая ляжет на большинство систем. Такая разработка может помочь проанализировать продукт, улучшить UX или даже провести реинжиниринг. 

Мы подобрали экспертов, которые делятся своей экспертизой и мнением, их комментарии - ниже по тексту. 

Приходите в комментарии, задавайте вопросы или делитесь своей экспертизой! 

Система service desk в развивающейся компании должна быть не просто стабильной. Она должна быть масштабируемой, омниканальной, гибкой и легко настраиваемой. В статье рассказали о том, как правильно подобранная service desk система улучшила работу в ИТ-службе.