Разработка модели системы мониторинга пользовательских запросов в крупной социальной сети Рунета — ООО "В Контакте"

В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:

* трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

* мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;

* зарегистрированные инциденты помогают при диагностике новых инцидентов;

* Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;

* легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;

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

Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены следующим образом:

*Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.

*Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.

*Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента.

*Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.

Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов:

*Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.

*Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.

В обоих случаях продолжение процесса одинаково, хотя в первом случае последующие действия гораздо проще.

При регистрации инцидента производятся следующие действия:

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

*Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.

*Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.

Классификация

Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. В данном разделе рассматриваются вопросы, относящиеся к классификации.

Приоритет

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

Группа поддержки

Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности(KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.

Сроки решения

С учетом приоритета пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

* новый;

* принят;

* запланирован;

* назначен;

* активный;

* отложен;

* разрешен;

* закрыт.

Привязка (сопоставление)

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

Расследование и диагностика

Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.

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

Решение и восстановление

После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.

Закрытие

После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне.

Мониторинг хода решения и отслеживание

В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

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

* общее количество инцидентов;

* среднее время разрешения инцидентов;

* среднее время разрешения инцидентов по приоритетам;

* процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

* средняя стоимость поддержки на инцидент;

* число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

* инциденты, решенные без посещения пользователя (удаленно);

* число (или процент) инцидентов с первоначально некорректной классификацией;

* число (или процент) инцидентов, неправильно распределенных в группы поддержки.

Функции и роли

Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.

Персонал групп поддержки

* Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.

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



Выводы к ГЛАВЕ 2

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

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

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

Служба технической поддержки устроена примерно по следующему принципу:

Пользователь обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки (электронная почта, или специальные сервисы подачи заявок).

Оператор (1-я линия поддержки) -- регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки.

Вторая линия поддержки -- получает заявки от первой линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из смежных отделов (например, системные администраторы, поддержка POS-терминалов, поддержка специального ПО, поддержка специального оборудования, администраторы биллинговой системы и т. д.)



ГЛАВА 3. Разработка модели мониторинга запросов потребителей для ВКонтакте

3.1 Анализ проблемной области

Главная задача грамотной технической поддержки заключается в эффективном решении задачи пользователя в самые короткие сроки.

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

В технической поддержке ВКонтакте реализовано некое отступление от правил устройства технических поддержек -- фильтрации и ранжирования ответов по значимости нет, поэтому все ответы поступают к агентам Поддержки в порядке живой очереди, что в условиях «завала» запросов может вызвать негативную реакцию у пользователей.

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

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

В Приложении 1 изображена диаграмма Исикавы для выявления факторов, влияющих на быстродействие ответов.

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

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

Помимо этого, увеличить качество ответов помогает дополнительная проверка ответов на вероятность несовпадения или ошибок. Это помогает проанализировать подготовку того или иного агента и избежать многих ошибок в будущем.

Многое также зависит и от работы разделов сайта и реагирования разработчиков на ту или иную проблему. Бывают случаи, когда разработчики не могут добраться до какой-то проблемы в течение нескольких месяцев. Все это негативно отражается на мнении пользователя о работе поддержки.

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

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

Примечательно, что большое количество ошибок и проблем на сайте выявляется именно с помощью пользователей сайта, что несомненно помогает разработчикам своевременно их устранять. Зачастую сами разработчики не могут увидеть проблемные области, но нынешняя репутация поддержки ВКонтакте очень помогает в нахождении этих проблемных областей -- поддержка поставила себя таким образом, чтобы пользователь доверял ей и обращался к ней в случае какого-либо важного вопроса.

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

Итак, от скорости решения вопроса зависит, насколько пользователь останется оказанной ему помощью.

Рисунок 18 -- начальная страничка интерфейса поддержки

социальный сеть запрос поддержка

Рассмотрим, как это происходит.

Пользователь обращается в поддержку при возникновении проблемы, как показано на рисунке 18.

Далее он создает свой вопрос (рис. 19). В этом вопросе он может общаться с агентом поддержки, которому вопрос попал рандомно.

Пользователь описывает свою проблему. Зачастую он делает это сумбурно и без особой связи.

Рисунок 19 -- Пример вопроса в поддержку ВКонтакте

«У меня не работают аудиозаписи», «Что с моей лентой новостей?», «Почему я не могу ничего написать?» -- примерно 20% процентов, заданных пользователями в поддержку, выглядят примерно так.

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

Поэтому агент начинает задавать уточняющие вопросы и просить скриншоты проблемы.

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

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

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

3.2 Описание элементов модели

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

Часто они сталкиваются с ошибками на сайте, из-за чего пишут в поддержку, чтобы разобраться. Но для этого нужно зайти в раздел «помощь» в верхней части сайта и создать свой вопрос.

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

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

Поэтому появилась идея создать возможность написания обращения в поддержку с любой страницы сайта с помощью окна диалога, как на Рисунке 20.

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

Рисунок 20-- пример диалогового окна для обращения в поддержку

Рисунок 21 -- Примерный вид обращения в поддержку с помощью диалогового окна

Это можно реализовать с помощью такого элемента, как небольшой значок в углу страницы, как на Рисунке 21.

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

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

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

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

Если у кого-то перестали работать аудиозаписи, сломалась стена -- не отображаются записи, не открывается сайт, такая система поддержки позволит агентам быстрее добраться до проблемной области и проверить, не является ли это массовой проблемой.

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

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

Идея с развитием поддержки в качестве чата может принести. Тем не менее, некоторые сложности, связанные с организацией отдела поддержки. Подобный формат, конечно же, может вызвать ажиотаж среди пользователей, поскольку сейчас доступность поддержки не очевидна так сильно. Поддержка давно позиционирует себя как «Межгалактическая Поддержка, способная ответить на любые вопросы пользователей». Такой формат поддержки непременно приведет к тому, что количество запросов в нее может увеличиться в несколько раз, к чему нынешнее состояние раздела совершенно не готово.

Преимущества такого формата поддержки:

Быстрота взаимодействия с пользователями;

Наглядность возникающей проблемы;

Поддержка становится более доступной;

Повышение лояльности пользователей и их желания вести диалог с отделом поддержки;

Увеличение качества технической поддержки сайта.

Недостатки такой системы:

Резкое увеличение запросов пользователей;

Необходимость увеличения штата агентов поддержки;

Поддержка может быть забита вопросами, не связанными с технической стороной сайта.

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

3.2 Классификация инновационного проекта

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

Этот проект связан с модернизацией и обновлением технического аппарата отдельно взятого предприятия -- сайта ВКонтакте (vk.com). Он является конечным и краткосрочным проектом, поскольку его вполне можно уложить в рамки двухгодичного срока.

Проект призван удовлетворить уже существующие потребности пользователей сайта и является монопроектом -- вводится он только на уровне одной компании и может быть реализован непосредственно ею.

При этом, это всего лишь обновление и так инновационного подхода к поддержке социальной сети, введенной во ВКонтакте почти три года назад -- направленной поддержки исключительно на пользователя.

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

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

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

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

Выводы к ГЛАВЕ 3

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

Модель состоит из следующих элементов:

Отдельной иконки на каждой странице сайта;

Диалогового окна при нажатии на иконку в углу;

Отдельного технического инструмента, позволяющего сделать скриншот проблемной области и тут же сохранить его в сообщение в поддержку;

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

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



Заключение

Большинство компаний в том или ином виде работает с клиентами и занимается их поддержкой. Для обеспечения качественного взаимодействия с клиентами существуют системы автоматизации класса HelpDesk (Service Desk). Без данной системы крайне трудно построить качественную службу поддержки.

Главными задачами HelpDesk систем является возможность приёма и обработки заявок, другими словами клиент задаёт вопрос (заявку, запрос, тикет) и менеджеры обрабатывают его. Благодаря использованию HelpDesk системы возможна совместная работа всех менеджеров компании.

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

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

Описала общую схему построения технической поддержки и отдельно рассмотрела техническую поддержку ВКонтакте.

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



Список использованной источников

[1] Леонтьев, В. П.Социальные сети: В контакте, Facebook и другие. Москва: ОЛМА Медиа Групп, 2012. -- С 6-7.

[2] По данным исследовательской компании SimilarWeb(http://www.similarweb.com/global)

[3] http://www.liveinternet.ru/stat/vkontakte.ru/ -- сайт статистики социальных сетей LiveInternet.

[4] https://xakep.ru -- онлайн-журнал Хакер замарт, 2011, на основе данных с московской конференции HighLoad++ в Москве в 2011 году.

[5] http://www.rusprofile.ru/id/2647641 -- справочная система по всем российским компаниям и предпринимателям «РусПрофайл»

[6] https://vk.com/vkcup -- официальное сообщество чемпионата

[7] https://vk.com/startfellows -- официальное сообщество программы

[8] http://bycongroup.com -- по исследованиям российской коммуникационной группы «Византия» (http://bycongroup.com/)

[9] Исследования TNSWebIndex за ноябрь-май 2014-2015. Материалы представлены в виде презентации на сайте http://tns-global.ru.

[10] Алехин 3. Service Desk цели, возможности, реализации // Открытые системы, №5-6, 2001, стр. 43-48.

[11] Сергей Лямуков Управление знаниями в Service Desk. Журнал «Открытые системы», № 01 (157), 2010, 37 с.

Приложение 1

Диаграмма проблемной области технической поддержки

Размещено на Allbest.ru