http://wiki.jrudevels.org/api.php?action=feedcontributions&user=Feez&feedformat=atomJaWiki (Jabber/XMPP wiki) - User contributions [en]2024-03-28T18:46:26ZUser contributionsMediaWiki 1.25.1http://wiki.jrudevels.org/index.php?title=Migration:How_to_move_friends&diff=7423Migration:How to move friends2008-12-12T16:35:50Z<p>Feez: Исправил вступление</p>
<hr />
<div>Ура! Наконец, после долгой борьбы со своенравной ICQ, вы решились перейти на джаббер. Вы потратили свое время, чтобы найти стабильный [[Jabber|джаббер]]-[[Server|сервер]], удобный [[Client|клиент]] и разобраться с [[Терминология|терминологией]]. Остался один вопрос: "что я буду там делать без 200-друзей в моем контакт листе?". <br />
<br />
С первого взгляда это Проблема. Уговорить 100-200 человек пройти тот же путь, кажется, нереальной задачей. И, может быть, оно так и есть. Поэтому перед тем, как действовать, надо оценить шансы, а чтобы правильно оценить, надо разобраться в сути задачи.<br />
<br />
== Чем друзья держат вас ==<br />
<br />
Ответ простой: они вам нужны. Это может быть необходимость в квалифицированном мнении, или мнении человека, которого вы уважаете, связь с родственниками и одноклассниками или, наконец, просто те, с кем разговор приносит удовольствие. Есть и другой тип необходимости: вы вынуждены. Например, ваш начальник или заказчик и выбрал этот тип связи и тут ничего не поделаешь. <br />
<br />
Но, обратите внимание, что как друзья тянут вас, так и вы тянете их. <b>Это обоюдная зависимость!</b> Если ей правильно и к месту пользоваться, то она может потянуть похлеще долгих уговоров.<br />
<br />
== Как пересаживать ==<br />
<br />
(поставьте себя на его место)<br />
<br />
(когда можно переубеждать, когда лучше этого не делать)<br />
<br />
(как убрать "меня устраивает все")<br />
<br />
== Разделяем друзей на группы ==<br />
<br />
(разделяй и властвуй, действительная доля людей, которых надо пересадить, пересадить?)<br />
<br />
(картинка)<br />
<br />
(краткое описание)<br />
<br />
=== Первая группа: без зависимостей ===<br />
<br />
Это случайные знакомые, контакты, которые вы нашли в поиске, чтобы просто поболтать. Это те, которых вы удаляете во время периодических чисток ростера. Удалите их и сейчас. <br />
<br />
Сюда же попадают старые друзья, с которыми вы не общаетесь, но держите контакт "на всякий случай". Запишите UIN вместе с телефоном и адресом в адресную книгу и удалите. Помните, вы не удаляете друга, не рвете отношения, вы обрываете средство связи, которое вам приносит больше неудобств чем пользы! Другие средства остаются.<br />
<br />
=== Вторая группа: зависимы от вас ===<br />
<br />
Это ваши подчиненные, люди, которые у вас периодически бесплатно консультируются. Обратите внимание на "бесплатно". Платные консультации, это уже четвертая группа. <br />
<br />
Это группа чуть-чуть сложнее первой, но с другой стороны, эти люди скорее всего перейдут на джаббер за вами без уговоров. Просто рассылкой или сообщением на сайте оповестите, что вы ушли в джаббер и скажите свой новый JID.<br />
<br />
=== Третья группа: вы зависите от них ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(если связь односторонняя, "онлайн на вопрос")<br />
<br />
(если многосторонняя, но есть телефон, почта и т.п.)<br />
<br />
=== Четвертая группа: взаимная зависимость ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(попытаться метод "онлайна на вопрос")<br />
<br />
== Итог ==<br />
<br />
(про то, что не надо боятся рвать связи. цинизм) <br />
<br />
(знакомство с новыми людьми)</div>Feezhttp://wiki.jrudevels.org/index.php?title=PR&diff=7422PR2008-12-12T15:28:26Z<p>Feez: /* Как мне пересадить контак-лист в 200 человек с аськи */</p>
<hr />
<div><big>'''Пропаганда Джаббера'''</big><br />
<br />
Эта часть распространения Джаббера конечно не так важна, как добавление в клиенты и серверы новых фич протокола, но она необходима для того, чтобы обычные пользователи хотя бы знали что такое джаббер, как сейчас знают что такое Linux. <br />
<br />
== Материал для пропаганды ==<br />
* [[Articles|Статьи]]<br />
* [[PR/Pictures|Картинки]]<br />
* [[PR/Posters|Плакаты]]<br />
* [[PR/Presentations|Презентации]]<br />
<br />
== Дискуссии и агитация ==<br />
Ниже будут описаны основные ошибки и проблемы, которые встречались мне во время чтения разных дискуссий и тезисы с обоснованиями и расшифровкой, которые можно использовать, чтобы не свалиться в [[w:Религиозные войны (сленг)|холивар]]. В качестве аргумента разумно использовать отсылку к [[UsageCases|опыту больших компаний]], которые используют в своих жизненных процессах Jabber.<br />
<br />
<br />
=== Психологические ошибки ===<br />
Вообще, зная психологию человека, легче добиться своего, но, все же, НЛП, софистику и прочие грязные методы спора использовать не надо. Знание психологии нужно, чтобы не оступиться, чтобы не попадать в ловушки, когда собеседник перестает слушать (это еще терпимо) или становится врагом (а это уже плохо).<br />
{{todo|найти материалы для чтения}}<br />
<br />
==== Не надо заставлять ====<br />
Человек по своей сути консервативен. Он с неохотой будет менять уже сложившиеся вещи и все попытки заставить его их изменить будет воспринимать в штыки.<br />
Это подсознательная реакция, поэтому не стоит начинать разговор со слов "выкинь аську, иди в джаббер" или подобных — с большой вероятностью спор окончится +1 к противникам джаббера. Также, даже если вы мирно начали разговор, то он все равно может скатиться на "только не надо меня заставлять". Это надо отслеживать и останавливать превентивно. Пусть целью будет рассказать о том чем он лучше, познакомить, но не пересадить. Такая цель реальнее и безопаснее.<br />
<br />
=== Логические ошибки ===<br />
Логика — это матчасть дискуссии. Если стоит задача вынести пользу из дискуссии, то логику знать просто необходимо. Без неё зачастую очень трудно увидеть ошибку и тем более объяснить в чем она заключается. <br />
<br />
Математическая схема простая: дискуссия возникает когда встречаются тезис и антитезис. Во первых они должны быть несовместны и различаться только в одно месте. Если мест несколько, то скорее всего можно разбить на несколько дискуссий и пар тезис/антитезис. После того, как установлены тезис и антитезис необходимо удостовериться, что все понятия знакомы, и оба собеседника одинаково понимают их смысл. Это очень важный этап, так как в основном несогласие проявляется именно в понимании слов, и сверка определений позволяет закончить дискуссию досрочно. И последний этап — док-во, или просто обоснование. Доказывать могут как тезис так и антитезис и собеседники могут не соглашаться с ними. В этом случае появляются другие пары-ветки тезис/антитезис, которые тоже надо доказывать. Еще один важный момент — финал. Если не удалось нормально доказать ни тезис ни антитезис, то истинна неустановленна и никто не был прав. В ход идут вероятности и жизненный опыт, т.е. каждый остается при своём ;)<br />
<br />
В жизни не часто можно увидеть дискуссию идущую по этим этапам, и практически никогда дискуссию проходящую так формально. В основном тезисы не формулируются и меняются на ходу, второй этап пропускается и т.п., а дискуссия начинается прямо с финала :), но знание матчасти позволяет четко держать линию, не уходить в оффтопики и другие вопросы, всегда помнить все "дерево" дискуссии и главный тезис. В жизни редко удается что-нибуть доказать, но привести достаточное обоснование вполне реально, также можно доказать, что собеседник ошибся. <br />
<br />
{{todo|ссылки на матчасть по спорам и софизмам}}<br />
<br />
==== &laquo;Открытый протокол&raquo; не равно &laquo;Открытый код&raquo; ====<br />
В споре можно неосознано перейти от обсуждения открытого Jabber-а к обсуждению открытого Linux-а или другого [[СПО]]. Конечно общее есть, но не следует их смешивать в одну кучу. Открытый протокол это не тоже самое, что открытое ПО и тем более СПО.<br />
{{todo|привести примеры ошибок}}<br />
<br />
==== Смешивание типов сравнения ====<br />
Jabber с другими IM-сетями можно сравнивать как в перспективе так и в настоящем. <br />
<br />
Сравнивая в перспективе допускают, что Jabber стал таким же большим и распространенным как, например, сейчас [[ICQ]] для России, и описывают плюсы и минусы между этими двумя вариантами. Т.е. они как бы находятся в равном положении с одинаковым числом пользователей, с одинаковым качеством и количеством клиентов. Цель: показать преимущество джаббера.<br />
<br />
Сравнивая в настоящем, рассматривают именно настоящую ситуацию в реальном мире для определенного человека. Цель: пересадить.<br />
<br />
В первом случае позиции Jabber-а гораздо крепче чем во втором. Поэтому, если оба спорщика не видят разницы, то скорее всего каждый перейдет в свою плоскость и спор сведется к разговору на двух разных языках. Лучше сразу определиться с типом сравнения и со своей целью, обозначить её с самого начала и вежливо отклонять все попытки подменить типы и записать, например, отсутствие друзей как недостаток технологии. <br />
<br />
Хорошим индикатором может служить следующий прием: в уме поменяйте местами Jabber и ICQ. Если после этого приведенный недостаток Jabber-а станет недостатком ICQ, то это из сравнения в настоящем, иначе из сравнения в перспективе. <br />
<br />
Для примера, сравнение в настоящем: мало клиентов, клиенты неудобны, все друзья в аське, работа идет через аську, в аське больше русских.<br />
<br />
Сравнения в перспективе: нет глобального поиска по всем пользователям джаббера, нет престижных шестизнаков.<br />
<br />
=== Тезисы для использования ===<br />
Ниже будут приведены тезисы, которые можно будет использовать и обоснования к ним. Если вы будете использовать какой-нибуть из них, добавьте ссылку на форум/блог сюда. Надо учится на своих ошибках и победах :)<br />
<br />
==== Открытость и расширяемость протокола в первую очередь полезна самим пользователям ====<br />
Если оппонент отвергает открытость и расширяемость протокола XMPP как плюс джаббера для простого пользователя фразой, типа &laquo;''это все для гиков, пользовалю же нужны удобные клиенты, свистелки всякие, красивые эффекты''&raquo;, то можно попробовать показать [[PR/OpenForUsers|чем же открытость протокола полезна именно пользователям]].<br />
<br />
'''Применения''': http://habrahabr.ru/blog/im/39067.html<br />
<br />
==== Список &laquo;Мне нужно&raquo; ====<br />
Оппонент может отбросить преимущества джаббера фразой типа &laquo;''мне нужно вот это, это, это и то. В аське это есть, она меня устраивает. Джаббер не нужен''&raquo;. <br />
<br />
Если оппонент &mdash; хороший знакомый, то можно попытаться угадать с его потребностями и показать интересную функцию джаббера, которая может оказаться полезной. <br />
<br />
Если первый способ не подходит, то можно попробовать объяснить [[PR/ListOfNecessary|суть списка желаний и как джаббер на него влияет]].<br />
<br />
=== Проблемные вопросы ===<br />
Тупики и вопросы, на которые джабберу нечего ответить. Ответы на них :)<br />
<br />
==== Нет поля для указания пола ====<br />
Это вопрос времени. В новом стандарте [[Profile|Профиль]] он есть, и даже больше. Осталось только его реализовать в клиентах и серверах :)<br />
<br />
==== Нет поля для интересов ====<br />
См. выше, в [[Profile|профиле]] все будет<br />
<br />
==== Нет единой базы пользователей ====<br />
С одной стороны это проблема, а с другой стороны это плюс. Единая база несовместима с децентрализованной сетью Джаббер. <br />
<br />
'''Первый вариант''': предложить использовать Gtalk {{todo|проверить много ли там наших и есть ли там нормальый поиск по полу и возрасту}} <br />
<br />
'''Второй вариант''': это должны делать службы знакомств, социальные сети, а не IM-сети. <br />
<br />
'''Возможный контрответ''': попросить оппонента рассказать как в ICQ заполнить vcard (для друзей, деловых партнеров) и при этом запретить себя искать.<br />
<br />
==== Как мне пересадить контак-лист в 200 человек с аськи ====<br />
{{todo|Миграционные моменты я опишу или ты про что-то другое? и зачем 200? зачем пересаживать?}}<br />
<br />
* [[Migration:How to move friends|Как перевести друзей в джаббер]]<br />
<br />
Для облегчения процесса с нашей стороны (JRuDevels), нужно реализовать пункты изложенные в [[Migration:Programme|Миграционной программе]].</div>Feezhttp://wiki.jrudevels.org/index.php?title=Migration:How_to_move_friends&diff=7421Migration:How to move friends2008-12-12T15:27:34Z<p>Feez: /* Вторая группа: зависимы от вас */</p>
<hr />
<div>Вы наконец решились перейти на джаббер. Смены протоколов, перебои в работоспособности надоели (или привели к убыткам) и вы потратили свое время, чтобы найти стабильный джаббер [[Server|сервер]], нормальный удобный джаббер-[[Client|клиент]] и разобраться с [[Терминология|терминологией]]. Остался один вопрос: "что я буду там делать без 200-друзей в моем контакт листе?". <br />
<br />
С первого взгляда это проблема. Уговорить 100-200 человек пройти тот же путь — кажется нереальной задачей. И может оно так и есть. Поэтому для начала надо оценить. А чтобы оценить, надо разобраться в сути.<br />
<br />
== Чем друзья держат вас ==<br />
<br />
Ответ простой: они вам нужны. Это может быть необходимость в квалифицированном мнении, или мнении человека, которого вы уважаете, связь с родственниками и одноклассниками или, наконец, просто те, с кем разговор приносит удовольствие. Есть и другой тип необходимости: вы вынуждены. Например, ваш начальник или заказчик и выбрал этот тип связи и тут ничего не поделаешь. <br />
<br />
Но, обратите внимание, что как друзья тянут вас, так и вы тянете их. <b>Это обоюдная зависимость!</b> Если ей правильно и к месту пользоваться, то она может потянуть похлеще долгих уговоров.<br />
<br />
== Как пересаживать ==<br />
<br />
(поставьте себя на его место)<br />
<br />
(когда можно переубеждать, когда лучше этого не делать)<br />
<br />
(как убрать "меня устраивает все")<br />
<br />
== Разделяем друзей на группы ==<br />
<br />
(разделяй и властвуй, действительная доля людей, которых надо пересадить, пересадить?)<br />
<br />
(картинка)<br />
<br />
(краткое описание)<br />
<br />
=== Первая группа: без зависимостей ===<br />
<br />
Это случайные знакомые, контакты, которые вы нашли в поиске, чтобы просто поболтать. Это те, которых вы удаляете во время периодических чисток ростера. Удалите их и сейчас. <br />
<br />
Сюда же попадают старые друзья, с которыми вы не общаетесь, но держите контакт "на всякий случай". Запишите UIN вместе с телефоном и адресом в адресную книгу и удалите. Помните, вы не удаляете друга, не рвете отношения, вы обрываете средство связи, которое вам приносит больше неудобств чем пользы! Другие средства остаются.<br />
<br />
=== Вторая группа: зависимы от вас ===<br />
<br />
Это ваши подчиненные, люди, которые у вас периодически бесплатно консультируются. Обратите внимание на "бесплатно". Платные консультации, это уже четвертая группа. <br />
<br />
Это группа чуть-чуть сложнее первой, но с другой стороны, эти люди скорее всего перейдут на джаббер за вами без уговоров. Просто рассылкой или сообщением на сайте оповестите, что вы ушли в джаббер и скажите свой новый JID.<br />
<br />
=== Третья группа: вы зависите от них ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(если связь односторонняя, "онлайн на вопрос")<br />
<br />
(если многосторонняя, но есть телефон, почта и т.п.)<br />
<br />
=== Четвертая группа: взаимная зависимость ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(попытаться метод "онлайна на вопрос")<br />
<br />
== Итог ==<br />
<br />
(про то, что не надо боятся рвать связи. цинизм) <br />
<br />
(знакомство с новыми людьми)</div>Feezhttp://wiki.jrudevels.org/index.php?title=Migration:How_to_move_friends&diff=7420Migration:How to move friends2008-12-12T15:21:45Z<p>Feez: /* Первая группа: без зависимостей */</p>
<hr />
<div>Вы наконец решились перейти на джаббер. Смены протоколов, перебои в работоспособности надоели (или привели к убыткам) и вы потратили свое время, чтобы найти стабильный джаббер [[Server|сервер]], нормальный удобный джаббер-[[Client|клиент]] и разобраться с [[Терминология|терминологией]]. Остался один вопрос: "что я буду там делать без 200-друзей в моем контакт листе?". <br />
<br />
С первого взгляда это проблема. Уговорить 100-200 человек пройти тот же путь — кажется нереальной задачей. И может оно так и есть. Поэтому для начала надо оценить. А чтобы оценить, надо разобраться в сути.<br />
<br />
== Чем друзья держат вас ==<br />
<br />
Ответ простой: они вам нужны. Это может быть необходимость в квалифицированном мнении, или мнении человека, которого вы уважаете, связь с родственниками и одноклассниками или, наконец, просто те, с кем разговор приносит удовольствие. Есть и другой тип необходимости: вы вынуждены. Например, ваш начальник или заказчик и выбрал этот тип связи и тут ничего не поделаешь. <br />
<br />
Но, обратите внимание, что как друзья тянут вас, так и вы тянете их. <b>Это обоюдная зависимость!</b> Если ей правильно и к месту пользоваться, то она может потянуть похлеще долгих уговоров.<br />
<br />
== Как пересаживать ==<br />
<br />
(поставьте себя на его место)<br />
<br />
(когда можно переубеждать, когда лучше этого не делать)<br />
<br />
(как убрать "меня устраивает все")<br />
<br />
== Разделяем друзей на группы ==<br />
<br />
(разделяй и властвуй, действительная доля людей, которых надо пересадить, пересадить?)<br />
<br />
(картинка)<br />
<br />
(краткое описание)<br />
<br />
=== Первая группа: без зависимостей ===<br />
<br />
Это случайные знакомые, контакты, которые вы нашли в поиске, чтобы просто поболтать. Это те, которых вы удаляете во время периодических чисток ростера. Удалите их и сейчас. <br />
<br />
Сюда же попадают старые друзья, с которыми вы не общаетесь, но держите контакт "на всякий случай". Запишите UIN вместе с телефоном и адресом в адресную книгу и удалите. Помните, вы не удаляете друга, не рвете отношения, вы обрываете средство связи, которое вам приносит больше неудобств чем пользы! Другие средства остаются.<br />
<br />
=== Вторая группа: зависимы от вас ===<br />
<br />
(кто)<br />
<br />
(оповестить, удалить из аськи, ждать когда придут в джаббер)<br />
<br />
=== Третья группа: вы зависите от них ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(если связь односторонняя, "онлайн на вопрос")<br />
<br />
(если многосторонняя, но есть телефон, почта и т.п.)<br />
<br />
=== Четвертая группа: взаимная зависимость ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(попытаться метод "онлайна на вопрос")<br />
<br />
== Итог ==<br />
<br />
(про то, что не надо боятся рвать связи. цинизм) <br />
<br />
(знакомство с новыми людьми)</div>Feezhttp://wiki.jrudevels.org/index.php?title=Migration:How_to_move_friends&diff=7419Migration:How to move friends2008-12-12T15:14:48Z<p>Feez: /* Как именно ваши друзья держат вас */</p>
<hr />
<div>Вы наконец решились перейти на джаббер. Смены протоколов, перебои в работоспособности надоели (или привели к убыткам) и вы потратили свое время, чтобы найти стабильный джаббер [[Server|сервер]], нормальный удобный джаббер-[[Client|клиент]] и разобраться с [[Терминология|терминологией]]. Остался один вопрос: "что я буду там делать без 200-друзей в моем контакт листе?". <br />
<br />
С первого взгляда это проблема. Уговорить 100-200 человек пройти тот же путь — кажется нереальной задачей. И может оно так и есть. Поэтому для начала надо оценить. А чтобы оценить, надо разобраться в сути.<br />
<br />
== Чем друзья держат вас ==<br />
<br />
Ответ простой: они вам нужны. Это может быть необходимость в квалифицированном мнении, или мнении человека, которого вы уважаете, связь с родственниками и одноклассниками или, наконец, просто те, с кем разговор приносит удовольствие. Есть и другой тип необходимости: вы вынуждены. Например, ваш начальник или заказчик и выбрал этот тип связи и тут ничего не поделаешь. <br />
<br />
Но, обратите внимание, что как друзья тянут вас, так и вы тянете их. <b>Это обоюдная зависимость!</b> Если ей правильно и к месту пользоваться, то она может потянуть похлеще долгих уговоров.<br />
<br />
== Как пересаживать ==<br />
<br />
(поставьте себя на его место)<br />
<br />
(когда можно переубеждать, когда лучше этого не делать)<br />
<br />
(как убрать "меня устраивает все")<br />
<br />
== Разделяем друзей на группы ==<br />
<br />
(разделяй и властвуй, действительная доля людей, которых надо пересадить, пересадить?)<br />
<br />
(картинка)<br />
<br />
(краткое описание)<br />
<br />
=== Первая группа: без зависимостей ===<br />
<br />
(кто)<br />
<br />
(можно просто удалить, особенно если есть другой способ связи)<br />
<br />
=== Вторая группа: зависимы от вас ===<br />
<br />
(кто)<br />
<br />
(оповестить, удалить из аськи, ждать когда придут в джаббер)<br />
<br />
=== Третья группа: вы зависите от них ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(если связь односторонняя, "онлайн на вопрос")<br />
<br />
(если многосторонняя, но есть телефон, почта и т.п.)<br />
<br />
=== Четвертая группа: взаимная зависимость ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(попытаться метод "онлайна на вопрос")<br />
<br />
== Итог ==<br />
<br />
(про то, что не надо боятся рвать связи. цинизм) <br />
<br />
(знакомство с новыми людьми)</div>Feezhttp://wiki.jrudevels.org/index.php?title=Migration:How_to_move_friends&diff=7418Migration:How to move friends2008-12-12T15:00:21Z<p>Feez: Немного циничная инструкция по пересадке друзей (шаблон). Дискуссия приветствуется.</p>
<hr />
<div>Вы наконец решились перейти на джаббер. Смены протоколов, перебои в работоспособности надоели (или привели к убыткам) и вы потратили свое время, чтобы найти стабильный джаббер [[Server|сервер]], нормальный удобный джаббер-[[Client|клиент]] и разобраться с [[Терминология|терминологией]]. Остался один вопрос: "что я буду там делать без 200-друзей в моем контакт листе?". <br />
<br />
С первого взгляда это проблема. Уговорить 100-200 человек пройти тот же путь — кажется нереальной задачей. И может оно так и есть. Поэтому для начала надо оценить. А чтобы оценить, надо разобраться в сути.<br />
<br />
== Как именно ваши друзья держат вас ==<br />
(ICQ сеть, <br />
<br />
<br />
== Как пересаживать ==<br />
<br />
(поставьте себя на его место)<br />
<br />
(когда можно переубеждать, когда лучше этого не делать)<br />
<br />
(как убрать "меня устраивает все")<br />
<br />
== Разделяем друзей на группы ==<br />
<br />
(разделяй и властвуй, действительная доля людей, которых надо пересадить, пересадить?)<br />
<br />
(картинка)<br />
<br />
(краткое описание)<br />
<br />
=== Первая группа: без зависимостей ===<br />
<br />
(кто)<br />
<br />
(можно просто удалить, особенно если есть другой способ связи)<br />
<br />
=== Вторая группа: зависимы от вас ===<br />
<br />
(кто)<br />
<br />
(оповестить, удалить из аськи, ждать когда придут в джаббер)<br />
<br />
=== Третья группа: вы зависите от них ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(если связь односторонняя, "онлайн на вопрос")<br />
<br />
(если многосторонняя, но есть телефон, почта и т.п.)<br />
<br />
=== Четвертая группа: взаимная зависимость ===<br />
<br />
(кто)<br />
<br />
(не уговаривайте!)<br />
<br />
(попытаться метод "онлайна на вопрос")<br />
<br />
== Итог ==<br />
<br />
(про то, что не надо боятся рвать связи. цинизм) <br />
<br />
(знакомство с новыми людьми)</div>Feezhttp://wiki.jrudevels.org/index.php?title=PR&diff=7417PR2008-12-12T14:36:22Z<p>Feez: /* Как мне пересадить контак-лист в 200 человек с аськи */</p>
<hr />
<div><big>'''Пропаганда Джаббера'''</big><br />
<br />
Эта часть распространения Джаббера конечно не так важна, как добавление в клиенты и серверы новых фич протокола, но она необходима для того, чтобы обычные пользователи хотя бы знали что такое джаббер, как сейчас знают что такое Linux. <br />
<br />
== Материал для пропаганды ==<br />
* [[Articles|Статьи]]<br />
* [[PR/Pictures|Картинки]]<br />
* [[PR/Posters|Плакаты]]<br />
* [[PR/Presentations|Презентации]]<br />
<br />
== Дискуссии и агитация ==<br />
Ниже будут описаны основные ошибки и проблемы, которые встречались мне во время чтения разных дискуссий и тезисы с обоснованиями и расшифровкой, которые можно использовать, чтобы не свалиться в [[w:Религиозные войны (сленг)|холивар]]. В качестве аргумента разумно использовать отсылку к [[UsageCases|опыту больших компаний]], которые используют в своих жизненных процессах Jabber.<br />
<br />
<br />
=== Психологические ошибки ===<br />
Вообще, зная психологию человека, легче добиться своего, но, все же, НЛП, софистику и прочие грязные методы спора использовать не надо. Знание психологии нужно, чтобы не оступиться, чтобы не попадать в ловушки, когда собеседник перестает слушать (это еще терпимо) или становится врагом (а это уже плохо).<br />
{{todo|найти материалы для чтения}}<br />
<br />
==== Не надо заставлять ====<br />
Человек по своей сути консервативен. Он с неохотой будет менять уже сложившиеся вещи и все попытки заставить его их изменить будет воспринимать в штыки.<br />
Это подсознательная реакция, поэтому не стоит начинать разговор со слов "выкинь аську, иди в джаббер" или подобных — с большой вероятностью спор окончится +1 к противникам джаббера. Также, даже если вы мирно начали разговор, то он все равно может скатиться на "только не надо меня заставлять". Это надо отслеживать и останавливать превентивно. Пусть целью будет рассказать о том чем он лучше, познакомить, но не пересадить. Такая цель реальнее и безопаснее.<br />
<br />
=== Логические ошибки ===<br />
Логика — это матчасть дискуссии. Если стоит задача вынести пользу из дискуссии, то логику знать просто необходимо. Без неё зачастую очень трудно увидеть ошибку и тем более объяснить в чем она заключается. <br />
<br />
Математическая схема простая: дискуссия возникает когда встречаются тезис и антитезис. Во первых они должны быть несовместны и различаться только в одно месте. Если мест несколько, то скорее всего можно разбить на несколько дискуссий и пар тезис/антитезис. После того, как установлены тезис и антитезис необходимо удостовериться, что все понятия знакомы, и оба собеседника одинаково понимают их смысл. Это очень важный этап, так как в основном несогласие проявляется именно в понимании слов, и сверка определений позволяет закончить дискуссию досрочно. И последний этап — док-во, или просто обоснование. Доказывать могут как тезис так и антитезис и собеседники могут не соглашаться с ними. В этом случае появляются другие пары-ветки тезис/антитезис, которые тоже надо доказывать. Еще один важный момент — финал. Если не удалось нормально доказать ни тезис ни антитезис, то истинна неустановленна и никто не был прав. В ход идут вероятности и жизненный опыт, т.е. каждый остается при своём ;)<br />
<br />
В жизни не часто можно увидеть дискуссию идущую по этим этапам, и практически никогда дискуссию проходящую так формально. В основном тезисы не формулируются и меняются на ходу, второй этап пропускается и т.п., а дискуссия начинается прямо с финала :), но знание матчасти позволяет четко держать линию, не уходить в оффтопики и другие вопросы, всегда помнить все "дерево" дискуссии и главный тезис. В жизни редко удается что-нибуть доказать, но привести достаточное обоснование вполне реально, также можно доказать, что собеседник ошибся. <br />
<br />
{{todo|ссылки на матчасть по спорам и софизмам}}<br />
<br />
==== &laquo;Открытый протокол&raquo; не равно &laquo;Открытый код&raquo; ====<br />
В споре можно неосознано перейти от обсуждения открытого Jabber-а к обсуждению открытого Linux-а или другого [[СПО]]. Конечно общее есть, но не следует их смешивать в одну кучу. Открытый протокол это не тоже самое, что открытое ПО и тем более СПО.<br />
{{todo|привести примеры ошибок}}<br />
<br />
==== Смешивание типов сравнения ====<br />
Jabber с другими IM-сетями можно сравнивать как в перспективе так и в настоящем. <br />
<br />
Сравнивая в перспективе допускают, что Jabber стал таким же большим и распространенным как, например, сейчас [[ICQ]] для России, и описывают плюсы и минусы между этими двумя вариантами. Т.е. они как бы находятся в равном положении с одинаковым числом пользователей, с одинаковым качеством и количеством клиентов. Цель: показать преимущество джаббера.<br />
<br />
Сравнивая в настоящем, рассматривают именно настоящую ситуацию в реальном мире для определенного человека. Цель: пересадить.<br />
<br />
В первом случае позиции Jabber-а гораздо крепче чем во втором. Поэтому, если оба спорщика не видят разницы, то скорее всего каждый перейдет в свою плоскость и спор сведется к разговору на двух разных языках. Лучше сразу определиться с типом сравнения и со своей целью, обозначить её с самого начала и вежливо отклонять все попытки подменить типы и записать, например, отсутствие друзей как недостаток технологии. <br />
<br />
Хорошим индикатором может служить следующий прием: в уме поменяйте местами Jabber и ICQ. Если после этого приведенный недостаток Jabber-а станет недостатком ICQ, то это из сравнения в настоящем, иначе из сравнения в перспективе. <br />
<br />
Для примера, сравнение в настоящем: мало клиентов, клиенты неудобны, все друзья в аське, работа идет через аську, в аське больше русских.<br />
<br />
Сравнения в перспективе: нет глобального поиска по всем пользователям джаббера, нет престижных шестизнаков.<br />
<br />
=== Тезисы для использования ===<br />
Ниже будут приведены тезисы, которые можно будет использовать и обоснования к ним. Если вы будете использовать какой-нибуть из них, добавьте ссылку на форум/блог сюда. Надо учится на своих ошибках и победах :)<br />
<br />
==== Открытость и расширяемость протокола в первую очередь полезна самим пользователям ====<br />
Если оппонент отвергает открытость и расширяемость протокола XMPP как плюс джаббера для простого пользователя фразой, типа &laquo;''это все для гиков, пользовалю же нужны удобные клиенты, свистелки всякие, красивые эффекты''&raquo;, то можно попробовать показать [[PR/OpenForUsers|чем же открытость протокола полезна именно пользователям]].<br />
<br />
'''Применения''': http://habrahabr.ru/blog/im/39067.html<br />
<br />
==== Список &laquo;Мне нужно&raquo; ====<br />
Оппонент может отбросить преимущества джаббера фразой типа &laquo;''мне нужно вот это, это, это и то. В аське это есть, она меня устраивает. Джаббер не нужен''&raquo;. <br />
<br />
Если оппонент &mdash; хороший знакомый, то можно попытаться угадать с его потребностями и показать интересную функцию джаббера, которая может оказаться полезной. <br />
<br />
Если первый способ не подходит, то можно попробовать объяснить [[PR/ListOfNecessary|суть списка желаний и как джаббер на него влияет]].<br />
<br />
=== Проблемные вопросы ===<br />
Тупики и вопросы, на которые джабберу нечего ответить. Ответы на них :)<br />
<br />
==== Нет поля для указания пола ====<br />
Это вопрос времени. В новом стандарте [[Profile|Профиль]] он есть, и даже больше. Осталось только его реализовать в клиентах и серверах :)<br />
<br />
==== Нет поля для интересов ====<br />
См. выше, в [[Profile|профиле]] все будет<br />
<br />
==== Нет единой базы пользователей ====<br />
С одной стороны это проблема, а с другой стороны это плюс. Единая база несовместима с децентрализованной сетью Джаббер. <br />
<br />
'''Первый вариант''': предложить использовать Gtalk {{todo|проверить много ли там наших и есть ли там нормальый поиск по полу и возрасту}} <br />
<br />
'''Второй вариант''': это должны делать службы знакомств, социальные сети, а не IM-сети. <br />
<br />
'''Возможный контрответ''': попросить оппонента рассказать как в ICQ заполнить vcard (для друзей, деловых партнеров) и при этом запретить себя искать.<br />
<br />
==== Как мне пересадить контак-лист в 200 человек с аськи ====<br />
{{todo|Миграционные моменты я опишу или ты про что-то другое? и зачем 200? зачем пересаживать?}}<br />
<br />
* [[Migration:How to move friends|Как перевести друзей]]<br />
<br />
Для облегчения процесса с нашей стороны (JRuDevels), нужно реализовать пункты изложенные в [[Migration:Programme|Миграционной программе]].</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7344IM Support Service/Wanted2008-11-03T11:21:37Z<p>Feez: /* Поиск свободного оператора */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]<br />
<br />
* Расписание работы узла поддержки. Чтобы можно было указать дни недели и время работы узла поддержки. В остальное время узел может быть выключен или отвечать стандартным сообщением "обратитесь в рабочее время ...". Выключение узла по расписанию лучше производить в "мягком режиме" — не затрагивая активные чаты с клиентами.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
* Расписание работы оператора. (Часы, дни недели, и т.п., сменный график). Если оператор в сети, свободен, но по расписанию он должен отдыхать, то не трогать его.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).<br />
<br />
==== Управление ====<br />
Для автоматизации рутинных задач по управлению сервисом нужны веревочки которые можно дергать из вне.<br />
<br />
* Временное отключение, включение операторов в узлах, групп в узлах, самих узлов, всего сервиса. (все это с разрывом текущих чатов и без). Например для настройки гибкой системы расписаний прямо из внутреннего табельного учета, где учитываются все праздники выходные, отпуска, сокращенные рабочие дни и т.п.<br />
<br />
* Перемещение операторов из одной группы в другую (в пределах узла, между узлами и т.д.)<br />
<br />
* Добавление оператора (его JID-а), удаление.<br />
<br />
* Отправка сообщений операторам группы, в чаты с клиентам, в чат с определенным клиентом, в чат с определенным оператором. Для всяких широковещательных автоматических объявлений.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7343IM Support Service/Wanted2008-11-03T11:18:29Z<p>Feez: /* Программные интерфейсы */ Добавил управление из вне</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]<br />
<br />
* Расписание работы узла поддержки. Чтобы можно было указать дни недели и время работы узла поддержки. В остальное время узел может быть выключен или отвечать стандартным сообщением "обратитесь в рабочее время ...". Выключение узла по расписанию лучше производить в "мягком режиме" — не затрагивая активные чаты с клиентами.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).<br />
<br />
==== Управление ====<br />
Для автоматизации рутинных задач по управлению сервисом нужны веревочки которые можно дергать из вне.<br />
<br />
* Временное отключение, включение операторов в узлах, групп в узлах, самих узлов, всего сервиса. (все это с разрывом текущих чатов и без). Например для настройки гибкой системы расписаний прямо из внутреннего табельного учета, где учитываются все праздники выходные, отпуска, сокращенные рабочие дни и т.п.<br />
<br />
* Перемещение операторов из одной группы в другую (в пределах узла, между узлами и т.д.)<br />
<br />
* Добавление оператора (его JID-а), удаление.<br />
<br />
* Отправка сообщений операторам группы, в чаты с клиентам, в чат с определенным клиентом, в чат с определенным оператором. Для всяких широковещательных автоматических объявлений.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7342IM Support Service2008-10-31T12:50:17Z<p>Feez: /* Обсуждение этого проекта в Сети */</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* <strike>[[IM Support Service/Specification|Техническое задание]]</strike> (сбора фич должно быть достаточно)<br />
* Выбор минимума из фич, которые будут реализованы в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
* http://cybersocialism.livejournal.com/39008.html<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»<br />
* LOR Talks: «[http://www.linux.org.ru/view-message.jsp?msgid=3211804&lastmod=1225371359976 Техподдержка через IM]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7341IM Support Service/UseCases2008-10-31T09:18:13Z<p>Feez: /* Использование временных узлов поддержки */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Использование временных узлов поддержки ====<br />
<br />
Сотрудник компании Боб некоторое время общался с клиентом Клодом через почту или систему тикетов. Наконец, чтобы помочь Клоду собрать отладочную информацию, Боб решил перейти к более быстрому общению через IM (телефон не подошел, так как нужен был обмен командами, ссылками и скриншотами).<br />
<br />
Отправить Клода на контактный адрес ''постоянного'' узла поддержки Боб не может, так как нет гарантий, что сервис соединит его именно с Бобом, а не с другим оператором (или Боб вообще не является оператором).<br />
<br />
Написать со своего рабочего JID-а Боб тоже не может (возможные причины: у клиента нет Jabber-а или вообще нет IM, прямые контакты с клиентами запрещены политикой так как не сохраняется история, и т.д.)<br />
<br />
Поэтому Боб создает ''временный узел поддержки'' с уникальным ID (например, temp3456653) и URL (содержит ID).<br />
<br />
В качестве оператора Боб добавляет свой рабочий JID. Кроме того он указывает сколько клиентов может быть в чате, открывать ли публичный доступ к истории и др. параметры.<br />
<br />
Затем Боб почтой или через систему тикетов отправляет Клоду URL к чату и ID узла.<br />
<br />
Клод может перейти по URL и сразу попадет в web-чат с Боб-ом. Или Клод может с помощью своего IM-клиента открыть чат с любым ''постоянным'' узлом поддержки и вместо своего вопроса отправить !node temp3456653, тогда система переключит его на чат с Боб-ом.<br />
<br />
Когда вопрос будет улажен Боб и Клод покидают чат, узел удаляется, но история сохраняется. В следующий раз, когда кто-либо, перейдет по ссылке, оставленной в системе тикетов, он увидит историю этого чата.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7340IM Support Service/UseCases2008-10-31T09:16:56Z<p>Feez: /* Использование временных узлов поддержки */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Использование временных узлов поддержки ====<br />
<br />
Сотрудник компании Боб некоторое время общался с клиентом Клодом через почту или систему тикетов. Наконец Боб решил перейти к более быстрому общению через IM (телефон не подошел, так как нужен был обмен файлами и скриншотами).<br />
<br />
Отправить Клода на контактный адрес ''постоянного'' узла поддержки Боб не может, так как нет гарантий, что сервис соединит его именно с Бобом, а не с другим оператором (или Боб вообще не является оператором).<br />
<br />
Написать со своего рабочего JID-а Боб тоже не может (возможные причины: у клиента нет Jabber-а или вообще нет IM, прямые контакты с клиентами запрещены политикой так как не сохраняется история, и т.д.)<br />
<br />
Поэтому Боб создает ''временный узел поддержки'' с уникальным ID (например, temp3456653) и URL (содержит ID).<br />
<br />
В качестве оператора Боб добавляет свой рабочий JID. Кроме того он указывает сколько клиентов может быть в чате, открывать ли публичный доступ к истории и др. параметры.<br />
<br />
Затем Боб почтой или через систему тикетов отправляет Клоду URL к чату и ID узла.<br />
<br />
Клод может перейти по URL и сразу попадет в web-чат с Боб-ом. Или Клод может с помощью своего IM-клиента открыть чат с любым ''постоянным'' узлом поддержки и вместо своего вопроса отправить !node temp3456653, тогда система переключит его на чат с Боб-ом.<br />
<br />
Когда вопрос будет улажен Боб и Клод покидают чат, узел удаляется, но история сохраняется. В следующий раз, когда кто-либо, перейдет по ссылке, оставленной в системе тикетов, он увидит историю этого чата.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7339IM Support Service/UseCases2008-10-31T09:16:16Z<p>Feez: /* Использование временных узлов поддержки */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Использование временных узлов поддержки ====<br />
<br />
Оператор Боб некоторое время общался с клиентом Клодом через почту или систему тикетов. Наконец Боб решил перейти к более быстрому общению через IM (телефон не подошел, так как нужен был обмен файлами и скриншотами).<br />
<br />
Отправить Клода на контактный адрес ''постоянного'' узла поддержки Боб не может, так как нет гарантий, что сервис соединит его именно с Бобом, а не с другим оператором (или Боб вообще не является оператором).<br />
<br />
Написать со своего рабочего JID-а Боб тоже не может (возможные причины: у клиента нет Jabber-а или вообще нет IM, прямые контакты с клиентами запрещены политикой так как не сохраняется история, и т.д.)<br />
<br />
Поэтому Боб создает ''временный узел поддержки'' с уникальным ID (например, temp3456653) и URL (содержит ID).<br />
<br />
В качестве оператора Боб добавляет свой рабочий JID. Кроме того он указывает сколько клиентов может быть в чате, открывать ли публичный доступ к истории и др. параметры.<br />
<br />
Затем Боб почтой или через систему тикетов отправляет Клоду URL к чату и ID узла.<br />
<br />
Клод может перейти по URL и сразу попадет в web-чат с Боб-ом. Или Клод может с помощью своего IM-клиента открыть чат с любым ''постоянным'' узлом поддержки и вместо своего вопроса отправить !node temp3456653, тогда система переключит его на чат с Боб-ом.<br />
<br />
Когда вопрос будет улажен Боб и Клод покидают чат, узел удаляется, но история сохраняется. В следующий раз, когда кто-либо, перейдет по ссылке, оставленной в системе тикетов, он увидит историю этого чата.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7338IM Support Service/Wanted2008-10-31T09:15:22Z<p>Feez: /* Сервис */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]<br />
<br />
* Расписание работы узла поддержки. Чтобы можно было указать дни недели и время работы узла поддержки. В остальное время узел может быть выключен или отвечать стандартным сообщением "обратитесь в рабочее время ...". Выключение узла по расписанию лучше производить в "мягком режиме" — не затрагивая активные чаты с клиентами.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7333IM Support Service/Wanted2008-10-30T12:26:37Z<p>Feez: /* Сервис */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
* Временные узлы поддержки. см соотвествующий [[IM Support Service/UseCases#Использование временных узлов поддержки|юзекейс]]<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7332IM Support Service/UseCases2008-10-30T12:24:10Z<p>Feez: /* Использование временных узлов поддержки */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Использование временных узлов поддержки ====<br />
<br />
Оператор Боб некоторое время общался с клиентом Клодом через почту или систему тикетов. Наконец Боб решил перейти к более быстрому общению через IM (телефон не подошел, так как нужен был обмен файлами и скриншотами).<br />
<br />
Отправить Клода на контактный адрес ''постоянного'' узла поддержки Боб не может, так как нет гарантий, что сервис соединит его именно с Бобом, а не с другим оператором, или Боб вообще не является оператором.<br />
<br />
Написать со своего рабочего JID-а Боб тоже не может (возможные причины: у клиента нет Jabber-а или вообще нет IM, прямые контакты с клиентами запрещены политикой так как не сохраняется история, и т.д.)<br />
<br />
Поэтому Боб создает ''временный узел поддержки'' с уникальным ID (например, temp3456653) и URL (содержит ID).<br />
<br />
В качестве оператора Боб добавляет свой рабочий JID. Кроме того он указывает сколько клиентов может быть в чате, открывать ли публичный доступ к истории и др. параметры.<br />
<br />
Затем Боб почтой или через систему тикетов отправляет Клоду URL к чату и ID узла.<br />
<br />
Клод может перейти по URL и сразу попадет в web-чат с Боб-ом. Или Клод может с помощью своего IM-клиента открыть чат с любым ''постоянным'' узлом поддержки и вместо своего вопроса отправить !node temp3456653, тогда система переключит его на чат с Боб-ом.<br />
<br />
Когда вопрос будет улажен Боб и Клод покидают чат, узел удаляется, но история сохраняется. В следующий раз, когда кто-либо, перейдет по ссылке, оставленной в системе тикетов, он увидит историю этого чата.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7331IM Support Service/UseCases2008-10-30T12:20:54Z<p>Feez: /* Оператор */ Еще один кейс -- временные узлы поддержки</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Использование временных узлов поддержки ====<br />
<br />
Оператор Боб некоторое время общался с клиентом Клодом через почту или систему тикетов. Наконец Боб решил перейти к более быстрому общению через IM (телефон не подошел, так как нужен был обмен файлами и скриншотами).<br />
<br />
Отправить Клода на контактный адрес ''постоянного'' узла поддержки Боб не может, так как нет гарантий, что сервис соединит его именно с Бобом, а не с другим оператором, или Боб вообще не является оператором.<br />
<br />
Написать со своего рабочего JID-а Боб тоже не может (возможные причины: у клиента нет Jabber-а или вообще нет IM, прямые контакты с клиентами запрещены политикой так как не сохраняется история, и т.д.)<br />
<br />
Поэтому Боб создает ''временный узел поддержки'' с уникальным контактным адресом (например, temp3456653@support.shop.ru). temp3456653 — ID временного узла.<br />
<br />
В качестве оператора Боб добавляет свой рабочий JID. Кроме того он указывает сколько клиентов может быть в чате, открывать ли публичный доступ к истории и др. параметры.<br />
<br />
Затем Боб почтой или через систему тикетов отправляет Клоду URL к чату и ID узла.<br />
<br />
Клод может перейти по URL и сразу попадет в web-чат с Боб-ом. Или Клод может с помощью своего IM-клиента открыть чат с любым ''постоянным'' узлом поддержки и вместо своего вопроса отправить !node temp3456653, тогда система переключит его на чат с Боб-ом.<br />
<br />
Когда вопрос будет улажен Боб и Клод покидают чат, узел удаляется, но история сохраняется. В следующий раз, когда кто-либо, перейдет по ссылке, оставленной в системе тикетов, он увидит историю этого чата.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7330IM Support Service/Wanted2008-10-30T05:50:50Z<p>Feez: /* Собственный клиент */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.shop.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7329IM Support Service/Wanted2008-10-30T05:50:24Z<p>Feez: /* Клиентское ПО */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
У клиента не должно быть ограничений по выбору средства связи с техподдержкой.<br />
<br />
* Любая IM сеть и любой IM клиент, вплоть до самого дубового, который поддерживает только текстовый интерфейс (пересылка файлов в этом случае будет через web-сервер сервиса).<br />
<br />
* Форма с чатом на сайте сервиса поддержки.<br />
<br />
====== Собственный клиент ======<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.ru), добавить туда пару функций, выкинуть все лишнее, то получится замечательное ПО для обращения в техподдержку, которое можно прикладывать к дистрибутивам программ.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7328IM Support Service/Wanted2008-10-30T05:26:49Z<p>Feez: /* Запросы информации */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик), определенного узла, оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7327IM Support Service/Wanted2008-10-30T05:23:20Z<p>Feez: /* Поиск свободного оператора */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: отправляется приглашение в чат первому свободному, если он не ответил, то следующему свободному и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Порядок опроса с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: в этой все заняты, никто в этой не открыл чат в течении N минут, все отказались по N раз и т.д.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил в последний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент. Учитывать их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать.<br />
<br />
* Если разрешено несколько чатов у одного оператора одновременно, то те, кто уже разговаривают, должны опрашиваться в последнюю очередь.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7326IM Support Service/Wanted2008-10-30T05:14:54Z<p>Feez: /* Сервис */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки). Клиенту сообщения должны приходить с контактного адреса сервиса, а не от JID-а оператора.<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7325IM Support Service/Wanted2008-10-30T05:13:12Z<p>Feez: /* Общая структура, терминология */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному контактному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки).<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7324IM Support Service/Wanted2008-10-30T05:12:14Z<p>Feez: /* Общая структура, терминология */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом. <br />
<br />
К каждому узлу привязываются '''операторы''' — сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес — это '''прямой контакт''', когда оператор от имени сервиса пишет клиенту — это '''обратный контакт'''<br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки).<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7323IM Support Service/Wanted2008-10-30T05:09:36Z<p>Feez: /* Сервис */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом ''(обратный контакт тоже должен быть возможен)''.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных. <br />
''Комментарий: Люди способны вести больше одного диалога одновременно, поэтому эту настройку нужно либо вводить опционально (даже в рамках одной группы), либо с настройкой количества одновременных сессий.''<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
* Возможность обратного контакта клиента службой поддержки. Это может понадобится в случае, когда моментальное решение проблемы не возможно и требуется сообщение о результате решения (для ранее обращавшихся клиентов). Либо для срочного уведомления клиентов (обращавшихся или не обращавшихся ранее в службу поддержки).<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7319IM Support Service/Wanted2008-10-29T16:13:26Z<p>Feez: /* Операторы */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса (away, n/a, dnd и т.д.) или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7318IM Support Service/Wanted2008-10-29T16:11:43Z<p>Feez: /* Клиенты */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобится). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7317IM Support Service2008-10-29T15:55:05Z<p>Feez: /* Этапы разработки */</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* <strike>[[IM Support Service/Specification|Техническое задание]]</strike> (сбора фич должно быть достаточно)<br />
* Выбор минимума из фич, которые будут реализованы в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
* http://cybersocialism.livejournal.com/39008.html<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7316IM Support Service/UseCases2008-10-29T15:53:46Z<p>Feez: /* Отправка файла через передачу файлов по протоколу Jabber */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Боб выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл". Затем в диалоге открытия файла выбирает сам файл и нажимает "отправить".<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение" сервисом, то этот запрос перехватывает сам сервис и начинает приём файла к себе на сервер. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл отправляется Бобу в чат вместе со своим ID.<br />
<br />
Если все прошло нормально, Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7315IM Support Service/UseCases2008-10-29T15:51:05Z<p>Feez: /* Отправка файла через команду !file */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Боб хочет отправить клиенту pdf файл с документацией. <br />
<br />
Для этого он набирает !file в чате с клиентом. Как и все команды, эта скрывается от клиента и отображается только операторам. <br />
<br />
Бобу в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому адресу и видит там простую форму: <br />
<br />
(_____имя файла______) [Выбрать]<br />
(____описание________)<br />
[Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл, заполняет описание (потом легче будет его найти) и нажимает отправить. <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с его ID.<br />
<br />
Боб проверяет тот ли он файл разместил на сервер. Если все нормально, то Боб может отправить ссылку клиенту набрав !file <ID><br />
<br />
В следующий раз, когда Боб захочет отправить этот файл, и если он запомнил ID файла, то он сможет пропустить первые шаги по загрузке файла и сразу перейти к последней команде !file <ID>. Для поиска есть команда !sfile.<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Джо выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл", выбирает сам файл и нажимает отправить.<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение", то этот запрос перехватывает сервис и начинает приём файла. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с ID.<br />
<br />
Если все прошло нормально, Джо может отправить ссылку клиенту набрав !file ID<br />
<br />
В следующий раз, когда Джо захочет отправить этот файл, он сможет пропустить первые шаги по загрузке файла, если запомнил ID файла. Для поиска есть команда !sfile.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7314IM Support Service2008-10-29T15:43:24Z<p>Feez: /* Этапы разработки */ Нафиг строгое ТЗ (пока)</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* <strike>[[IM Support Service/Specification|Техническое задание]]</strike> (сбора фич должно быть достаточно)<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
* http://cybersocialism.livejournal.com/39008.html<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7313IM Support Service/Wanted2008-10-29T15:40:14Z<p>Feez: поправил введение</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. Можно писать в свободной форме, но постарайтесь указать как можно больше деталей. <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
(Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
Вторая просьба: ознакомтесь с терминологией ниже и постарайтесь её придерживаться. <br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7312IM Support Service/Wanted2008-10-29T15:35:51Z<p>Feez: /* Аналитики */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Cтатистика по узлу (по всем узлам сервиса). Параметры: количество клиентов, средняя продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7311IM Support Service/Wanted2008-10-29T15:32:04Z<p>Feez: Вынес описание и терминологию в начало. Немого вычистки текста.</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Общая структура, терминология ==<br />
''Черновой вариант. На примере''<br />
<br />
Магазин бытовой техники решил оказывать консультации через ICQ, Jabber-у, MSN и др. IM сети. Он поднимает у себя '''сервис поддержки'''. Это компонент к Jabber-серверу с адресом, например, support.example.ru. (адрес магазина -- example.ru)<br />
<br />
На этом сервисе, заводится один или несколько '''узлов поддержки'''. Каждый узел имеет свою специализацию. Например: вопросы продаж (sell@support.shop.ru), вопросы доставки (delivery@support.shop.ru), консультанты по оборудованию (consulting@support.shop.ru) и т.д. <br />
<br />
Каждый узел получает свой '''контактный адрес''' (тот, что в скобках) в сети Jabber, а также с помощью транспортов или напрямую по одному адресу в других IM сетях. На контактный адрес будет писать '''клиент''' — человек с вопросом.<br />
<br />
К каждому узлу привязываются '''операторы''' -- сотрудники магазина, которые разбираются в специализации узла и будут отвечать на вопросы клиентов. <br />
<br />
Когда клиент пишет на контактный адрес свой вопрос, он попадает в '''очередь''' — сервис пытается найти свободного оператора. Когда оператор найден, они вместе с клиентом попадают в общий '''чат'''. '''История''' чата сохраняется сервисом и может быть доступна в дальнейшем.<br />
<br />
== Пожелания ==<br />
<br />
=== Сервис === <br />
<br />
* Один оператор в нескольких узлах. При этом, если оператор разговаривает с клиентом через один узел, то он считается занятым и во всех остальных.<br />
<br />
* Группы в пределах одного узла поддержки. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус контактного адреса узла (JID, UIN, и т.д.), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что оператора нет за компом и не надо перенаправлять на него клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другой узел. Но не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в чат. (чат на три человека)<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в истории этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно показать клиенту с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние узла. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре. Время проведенное текущими клиентами в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая их приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смогут общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk и т.д.<br />
<br />
* Клиент обратился с вопросом и встал в очередь<br />
<br />
* Клиент вошел в чат с оператором. <br />
<br />
* Клиент закрыл чат с оператором.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Получить текущее состояние всего сервиса (как её видит аналитик) определенного оператора или клиента.<br />
<br />
* Получить статистику (ту же, которая доступна аналитикам).</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7310IM Support Service/Wanted2008-10-29T14:55:55Z<p>Feez: Добавил фич для поддержки многоязычных сервисов поддержки. Поправил статусы.</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
=== Общая структура === <br />
<br />
* Специализации поддержки. Например, магазин продажи бытовой техники может разделить поддержку по следующим специализациям: вопросы продаж, вопросы доставки, вопросы ремонта, консультанты по технике, кредит. <br/>В каждой специализации свои операторы и своя очередь клиентов, но один оператор может находиться в нескольких специализациях одновременно.<br />
<br />
* Группы в пределах одной специализации. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус сервиса (JID, UIN, ссылка на web-странице), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** n/a -- все операторы offline<br />
** offline -- сервис не работает<br />
<br />
* Чтобы была возможность выбрать один или несколько языков и указать их приоритет. Это должно учитываться не только в локализации сообщений от системы, но и при выборе оператора: рассматривать только тех, которые смогут найти общий язык с клиентом.<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что меня нет за компом и не надо перенаправлять на меня клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другую специализацию. Не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в общий чат<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в логе этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту (и себе) заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно выдать с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние специализации. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
* Учитывать языки, которыми владеет клиент, учитывая приоритеты. Сначала проверить тех операторов, которые владеют языком с наивысшим приоритетом, затем тех, которые владеют языком с меньшим приоритетом и т.д. Операторов, которые не смог общаться с клиентом, не трогать. <br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Узнать текущее состояние всей системы, как её видит аналитик, определенного оператора или клиента.<br />
<br />
* Узнать статистику, которая доступна аналитикам.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7303IM Support Service/UseCases2008-10-28T15:39:44Z<p>Feez: /* Оператор */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Джо хочет отправить клиенту pdf файл с документацией. Для этого он набирает !file. Как и все команды, эта отображается только операторам. <br />
<br />
Кроме эхо, Джо в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому URL-у и видит там простую форму: <br />
(_____имя файла______) [Выбрать] [Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл и нажимает "отправить". <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с ID.<br />
<br />
Если все прошло нормально, Джо может отправить ссылку клиенту набрав !file ID<br />
<br />
В следующий раз, когда Джо захочет отправить этот файл, он сможет пропустить первые шаги по загрузке файла, если запомнил ID файла. Для поиска есть команда !sfile.<br />
<br />
<br />
==== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Джо выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл", выбирает сам файл и нажимает отправить.<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение", то этот запрос перехватывает сервис и начинает приём файла. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с ID.<br />
<br />
Если все прошло нормально, Джо может отправить ссылку клиенту набрав !file ID<br />
<br />
В следующий раз, когда Джо захочет отправить этот файл, он сможет пропустить первые шаги по загрузке файла, если запомнил ID файла. Для поиска есть команда !sfile.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7302IM Support Service/UseCases2008-10-28T15:39:24Z<p>Feez: /* Оператор */</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
==== Отправка файла через команду !file ====<br />
<br />
Оператор Джо хочет отправить клиенту pdf файл с документацией. Для этого он набирает !file. Как и все команды, эта отображается только операторам. <br />
<br />
Кроме эхо, Джо в чат выдается внутренний служебный URL на форму добавления. Он переходит по этому URL-у и видит там простую форму: <br />
(_____имя файла______) [Выбрать] [Отправить]<br />
<br />
С помощью кнопки "выбрать" он выбирает PDF-файл и нажимает "отправить". <br />
<br />
Файл через POST-запрос сохраняется на сервере и в будущем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с ID.<br />
<br />
Если все прошло нормально, Джо может отправить ссылку клиенту набрав !file ID<br />
<br />
В следующий раз, когда Джо захочет отправить этот файл, он сможет пропустить первые шаги по загрузке файла, если запомнил ID файла. Для поиска есть команда !sfile.<br />
<br />
<br />
===== Отправка файла через передачу файлов по протоколу Jabber ====<br />
<br />
Оператор Джо выбирает клиента в списке посетителей чата и через меню выбирает "отправить файл", выбирает сам файл и нажимает отправить.<br />
<br />
Так как в чате сидит не сам клиент, а его "отображение", то этот запрос перехватывает сервис и начинает приём файла. Этот файл сохраняется на сервере и в дальнейшем будет доступен при просмотре истории чата. <br />
<br />
Публично доступный URL на этот файл высвечивается оператору вместе с ID.<br />
<br />
Если все прошло нормально, Джо может отправить ссылку клиенту набрав !file ID<br />
<br />
В следующий раз, когда Джо захочет отправить этот файл, он сможет пропустить первые шаги по загрузке файла, если запомнил ID файла. Для поиска есть команда !sfile.<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7301IM Support Service/Wanted2008-10-28T15:25:28Z<p>Feez: /* Текстовый интерфейс оператора */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
=== Общая структура === <br />
<br />
* Специализации поддержки. Например, магазин продажи бытовой техники может разделить поддержку по следующим специализациям: вопросы продаж, вопросы доставки, вопросы ремонта, консультанты по технике, кредит. <br/>В каждой специализации свои операторы и своя очередь клиентов, но один оператор может находиться в нескольких специализациях одновременно.<br />
<br />
* Группы в пределах одной специализации. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус сервиса (JID, UIN, ссылка на web-странице), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** offline -- все операторы offline<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что меня нет за компом и не надо перенаправлять на меня клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другую специализацию. Не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в общий чат<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, но здесь это "!". С такими командами оператор может не покидая чата быстро выполнить рутинные действия.<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в логе этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту (и себе) заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно выдать с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
* Чтобы можно было этот список расширить своими командами (обращение за данными в другие системы, поиск в интернете, цитатник смешных перлов клиентов и т.д.)<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние специализации. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Узнать текущее состояние всей системы, как её видит аналитик, определенного оператора или клиента.<br />
<br />
* Узнать статистику, которая доступна аналитикам.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7300IM Support Service/Wanted2008-10-28T15:22:13Z<p>Feez: /* Операторы */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
=== Общая структура === <br />
<br />
* Специализации поддержки. Например, магазин продажи бытовой техники может разделить поддержку по следующим специализациям: вопросы продаж, вопросы доставки, вопросы ремонта, консультанты по технике, кредит. <br/>В каждой специализации свои операторы и своя очередь клиентов, но один оператор может находиться в нескольких специализациях одновременно.<br />
<br />
* Группы в пределах одной специализации. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус сервиса (JID, UIN, ссылка на web-странице), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** offline -- все операторы offline<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что меня нет за компом и не надо перенаправлять на меня клиентов.<br />
<br />
* Возможность прямо из чата перенаправить клиента другому оператору, в другую группу, в другую специализацию. Не покидать чат, пока не войдет другой оператор. (чтобы клиенту не было скучно)<br />
<br />
* Пригласить другого оператора в общий чат<br />
<br />
* Если оператор входит не в новый чат, а по перенаправлению или приглашению, то должна выдаться вся история этого чата. <br />
<br />
* Если оператор входит в чат, и клиент уже говорил с ним или с другим оператором (в общем он тут не в первый раз), то эта информация должна содержаться в первом сообщении от сервиса. Желательны ссылки на логи прошлых разговоров.<br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько.<br />
<br />
===== Текстовый интерфейс оператора =====<br />
Команды оператора, которые не видит клиент, но распознает сервис поддержки. Могут начинаться с особого символа, например !<br />
<br />
* !mute. Все дальнейшие сообщения не транслируются клиенту, но остаются в истории и видны другим операторам (если есть). !mute еще раз и сообщения опять пойдут к клиенту. Нужно для внутренних разговоров между операторами, которые хорошо бы сохранить в логе этого чата. <br />
<br />
* !history. Подтянуть историю прошлых разговоров с этим клиентом<br />
<br />
* !faq <ID>. Выдать клиенту (и себе) заранее заготовленный ответ из базы часто задаваемых вопросов. С !mute сообщение будет только оператору (операторам)<br />
<br />
* !sfaq <keyword> Искать в базе вопросов, ответ выдаётся только операторам. Найденную запись потом можно выдать с помощью !faq<br />
<br />
* !file [ID]. Отправить файл клиенту. Так как прямая отправка не сохранится на сервере и в логах, то файл предварительно надо загрузить на web-сервер, а потом вставить публичную ссылку на него в чат. Примерное использование см в [[IM Support Service/UseCases|юзекейсах]].<br />
<br />
* !sfile. Поиск по прошлым или общим отправленным файлам, чтобы опять не загружать его на сервер.<br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние специализации. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Узнать текущее состояние всей системы, как её видит аналитик, определенного оператора или клиента.<br />
<br />
* Узнать статистику, которая доступна аналитикам.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7299IM Support Service/Wanted2008-10-28T15:05:27Z<p>Feez: /* Клиенты */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
=== Общая структура === <br />
<br />
* Специализации поддержки. Например, магазин продажи бытовой техники может разделить поддержку по следующим специализациям: вопросы продаж, вопросы доставки, вопросы ремонта, консультанты по технике, кредит. <br/>В каждой специализации свои операторы и своя очередь клиентов, но один оператор может находиться в нескольких специализациях одновременно.<br />
<br />
* Группы в пределах одной специализации. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Чтобы статус сервиса (JID, UIN, ссылка на web-странице), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** offline -- все операторы offline<br />
<br />
===== Клиентское ПО =====<br />
Если чуть-чуть допилить какой-нибудь джаббер клиент, сделать автоматическую регистрацию (userXXXXXXXX@clients.example.com), добавить туда пару функций, то получится замечательное ПО для обращения в техподдержку.<br />
<br />
* Упрощенный интерфейс для отправки скриншота. Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Редактор для скриншота, который откроется перед отправкой и позволит замазать разную информацию не для чужих глаз.<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что меня нет за компом и не надо перенаправлять на меня клиентов.<br />
<br />
* Перенаправить клиента другому оператору, в другую группу, в другую специализацию<br />
<br />
* Пригласить другого оператора в общий чат<br />
<br />
* При разговоре с клиентом чтобы можно было быстро посмотреть лог прошлых разговоров с этим клиентом (определяется по его JID-у, UIN-у или другому уникальному атрибуту). Это может быть полезно при определении проблемы, и съэкономит время на переспрашивание. <br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько. <br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние специализации. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Узнать текущее состояние всей системы, как её видит аналитик, определенного оператора или клиента.<br />
<br />
* Узнать статистику, которая доступна аналитикам.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7298IM Support Service/Wanted2008-10-28T15:01:01Z<p>Feez: /* Пожелания */</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
=== Общая структура === <br />
<br />
* Специализации поддержки. Например, магазин продажи бытовой техники может разделить поддержку по следующим специализациям: вопросы продаж, вопросы доставки, вопросы ремонта, консультанты по технике, кредит. <br/>В каждой специализации свои операторы и своя очередь клиентов, но один оператор может находиться в нескольких специализациях одновременно.<br />
<br />
* Группы в пределах одной специализации. Нужно для того, чтобы разделить, например, всех операторов на две группы: первая волна и вторая волна. Вторая волна задействуется только тогда, когда в первой никого нет или все заняты. <br/>Могут быть группы, которые никогда не задействуются автоматически. В них, например, можно переместить специалистов, к которым клиент может только через перенаправление другим оператором. (т.е. нужна возможность перенаправлять не только на определенного оператора, но и на группу)<br />
<br />
=== Интерфейсы, роли, возможности ===<br />
<br />
==== Клиенты ====<br />
''Те, у кого проблемы''<br />
<br />
* Возможность отправить файл оператору. Файл должен быть сохранен в истории чата, и доступен позже, при разборе полетов (если вдруг понадобиться). <br />
<br />
* Упрощенный интерфейс для отправки скриншота (тот же файл). Кнопочка, которая сразу же или по истечении N секунд сделает скриншот экрана, сохранит в читаемый, хорошо сжатый формат и отправит оператору. <br />
<br />
* Чтобы статус сервиса (JID, UIN, ссылка на web-странице), на которой клиент пишет свой вопрос и через который происходит общение, отображал текущее состояние сервиса: <br />
** online -- есть свободные операторы<br />
** away -- есть свободные операторы, но они AFK<br />
** dna -- все операторы заняты<br />
** offline -- все операторы offline<br />
<br />
==== Операторы ====<br />
''Те, кто решает проблемы''<br />
<br />
* AFK -- возможность с помощью статуса или чего-то другого указать, что меня нет за компом и не надо перенаправлять на меня клиентов.<br />
<br />
* Перенаправить клиента другому оператору, в другую группу, в другую специализацию<br />
<br />
* Пригласить другого оператора в общий чат<br />
<br />
* При разговоре с клиентом чтобы можно было быстро посмотреть лог прошлых разговоров с этим клиентом (определяется по его JID-у, UIN-у или другому уникальному атрибуту). Это может быть полезно при определении проблемы, и съэкономит время на переспрашивание. <br />
<br />
* Фильтра мата. На всякий случай. Чтобы весь мат, который оператор пишет в чат отфильтровывался и ему приходило уведомление с выделением слова, которое не прошло фильтр (чтобы, в случае ложного срабатывания, он смог его изменить)<br />
<br />
* Фильтр ссылок на корпоративные ресурсы. Оператор может по ошибке кинуть ссылку на внутренний ресурс, к которому у клиента нет доступа.<br />
<br />
* В случае внезапного оффлайна или зависания компа, должна быть возможность открыть последний активный чат, или чаты, если их было несколько. <br />
<br />
==== Администраторы ====<br />
''Те, кто администрируют ресурс, добавляют удаляют операторов, разделяют по группам и т.п.''<br />
<br />
* Посмотреть архив любого разговора, в том числе все файлы, которые были пересланы между оператором и клиентом.<br />
<br />
==== Аналитики ====<br />
''Хотят все знать.''<br />
<br />
* Общая статистика. Параметры: количество клиентов, продолжительность разговора, сколько не дождалось оператора, среднее время ожидания в очереди.<br />
<br />
* Статистика по оператору. Параметры: количество клиентов, средняя продолжительность разговора, сколько времени провел в AFK, сколько времени провел в онлайне. <br />
<br />
* Статистика по клиенту. Параметры: сколько раз обращался, сколько времени провел в очереди/в разговоре. <br />
<br />
* Текущее состояние специализации. Количество операторов всего/онлайн/afk/свободны/в разговоре. Количество клиентов в очереди/в разговоре.<br />
<br />
=== Алгоритмы ===<br />
<br />
==== Поиск свободного оператора ====<br />
Когда клиент оформил вопрос, нужно найти оператора, который сможет ему помочь. Самый простой вариант: первый свободный, если не ответил, то следующий свободный и т.д. Но тут можно расширить:<br />
<br />
* Чтобы можно было в алгоритм определения свободности оператора вставить свои проверки. Например, чтобы учитывать занятость оператора в других алогичных системах (голосовая поддержка). <br />
<br />
* Поиск с учетом внутренних групп. В каких группах искать в первую очередь, в каких во вторую и т.п. Условия перехода к следующей группе: все заняты, никто не открыл чат в течении N минут, все отказались по N раз и т.п.<br />
<br />
* Если клиент уже обращался, то лучше попытаться связать его с тем оператором, с которым он говорил впоследний раз.<br />
<br />
=== Программные интерфейсы ===<br />
Все пункты здесь нужны для интеграции с другими системами, будь то внутренний ERP, CRM, helpdesk или еще что.<br />
<br />
==== Хуки ====<br />
''Это возможность повесить свои обработчики на наступление определенных событий.''<br />
<br />
* Оператор открыл/закрыл чат с клиентом. <br />
<br />
* Оператор перенаправил клиента другому оператору. <br />
<br />
* Оператор вышел в онлай, ушел в оффлай/afk.<br />
<br />
==== Запросы информации ====<br />
Другие системы тоже имеют право знать, в каком состоянии сейчас находиться техподдержка. <br />
<br />
* Вытянуть историю чата по времени, ID чата, по оператору и клиенту.<br />
<br />
* Узнать текущее состояние всей системы, как её видит аналитик, определенного оператора или клиента.<br />
<br />
* Узнать статистику, которая доступна аналитикам.</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7297IM Support Service2008-10-28T08:38:03Z<p>Feez: /* Этапы разработки */ перенес ТЗ в след этап. Сначала надо хотя бы фичи собрать</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* [[IM Support Service/Specification|Техническое задание]]<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
* http://cybersocialism.livejournal.com/39008.html<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7296IM Support Service2008-10-28T08:35:40Z<p>Feez: /* Запросы на похожую функциональность в Jabber */ + еще одна ссылка</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/Specification|Техническое задание]], [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
* http://cybersocialism.livejournal.com/39008.html<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/Wanted&diff=7282IM Support Service/Wanted2008-10-20T12:18:34Z<p>Feez: New page: Список пожеланий для IM Support Service. Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои...</p>
<hr />
<div>Список пожеланий для [[IM Support Service]]. <br />
<br />
Если вам лень оформлять в ТЗ или пока не готовы, может оформить свои пожелания здесь. Но попытайтесь указать как можно больше деталей: <br />
<br />
Плохой вариант: <br />
* Чтобы можно было грабить корованы<br />
<br />
Хороший вариант:<br />
* Чтобы в интерфейсе пользователя во время ожидания свободного оператора была кнопка "Грабить корованы", а в результате чтоб была табличка с награбленными ценностями и картинками. Так пользователь весело проведет время в ожидании и полчаса пролетят незаметно :)<br />
<br />
Не факт, что все ваши запросы будут реализованы, но место под доделку или плагин точно забронируем :)<br />
<br />
== Пожелания ==<br />
<br />
* ''Пишите здесь''</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service/UseCases&diff=7281IM Support Service/UseCases2008-10-20T12:01:19Z<p>Feez: New page: Шаблоны использования для IM Support Service === Пользователь (клиент) === === Оператор === === Администратор === === ...</p>
<hr />
<div>Шаблоны использования для [[IM Support Service]]<br />
<br />
=== Пользователь (клиент) ===<br />
<br />
=== Оператор ===<br />
<br />
=== Администратор ===<br />
<br />
=== Аналитик ===</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7280IM Support Service2008-10-20T12:00:07Z<p>Feez: /* Этапы разработки */</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/Specification|Техническое задание]], [[IM Support Service/UseCases|юзекейсы]], [[IM Support Service/Wanted|сбор фич]]. '''&larr; текущий этап'''<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7279IM Support Service2008-10-20T11:57:26Z<p>Feez: /* Запросы на похожую функциональность в Jabber */</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/Specification|Техническое задание]], сбор фич. '''&larr; текущий этап'''<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=IM_Support_Service&diff=7278IM Support Service2008-10-20T11:56:04Z<p>Feez: /* Запросы на похожую функциональность в Jabber */</p>
<hr />
<div>Цель проекта — создание аналога кол-центра (один контактный телефон — много операторов) для [[IM|IM-сетей]]. Предложение идеи, её большое обсуждение и первые наброски технического задания (ТЗ) и общей схемы можно найти [http://forum.jrudevels.org/viewtopic.php?t=1084 на форуме JRuDevels].<br />
<br />
Скорее всего, это будет сделано в виде [[XMPP]]-[[Component|компонента]], и взаимодействие с клиентами из других сетей будет производиться через [[gateway|транспорты]].<br />
<br />
<br />
== Этапы разработки ==<br />
* [[IM Support Service/Specification|Техническое задание]], сбор фич. '''&larr; текущий этап'''<br />
* Выбор минимума из ТЗ, который должен будет реализован в этом проекте.<br />
* Выбор фреймворка, языка программирования, лицензии и т.п.<br />
* Планирование общей схемы программы.<br />
* ... (пока туманное будущее с неясными очертаниями)<br />
<br />
== Участники ==<br />
<i>Всем, кто готов помочь — добро пожаловать!</i><br />
* [[User:feez|feez]]: Проектирование, программирование. Постараюсь поддерживать информацию на wiki в актуальном состоянии.<br />
* [[User:Binary|Binary]]: Программирование, обсуждения.<br />
* [[user:leksey|leksey]] спецификация и кейзы<br />
<br />
== Ссылки ==<br />
=== Аналогичные проекты в XMPP или других IM-сетях ===<br />
Платные и свободные проекты многоканального IM-пейджера: <br />
* http://www.im-gate.com/<br />
<br />
=== Запросы на похожую функциональность в Jabber ===<br />
Ссылки на посты в форумах и блогах, где люди явно спрашивали похожую функциональность или этот проект хорошо бы подошел для решения их проблемы:<br />
* http://www.linux.org.ru/view-message.jsp?msgid=3173701<br />
<br />
=== Обсуждение этого проекта в Сети ===<br />
Ссылки на обсуждения для составления списка спрашиваемых фич:<br />
* Форум JRuDevels.org: «[http://forum.jrudevels.org/viewtopic.php?t=1084 (идея) Подобие многоканального телефона для ICQ-транспорта]»</div>Feezhttp://wiki.jrudevels.org/index.php?title=User:Feez&diff=6276User:Feez2008-08-19T10:46:05Z<p>Feez: </p>
<hr />
<div>Артем. <br />
<br />
{{SendMessage|to=feez}}<br />
<br />
== Ссылки ==<br />
{| class="standart" width=100%<br />
! width=20%| Внутренние <br />
! width=20%| ToWrite <br />
! width=20%| Вопросы оформления<br />
! width=20%| Остальное<br />
|-<br />
|<br />
* [[Special:Whatlinkshere/ToDo|ToDo]]<br />
* [[Special:Whatlinkshere/FixMe|FixMe]]<br />
* [[Special:Categories|Категории]]<br />
|<br />
* [[Neutron]]<br />
* [[FtpSpider]]<br />
* [[Tkabber]]<br />
|<br />
* [http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D0%B0%D0%BA_%D0%B4%D0%B5%D0%BB%D0%B0%D1%82%D1%8C_%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B создание таблиц]<br />
* [http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9E%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86 оформление таблиц на wikipedia.org]<br />
* [http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D0%B8 категории на wikipedia.org]<br />
* [http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9C%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC_%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2 Механизм шаблонов]<br />
* [http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8_%D0%BF%D0%B0%D1%80%D1%81%D0%B5%D1%80%D0%B0 Функции парсера]<br />
|<br />
* [http://www.saint-andre.com/blog/2005-03.html#2005-03-09T11:47 поднимайте свои серверы.]<br />
|}<br />
<br />
== Разная инфа ==<br />
* Big companies like AT&T, EDS, FedEx, HP, Oracle, and Sun depend on their Jabber-based IM systems for daily communication [http://www.jabber.org/journal/2005-06-24.shtml]<br />
* And a number of large ISPs and telecommunications providers (such as France Telecom, BellSouth, and Orange) have used XMPP as the basis for mobile IM as well as innovative services such as push-to-talk. [http://www.jabber.org/journal/2005-06-24.shtml]<br />
{|<br />
|[[image:AdoptionCurve.png|thumb|Техника переманивания пользователей с вражеских сетей]]<br />
|}</div>Feezhttp://wiki.jrudevels.org/index.php?title=JabberBot&diff=6273JabberBot2008-08-17T19:57:18Z<p>Feez: </p>
<hr />
<div>{{Library<br />
| name=JabberBot<br />
| url=http://thpinfo.com/2007/python-jabberbot/<br />
| author=Thomas Perl<br />
| language=Python<br />
| license=GNU GPLv3<br />
| roster=да<br />
}}<br />
<br />
==Описание==<br />
'''JabberBot''' -- маленькая библиотека на [[Python]], оболочка для [[xmpppy]], которая позволяет быстро и легко создавать маленьких ботов, выполняющих одну задачу, но делающих это хорошо. Томасу Перлу (Thomas Perl), автору этого проекта, идея пришла после изучения примера для библиотеки xmpppy. Он решил доделать код и оформить его в виде класса, упростив таким образом создание простых ботов.<br />
<br />
<br />
== Использование ==<br />
Краткая инструкция:<br />
# Импортируйте библиотеку: from jabberbot import JabberBot<br />
# Наследуйте класс JabberBot в своем классе<br />
# Добавьте методы начинающиеся с bot_, это будущие команды бота. (например, метод def bot_displayid( self, mess, args)); вызывается командой displayid и должен вернуть или строку, которая потом будет отправлена пользователю или None)<br />
# Создайте экземпляр своего класса, передав JID и пароль в качестве параметров<br />
# Вызовите метод serve_forever()<br />
# С помощью метода send() вы можете отправлять сообщения отдельным пользователям.<br />
<br />
==Пример==<br />
<br />
from jabberbot import JabberBot<br />
import datetime<br />
<br />
class SystemInfoJabberBot(JabberBot):<br />
def bot_serverinfo( self, mess, args):<br />
"""Displays information about the server"""<br />
version = open('/proc/version').read().strip()<br />
loadavg = open('/proc/loadavg').read().strip()<br />
<br />
return '%s\n\n%s' % ( version, loadavg, )<br />
<br />
def bot_time( self, mess, args):<br />
"""Displays current server time"""<br />
return str(datetime.datetime.now())<br />
<br />
def bot_rot13( self, mess, args):<br />
"""Returns passed arguments rot13'ed"""<br />
return args.encode('rot13')<br />
<br />
def bot_whoami( self, mess, args):<br />
"""Tells you your username"""<br />
return mess.getFrom()<br />
<br />
username = 'my-jabberid@jabberserver.example.org'<br />
password = 'my-password'<br />
bot = SystemInfoJabberBot(username,password)<br />
bot.serve_forever()<br />
<br />
Пример работы:<br />
<br />
http://thpinfo.com/2007/python-jabberbot/jabberbot-screenshot.png<br />
<br />
==Зависимости ==<br />
* [[xmpppy]]<br />
<br />
==Ссылки==<br />
* [http://thpinfo.com/2007/python-jabberbot/ Сайт]<br />
[[Category:Library]]<br />
[[Category:Python]]<br />
[[Category:Python_Library]]</div>Feez