Одно из первых приложений, которое мы собираемся выпустить на базе фреймворка Вебасист — это приложение «Поддержка» для организации поддержки клиентов.
Делать мы его будем, в первую очередь, чтобы обеспечить работу собственной службы поддержки (в первую очередь не потому, что для себя, а потому что это будет первым внедрением). Наша техподдержка пережила уже два поколения версий приложений, мы многому научились за это время, и на этот раз хотим сделать «идеальный инструмент»: платформу для работы с запросами (тикетами), которую можно будет настроить для работы с произвольной бизнес-логикой. От пресейл-вопросов и запросов в техподдержку до заказов на туры или приемки в ремонт аппаратуры. Приложение будет обеспечивать работу с потоком тикетов, распределенных по разным отделам, где в каждом отделе — свой рабочий процесс (воркфлоу).
Но каким бы завершенным ни было наше представление о приложении, нам хотелось бы посмотреть на «Поддержку» с другой стороны. Поэтому мы предлагаем вам рассказать каким вы видите ваш идеальный хелпдеск.
Мы видим следующие обязательные моменты в приложении:
— приложение должно быть одним большим маршрутизатором потоков в службу поддержки, где каждый поток (отдел) маршрутизируется по своим правилам;
— в первую очередь надо обеспечить обработку запросов по электронной почте, причем использовать веб-интерфейс приложения должно быть не обязательно: должно быть можно просто ответить на письмо из любимого почтового клиента, и приложение само его обработает, переслав ответ напрямую клиенту по почте или добавив новую запись в журнал обработки запроса (если это ответ на внутреннее обсуждение запроса, например);
— у приложения должен быть фронтенд: открытая база данных запросов в формате примерно как в сервисе «Реформал» или на stackoverflow.com; должно быть голосование и комментирование запросов, опубликованных во фронтенде;
— должен быть REST API;
— запросы могут приходить из разных источников и не только по электронной почте; в поток, вообще говоря, должно быть можно «запустить» запросы разной природы: заказы, уведомления от платежных систем, сообщения из форума и т.д. Такое расширение функционала должно обеспечиваться плагинами.
Приглашаем к дискуссии в комменты.
9 комментариев
У нас, к примеру, воркфлоу обработки запроса строится на основе статусов запроса: новый, на обсуждении, закрыт. Если оператор не знает, что ответить клиенту, он отправляет запрос на обсуждение на уровень выше (техконсультанту, админу, разработчику), т.е. инициирует внутреннее обсуждение запроса. Когда ответ подготовлен, оператор пишет и отправляет ответ клиенту.
ответитьА у вас как?
Один из вопросов, который хотелось бы обсудить: критерии, по которым оценивается приоритет запросов. Начиная от вручную выставленных "срочно — не срочно", заканчивая изменением приоритета за деньги клиентом (а что, ведь и такое бывает). Нужно ли? Если да, то какие схемы применяются у вас в работе?
ответитьЯ вижу, контингент комментаторов состоит, в основном, из ботов :)
ответитьФишка любой хэлпдеск-системы - это ее узконаправленность под те или иные задачи. На рынке есть (и даже успешно продаются) продукты, которые являются своего рода универсальными пакетами, и которые могут быть использованы как службой поддержки интернет-провайдера, так и офисным системным администратором. Но при всем этом зачастую во всех сферах применения такие системы имеют целый ворох минусов, которые не представляется возможным исправить. И в качестве заказчиков таких систем чаще всего выступают те компании, которые на текущий момент просто не могут позволить себе заказать разработку собственного ПО.
Я все это к чему. На мой взгляд, приложение в первую очередь должно быть модульным. Если даже базовый пакет состоит из модулей, а также есть возможность самостоятельно создавать / модифицировать модули - идеал.
Второй пункт по важности (опять же имхо) - это количество интегрированных для пользователя средств коммуникаций. То есть клиент при составлении запросов (опять же в идеале) не должен чувствовать разницу, отправляя сообщения через http, по e-mail, с помощью онлайн-консультанта или даже через смс-сообщения. Иными словами, Вы в основном делаете упор на удобстве сотрудников хэлпдеска, в то время как удобство, в первую очередь, должно быть для внешнего пользователя.
А вы видели Openfire? Мне нравится там хелпдеск часть, кстати и построено на xmpp.
ответитьОчень хотелось бы видеть в системе хелпдеска интергацию с крупными системами мониторинга, такими как nagios, centreon, zabbix, cacti. Как правило систему ориентируют на пользователей но и администраторам что-то должно достаться.
ответитьпосмотрите Itil и "Итилиум" там как раз очень много по этому поводу есть, можно даже вебинар бесплатный заказать, чтобы посмотреть возможности
ответитьДействительно было много комментариев от ботов. Пока блог работает на прототипе приложения «Блог», и авторизацию пользователей еще ен прикруптили. Будем делать.
ответитьЗа пожелания относительно хелпдеска спасибо!
Согласен с комментарием RudW0lf.
ответитьИнтеграция с другими CRM и HD/SD системами необходима.
В частности ClearQuest. Былобы приятно при эскалации проблемы на уровень разработчиков/инженеров, чтобы например баг регистрировался автоматически в CQ и обеспечивал основные WF заявки в нем.
По поводу приоритетов, очень неплохо реализован функционал в HP SD.
В справочнике отправителей заявок (где заявителей можно дифференцировать по организации проекту и пр. что то-же очень важно) можно установить приоритет для конкретных пользователей (тем самым выделив VIP разных уровней)
А так-же например работая согласно SLA уже можно говорить приоритетах, если например выбирать сервисы автоматически для точек входа таких как почта, форум, заявка на коллбэк и пр.
И вручную для консультаций по телефону/ICQ/IRC/Skype и пр.
Ну и еще важный момент, это настраиваемые напоминания, и возможность массовых оповещений (например о новостях компании) в виде бегущей строки, и личных сообщений для сотрудников.
И отдельно оповещение конечных пользователей например о важных новостях компании или проф. работах.
И безусловно удобный модуль статистики по заявкам в разрезе проектов/тематик/сервисов/точек входа и пр.
А еще получать фидбэки от конечных пользователей, для сбора статистики по удовлетворенности уровнем сервиса.
Вобщем все выше написанное это конечно описание стандартного функционала разных HD/SD систем, и гдето он реализован лучше, гдето хуже, а хотелосьбы видеть все идеальным и в одной оболочке!
Те задачи которые Вы поставили перед собой безусловно важные, но это только маленькая толика того, что нужно учесть...
Посмотрите продукт Omnitracker - с точки зрения возможностей фрейм ворка и вообще по теме сервисдеска. Из тяжелых продуктов с точки зрения внедренцев он "наиболее безвредный".
ответитьИдеальных сервисдесков, к сожалению не существует, попробуйте просто собрать все фичи (назначение, автоматическое назначение, назначение по правилам, все виды назначения приоритетов, юзер сюрвей и т.д.) и пихнуть в одну коробку. Получится хорошо, но не идеально.