Help Desk Software *

Организовать чат в Telegram для техподдержки — это очень легко. А вот реально наладить в этом мессенджере полноценную работу по поддержке пользователей очень сложно. Мы сами прошли этот путь, набили много шишек и разработали правила и инструменты, чтобы с ними справится. Эта статья — о них.

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

Напомню, что с вами на связи продуктовый аналитик отечественной service desk системы HubEx. В этом материале я продолжаю рассказывать про опыт нашего клиента, крупной сервисной компании «Брант». Одна из постоянных «болей» при оказании услуг — штрафные санкции со стороны клиента, в этом материале мы расскажем о том, как их избежать. И подскажем сервисным коллегам другие полезные советы, которые остановят руку кризиса.

С 16 марта наша команда ITSM 365 начала тестировать полноценную удаленную работу. Наши офисы в Екатеринбурге, Москве, Твери, Питере постепенно пустеют. Но мы, «переехав» домой, продолжаем оттачивать дзен при техподдержке клиентов и без паники решать другие рабочие вопросы.

Вместе с тем, оторвавшись от офисного пространства, все корпоративные сервисы от внутренних служб (ИТ, HR, бухгалтерии и других) получаем удаленно. Пришла пора протестировать, как это работает!

Пока мы еще на старте, поэтому хочу зафиксировать «как сейчас», а через какой-то период чекнуть, «что потом».

Год назад компания Axelos представила четвёртую версию ITIL, библиотеки лучших практик управления ИТ-услугами. Один из ключевых её разделов посвящён руководящим принципам ITIL 4 (The ITIL guiding principles).



Вместе с потоками создания ценностей и практиками, которые пришли на смену «процессам», семь руководящих принципов — основа ITIL 4. Принципы эти можно использовать ИТ-компаниям вне зависимости от стратегии, подхода к управлению и типа предоставляемых услуг. Как подчёркивают авторы библиотеки, каждый из принципов универсален и фундаментален. Вместе они воплощают основные идеи ITIL и ITSM.

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

Клиент при этом рассматривается не как потребитель услуги, просто получающий результат, а как партнёр. Это помогает клиенту влиять на качество и функциональность услуг.

Как раз в «Основах», первой из семи книг новой библиотеки, подробно изложены руководящие принципы ITIL 4. Базируются они на известных методиках: Agile, Lean, DevOps и т. п. То есть guiding principles помогают интегрировать лучшие практики в единый подход к управлению ИТ-услугами.

Снова на связи продуктовый аналитик отечественной service desk. В прошлый раз мы рассказывали про нашего клиента, сервисную компанию “Брант”, которая внедрила нашу платформу во время активного роста своего бизнеса.

Одновременно с ростом числа заявок у “Бранта” выросло и число объектов обслуживания — количественно и территориально. Как следствие, понадобилось больше разъездов на большие расстояния, и бюджет на расходы по ГСМ значительно увеличился. Как автоматизация диспетчерской службы помогла уберечь ее от этих расходов, хочу рассказать в этом посте.

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

Хочу поведать, как удалось автоматизировать трудоемкие бизнес-процессы одному из наших клиентов, сервисной компании “Брант”. Компания обратилась к нашей платформе, когда количество ее клиентов, и, соответственно, заявок на обслуживание, стало стремительно расти. Бизнес активно развивается, ведь это отлично, в чем подвох? В том, что резко растет и количество однотипных рутинных процессов, и эту опасность нельзя недооценивать. А кроме того, становится очевидно, что нельзя пользоваться теми же инструментами, которые работали, когда заявок было меньше.


Знакомо?

Итак, история спасения.

В каждой техподдержке свои процессы, тикет системы, принципы коммуникации с клиентами. Объединяет эти сервис службы – стремление бороться с пожирателями времени.

Когда в десятый раз за день в рабочем чате видишь «Не помнишь, как по такой заявке лучше ответить?», «Где лежит инструкция?», «Кинь ссылку, не могу найти», а в параллель коллега с порога «Не занят? Мне только спросить», начинаешь взывать к богам, которые хоть что-то слышали про Knowledge Management.

И все чаще мечтаешь не о новом мониторе в 49 дюймов, а о Базе знаний, да лучше с продуманной структурой, удобной навигацией и интеллектуальным поиском. И, пожалуйста, если можно, пусть это будет не склад папок на FTP и не портянка ссылок в Google Docs!

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

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

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

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

Кажется, что от этого не уйти, потому что техника есть техника: что-то ломается, теряется, портится… Но мы нашли неожиданное решение, как уменьшить нагрузку на хелпдеск и предельно сократить время ожидания нового аксессуара для сотрудников.

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

Бесплатный софт для бизнеса — спорная история. Компания, которая выбирает такое ПО, должна понимать, что либо ей придётся столкнуться с open source и искать разработчика на поддержку программы, либо принять бесплатную версию программы как есть, без надежды на поддержку, доработку и обучение. Так себе перспектива. Но это с позиций околоайтишного обывателя, который слова «open source» и «вендорское внедрение» выучил, а глубоко не погружался. А мы вот взяли и решили растолковать всё на примере одного популярного ПО, которое может пригодиться и большим, и маленьким компаниям. Давайте разбираться вместе.


Морали не будет, а вот выбор есть

Вот представьте, купили вы автомобиль, что вы будете делать? Своевременно проводить ТО, искать АЗС, где нет палёного бензина, мыть, полировать, покрывать воском  и всякими там нано-растворами и защищать сигнализацией — ну это если вы в здравом уме. Вряд ли вам придёт в голову бояться его заводить и только любоваться, заливать масло подешевле, купленное на трассе, затягивать его в пищевую плёнку, забивать на поломки до полного отказа тормозов и оставить защитную систему на потом. Логично? 

Казалось бы, с бизнесом всё должно быть ещё осторожнее, внимательнее и педантичнее. Отнюдь: посмотришь на иной бизнес и думаешь, на чём же он до сих пор держится, где скрыт его недюжинный ресурс, чтобы пережить все проблемы? А потом смотришь: а нет, ликвидировался, с долгами, в бегах… А ведь можно было работать и работать. Почему так происходит, в чём заключается нелюбовь к бизнесу и как это исправить, мы сейчас и обсудим.

А вы — любите свой бизнес?


Источник. Думаете, вискарь? Ан нет, валерьянка!

Как я уже писал в статье 7 основополагающих принципов ITIL, 4 аспекта управления услугами ITIL заслуживают отдельной статьи.

Для тех кто знаком с ITIL v3, эти аспекты покажутся знакомыми. В книге «Service Design», было описание 4P (the 4P of Service Design) проектирования услуг: Продукты (Products), Процессы (Processes), Персонал (People), Партнеры (Partners/Suppliers). Сейчас ITIL предлагает опираться на данные аспекты на всем жизненном цикле создания продукта или услуги, конечной целью которых является создание ценности (value).

Этой статьи не должно было быть: вроде как и Хабр не жалобная книга, и у меня частная история далеко не хабровской компании. Но именно на Хабре я получил не очень корректное отношение одной компании и познакомился аж с двумя другими в самый подходящий момент — в момент, когда я искал хелпдеск. Я протестировал и перебрал 15 разных хелпдеск-систем и не смог выбрать из них ни одну! Уже прочувствовали всю драму? Рано! В общем, я перекипел, выпустил пар, заставил потестировать своих коллег, немного выдохнул и решил не бомбить на эмоциях, а написать текст — о том, как требования могут соотноситься с ПО и о том, что разработчики иногда несколько оторваны от реальности. Хотя без эмоций не получится, потому что я был по обе стороны софта: и заказчиком, и разработчиком, а значит, понимаю обоих. Но никого не хочу оправдывать. Простите, если будет лонгрид. Может и лонг, но зато экшен!

Duran (вроде бы)

Это перевод ряда статей из блога одного опенсорсного хелпдеска (и общего почтового ящика) на Laravel. История данного проекта — хороший пример того, как опенсорс-сообщество может не просто повторить, но и местами улучшить дизайн и функционал уже готового распиаренного коммерческого продукта, а также стимулировать его развитие и изменение к лучшему.

Сегодня ценность ITIL многими ставится под сомнение. Одни утверждают, что это дорого и работает только в крупных инфраструктурах, другие говорят, что применять можно даже в небольших структурах. Я придерживаюсь идеи, что истина где-то посередине. Полностью следовать рекомендациям ITIL в небольших компаниях попросту дорого и нецелесообразно, а бывает, что и в крупных не все будет работать, именно поэтому ITIL это библиотека рекомендаций, а не строгих стандартов и применять их нужно с умом, опираясь на исходные данные.



Но, к счастью, есть часть библиотеки, которая может помочь всем, и это основополагающие принципы ITIL (в последней версии их 7). Я считаю, что эти принципы стоит применять даже за пределами управления ИТ-услугами. Часть из них применима даже в обычной повседневной жизни.

В силу специфики бизнеса (разработка Help Desk системы для автоматизации сервисной B2B поддержки), нам приходится быть максимально погруженными в тему саппорта во всех смыслах этого слова. Ежедневно мы общаемся с сотнями компаний в России и СНГ, как следствие, очень часто наше общение выходит за рамки вопросов «автоматизации». Именно поэтому в 2017 году мы опубликовали, собственное исследование уровня дохода в технической поддержке, ставшее, пожалуй, первым столь серьезным и детальным отраслевым подобным исследованием в принципе. В отчете этого, 2019 года, мы обновили данные и попробовали объяснить их изменения качественно, опираясь на общее представление о рынке.

Цифровые технологии проникли, пожалуй, уже во все сегменты бизнеса. Грузоперевозки, рестораны и кафе, обслуживание объектов ЖКХ — везде есть датчики, логгеры, оборудование или программное обеспечение, требующее обслуживания квалифицированным техническим персоналом. А вместе с ростом этих потребностей развивается и сфера выездного обслуживания — field service management. Поговорим о ее особенностях.

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

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

Вы легко отзываетесь на просьбу помочь? Вам не трудно сделать пару лишних задач? Вы молча переделываете не очень хорошую работу за коллегами или подчинёнными? Скорее всего, ваша рабочая нагрузка заставляет вас «перегреваться». 

Нередко в малом бизнесе мы занимаемся всем подряд, не замечая того: тестовый сервер будет перезапущен, о чём мы сами и сообщим в чате клиенту вместо инженера; баннер повесить — да погоди, у меня есть доступ к админке, готово; код аналитики — да давай я тебе Tag Manager повешу и покажу, как через него любые теги размещать; вот тут в выгрузке были подозрительные пики и провалы, я тебе сделал дополнительную детализацию… Особенно тяжело ситуация обстоит в компаниях, которые активно работают по заявкам клиентов, и каждый сотрудник берёт в работу самые разноплановые задачи. Как итог: усталость, выгорание, ошибки и завалы собственных невыполненных задач. Знакомо? Давайте искать причины и выходы под катом.

Всем привет! Мы разрабатываем Okdesk — облачный Helpdesk для постпродажного сервисного обслуживания b2b клиентов. Среди пользователей нашего продукта — ЦТО и АСЦ по кассовой технике, интеграторы по автоматизации торговли, службы эксплуатации ритейл-сетей, компании обслуживающие коммерческую недвижимость и многие другие сервисные компании. Спецификой сервиса в таких компаниях является большое количество работы «в полях»: работа с оборудованием, техническое обслуживание инфраструктуры, планово-профилактические работы — всё это требует физического нахождения специалиста на объекте. Это обстоятельство накладывает ряд дополнительных требований к Helpdesk-решению, а именно: мобильное рабочее место инженера и визуализация запланированных работ на карте с отображением ближайших сотрудников. Мобильное приложение Okdesk для инженеров (под iOS и Android) появилось довольно давно и мы продолжаем его активно развивать. А вот отображение заявок и ближайших сотрудников на карте мы выпустили на днях.



Но речь в статье пойдет не о новой функциональности — заинтересованные могут получить 14-ти дневный бесплатный триал-аккаунт на сайте и познакомиться с системой самостоятельно. Речь пойдет о выборе картографических сервисов для реализации функциональности и какие продуктовые требования к ним предъявлять. Если для вашего проекта задача выбора решений для картографических модулей актуальна — добро пожаловать под кат.

Какое корпоративное ПО установлено в вашей компании? CRM, система управления проектами, хелпдеск, ITSM-система, 1С (тут точно угадали)? У вас есть чёткое ощущение, что все эти программы дублируют друг друга? На самом деле, пересечение функций, действительно, бывает, многие вопросы может закрыть универсальная система автоматизации — мы сторонники этого подхода. Однако бывают подразделения или группы сотрудников, у которых должен быть «свой» софт — из соображений безопасности, функциональности, удобства и т.д. Сегодня мы на своём примере обсудим, как в ИТ-зоопарке компании сочетаются CRM и хелпдеск-система. А ещё короткий опрос в конце — хотим знать ваше мнение.


У него не было хелпдеска — тогда бы он молча ответил на заявку, не теряя клиентов и не выходя из себя. Любите своих саппортёров, они — фронтофис!