Difference between revisions of "IM Support Service/Wanted"

Revision as of 10:15, 31 October 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пожелания

Сервис

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

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

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

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

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

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

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

Клиенты

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

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

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

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

Клиентское ПО

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

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

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

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

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

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

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

Операторы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Администраторы

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

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

Аналитики

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

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

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

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

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

Алгоритмы

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

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

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

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

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

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

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

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

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

Хуки

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

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

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

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

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

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

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

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

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

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

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

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