Идеальный хелпдеск

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

    На наш взгляд, «идеальное» приложение для работы службы поддержки должно быть абстрагировано от природы запросов (тикетов). В потоке запросов должно быть можно обрабатывать и пресейл-вопросы, и сообщения в форуме, и заказы на туры, и заявки на приемку в ремонт аппаратуры. Приложение должно обеспечивать работу с потоком запросов, распределенных по разным отделам, где в каждом отделе настроен свой рабочий процесс (воркфлоу). Должен быть REST API, должно быть можно оказывать поддержку пользователей из своего любимого почтовика, а не обязательно через веб-интерфейс — приложение должно самостоятельно маршрутизировать все взаимодействия.

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



    Приглашаем к дискуссии в комменты к посту или в блог на сайте Вебасиста.
    Webasyst
    Компания

    Похожие публикации

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 17

      +1
      У нас, к примеру, воркфлоу обработки запроса строится на основе статусов запроса: новый, на обсуждении, закрыт. Если оператор не знает, что ответить клиенту, он отправляет запрос на обсуждение на уровень выше (техконсультанту, админу, разработчику), т.е. инициирует внутреннее обсуждение запроса. Когда ответ подготовлен, оператор пишет и отправляет ответ клиенту.
      Наверное, это стандартная схема. Однако, интересно было бы узнать и о других вариантах организации обработки запросов, которые применяются в ваших компаниях и группах.
        0
        А что такое хелпдеск? С точки зрения организационной структуры предприятия. Кому он подчиняется? И в чьих интересах работает?
          0
          Хелпдеск — служба поддержки ru.wikipedia.org/wiki/Служба_технической_поддержки
            0
            И все же, кто по-вашему, ее начальник?
              0
              Подчинение хэлпдеска, скорее зависит от приоритетов компании, её стратегии: комерческий отдел или технический отдел.
          0
          Один из вопросов, который хотелось бы обсудить: критерии, по которым оценивается приоритет запросов. Начиная от вручную выставленных «срочно — не срочно», заканчивая изменением приоритета за деньги клиентом (а что, ведь и такое бывает). Нужно ли? Если да, то какие схемы применяются у вас в работе?
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              Могу лишь сказать исходя из своего опыта работы в крупной компании.
              Система приоритетов в идеале неплоха: каждому приоритету регламентированное время решения проблемы, как следствие возможность гарантировать клиенту сроки и описывать их в договоре гарантировать перерасчет услуг при превышении этого времени (клиенто-ориентированность на лицо). Как вытекающее из системы приоритетов более удобная отчетность, анализ причинах превышения времени решения проблемы.

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

              Палка о двух концах.

              Система приоритетов должна быть гибкой и генерироваться самой системой.
              Лично мое мнение, система должна в реальном времени анализировать работу сотрудников. Чем меньше сотрудник загружен на данный момент, тем больше вероятность, что система назначит на него проблему, естественно анализируя общее число обработанных проблем. Адекватней будет система будильников, которая будет выделять ответственному отделу определенное время на решение проблемы, в зависимости от приоритета (и пусть сотрудники не знают этот приоритет).
              Например:
              1 приоритет (скрыт от сотрудников): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 1час -> при координации на отдел расчетов, сотруднику этого отдела выделено 2.5 часа и т.д.
              3 приоритет (скрыт от сотрудника): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 2часа -> при координации на отдел расчетов, сотруднику этого отдела выделено 4 часа и т.д.
              и приоритезировать тикеты согласно оставшемуся времени (показывать в списке очередность с которой сотрудник должен смотреть проблемы)
              +2
              Спасибо за картинку — теперь я буду знать как рисовать ТЗ! (не шучу).
                +1
                Мы так почти все техзадания пишем (тоже не шучу :-)
                +1
                каким вы видите ваш идеальный хелпдеск

                Однозначно не таким как как хелпдеск от IBM.
                Извините, наболело…
                  0
                  напишите скрипт интеграции сторонего модуля в БД WA, типа инсталятора, с ясным API. будет только польза.
                    +3
                    М-р-р-р, какой макет! :)
                      0
                      Самый лучший service desk, пока не идеальный, как мне видится,
                      1. Должен соответствовать ITIL, начиная от поддержки процессов управления инцидентами и проблемами, заканчивая подсчетом метрик,
                      2. Должен обладать хорошим интерфейсом. Потому что это слабое звено большинства решений. При заведении инцидента например, нужно вводить множество полей, так что должны быть шаблончики. Ну и еще по мелочи должны быть подобные решения для ускорения работы операторов. Интерфейс должен быть и для заявителей.
                        0
                        3. Должен интегрироваться с Configuration Management — системами, системами мониторинга, и многим другим.
                        0
                        Предлагаю не изобретать велосипед и посмотреть в Service Operations ITIL. там прекрастно описан хелпдеск таким каким он должен быть.
                          0
                          А идеальный хелпдеск для кого? Ведь действительно сильно зависит от размера компании (и чуть меньше — от специфики деятельности).

                          Угодить всем не получится.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое