Difference between revisions of "IM Support Service/Wanted"

Latest revision as of 12:21, 3 November 2008

Список пожеланий для IM Support Service. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей.

Плохой вариант:

• Чтобы можно было грабить корованы

Хороший вариант:

• Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)

(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)

Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться.

Общая структура, терминология[edit]

Черновой вариант. На примере

Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя сервис поддержки. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)

На этом сервисе, заводится один или несколько узлов поддержки. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д.

Каждый узел получает свой контактный адрес (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать клиент — человек с вопросом.

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

Когда клиент пишет на контактный адрес — это прямой контакт, когда оператор от имени сервиса пишет клиенту — это обратный контакт

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

Пожелания[edit]

Сервис[edit]

• Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.

Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.

• Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты.
  Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)

• Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.

• Временные узлы поддержки. см соотвествующий юзекейс

• Расписание работы узла поддержки. Чтобы можно было указать дни недели и время работы узла поддержки. В остальное время узел может быть выключен или отвечать стандартным сообщением "обратитесь в рабочее время ...". Выключение узла по расписанию лучше производить в "мягком режиме" — не затрагивая активные чаты с клиентами.

Интерфейсы, роли, возможности[edit]

Клиенты[edit]

Те, у кого проблемы

• Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится).

• Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса:
  • online -- есть свободные операторы
  • away -- есть свободные операторы, но они AFK
  • dna -- все операторы заняты
  • n/a -- все операторы offline
  • offline -- сервис не работает

• Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.

Клиентское ПО[edit]

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

• Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).

• Форма с чатом на сайте сервиса поддержки.

Собственный клиент[edit]

Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.

• Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору.

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

Операторы[edit]

Те, кто решает проблемы

• AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.

• Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)

• Пригласить другого оператора в чат. (чат на три человека)

• Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата.

• Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.

• Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)

• Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.

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

Текстовый интерфейс оператора[edit]

Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.

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

•  !history. Подтянуть историю прошлых разговоров с этим клиентом

•  !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)

•  !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq

•  !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в юзекейсах.

•  !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.

• Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)

Администраторы[edit]

Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.

• Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.

Аналитики[edit]

Хотят все знать.

• Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.

• Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне.

• Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре.

• Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.

Алгоритмы[edit]

Поиск свободного оператора[edit]

Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:

• Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка).

• Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.

• Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.

• Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.

• Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.

• Расписание работы оператора. (Часы, дни недели, и т.п., сменный график). Если оператор в сети, свободен, но по расписанию он должен отдыхать, то не трогать его.

Программные интерфейсы[edit]

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

Хуки[edit]

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

• Оператор открыл/закрыл чат с клиентом.

• Оператор перенаправил клиента другому оператору.

• Оператор вышел в онлай, ушел в оффлай/afk и т.д.

• Клиент обратился с вопросом и встал в очередь

• Клиент вошел в чат с оператором.

• Клиент закрыл чат с оператором.

Запросы информации[edit]

Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка.

• Вытянуть историю чата по времени, ID чата, по оператору и клиенту.

• Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.

• Получить статистику (ту же, которая доступна аналитикам).

Управление[edit]

Для автоматизации рутинных задач по управлению сервисом нужны веревочки которые можно дергать из вне.

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

• Перемещение операторов из одной группы в другую (в пределах узла, между узлами и т.д.)

• Добавление оператора (его JID-а), удаление.

• Отправка сообщений операторам группы, в чаты с клиентам, в чат с определенным клиентом, в чат с определенным оператором. Для всяких широковещательных автоматических объявлений.