Difference between revisions of "IM Support Service/Wanted"

From JaWiki (Jabber/XMPP wiki)
Jump to: navigation, search
(Общая структура, терминология)
(Поиск свободного оператора)
 
(11 intermediate revisions by the same user not shown)
Line 18: Line 18:
 
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д.  
 
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д.  
  
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом ''(обратный контакт тоже должен быть возможен)''.
+
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.  
  
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и  будут отвечать на вопросы клиентов.  
+
К каждому узлу привязываются '''операторы''' сотрудники магазина, которые разбираются в специализации узла и  будут отвечать на вопросы клиентов.  
 +
 
 +
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''
  
 
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.
 
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.
Line 33: Line 35:
 
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)
 
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)
  
* Возможность контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки).
+
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.
 +
 
 +
* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]
 +
 
 +
* Расписание работы узла поддержки. Чтобы можно было указать дни недели и время работы узла поддержки. В остальное время узел может быть выключен или отвечать стандартным сообщением "обратитесь в рабочее время ...". Выключение узла по расписанию лучше производить в "мягком режиме" — не затрагивая активные чаты с клиентами.
  
 
=== Интерфейсы, роли, возможности ===
 
=== Интерфейсы, роли, возможности ===
Line 52: Line 58:
  
 
===== Клиентское ПО =====
 
===== Клиентское ПО =====
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.
+
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.
 +
 
 +
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).
 +
 
 +
* Форма с чатом на сайте сервиса поддержки.
 +
 
 +
====== Собственный клиент ======
 +
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.
  
 
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору.  
 
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору.  
Line 113: Line 126:
  
 
==== Поиск свободного оператора ====
 
==== Поиск свободного оператора ====
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:
+
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:
  
 
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка).  
 
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка).  
  
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.
+
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.
  
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.
+
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.
  
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться  с клиентом, не трогать.  
+
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться  с клиентом, не трогать.
 +
 
 +
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.
 +
 
 +
* Расписание работы оператора. (Часы, дни недели, и т.п., сменный график). Если оператор в сети, свободен, но по расписанию он должен отдыхать, то не трогать его.
  
 
=== Программные интерфейсы ===
 
=== Программные интерфейсы ===
Line 146: Line 163:
 
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.
 
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.
  
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.
+
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.
  
 
* Получить статистику (ту же, которая доступна аналитикам).
 
* Получить статистику (ту же, которая доступна аналитикам).
 +
 +
==== Управление ====
 +
Для автоматизации рутинных задач по управлению сервисом нужны веревочки которые можно дергать из вне.
 +
 +
* Временное отключение, включение операторов в узлах, групп в узлах, самих узлов, всего сервиса. (все это с разрывом текущих чатов и без). Например для настройки гибкой системы расписаний прямо из внутреннего табельного учета, где учитываются все праздники выходные, отпуска, сокращенные рабочие дни и т.п.
 +
 +
* Перемещение операторов из одной группы в другую (в пределах узла, между узлами и т.д.)
 +
 +
* Добавление оператора (его JID-а), удаление.
 +
 +
* Отправка сообщений операторам группы, в чаты с клиентам, в чат с определенным клиентом, в чат с определенным оператором. Для всяких широковещательных автоматических объявлений.

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-а), удаление.
  • Отправка сообщений операторам группы, в чаты с клиентам, в чат с определенным клиентом, в чат с определенным оператором. Для всяких широковещательных автоматических объявлений.