Editing IM Support Service/Wanted

Список пожеланий для [[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 сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. 

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

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

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

== Пожелания ==

=== Сервис === 

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

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

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

* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]

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

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

==== Клиенты ====
''Те, у кого проблемы''

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

* Чтобы статус контактного адреса узла (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-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см  в [[IM Support Service/UseCases|юзекейсах]].

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

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

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

==== Аналитики ====
''Хотят все знать.''

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

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

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

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

=== Алгоритмы ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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