В ходе развития своих проектов большинство IT компаний рано или поздно сталкивается с проблемой его поддержки и сопровождения. Высокая конкуренция на рынке информационных технологий требует качественного оказания данной услуги, так как доступность и работоспособность интернет-магазина, актуальность его содержания — залог того, что посетитель не выберет конкурента, а будет сотрудничать именно с вами. В данной статье рассмотрим методику поддержки внутри проекта abcp, а также возникшие трудности и пути их решения.
Основная специфика сопровождения клиентов abcp заключается в том, что от качества поддержки зависят их продажи, а соответственно и прибыль. Чаще всего, те кто использует интернет-магазин на нашей платформе, ранее торговали в ларьках, магазинах, на авторынках. Есть и те, кто уже имели ресурс в интернете, однако поддерживать его самостоятельно не удалось. Определенный сегмент занимают крупные компании, которые готовы на аутсорсинг целого сайта. Время и постоянный технический прогресс также диктуют свои правила: кто не имел интернет-магазина, вынуждены его иметь (так как у конкурентов они появляются), кроме этого, это инструмент для уменьшения издержек, так как самостоятельная поддержка занимает много времени и отнимает много денег. В большинстве случаев возникшие вопросы и проблемы формируются клиентом “не отходя от кассы” и должны решаться быстро и эффективно. Основные темы обращений в техподдержку: некорректная цена на сайте, проблемы с оформлением заказа, проблемы с обновлением прайс-листа поставщика, проблемы с наполнением сайта контентом, загрузка и проверка информации о запчастях в товарных группах (масла, шины, диски) и т.д.
На текущий момент система насчитывает более восьмисот клиентов платформы, и положительная динамика прослеживается ежемесячно (см.график ниже). В условиях постоянного роста пользователей платформы поддержка должна быть быстрой и качественной, поэтому важно оптимизировать методы ее оказания.
Все начиналось очень просто. До формирования полноценного отдела поддержки каждый сотрудник помогал пользователям платформы в телефонном режиме или по почте. В то время в компании работало всего несколько человек, поэтому всем приходилось заниматься всей поступающей работой. Рост количества клиентов привел к тому, что стало невозможно совмещать разработку и поддержку. Момент, когда необходимо было определиться с выбором системы регистрации запросов, настал. Основными критериями выбора конечно же стали стоимость, а точнее ее отсутствие, и возможность свободно модифицировать код. В разработке уже использовался Mantis в качестве баг-трекера, поэтому было решено быстро (а значит дёшево) адаптировать его и к обработке задач от клиентов. Мы встроили форму отправки запроса в панель управления сайтом, то есть дали возможность кратко изложить суть запроса, вести переписку с сотрудником, увидеть статус тикета и так далее.
Возвращаясь к выбранному баг-трекеру, стоит отметить, что базовая версия Mantis была дополнена множеством фишек, которые активно применяются и по сей день. Большинство из них (дополнительные кнопки, ссылки для перехода к информации о клиентах и т.д.) позволили оптимизировать переходы между интерфейсами, тем самым ускорить обработку запросов. Самой полезной доработкой стало встраивание формы отправки тикета в административную панель управления сайтом.
У клиентов появился раздел “Техподержка”, в котором стали доступны возможности создания нового запроса/тикета в support, ведение переписки в существующих запросах, отслеживание активных тикетов. Пример формы отправки запроса приведен ниже.
Форма нового запроса максимально проста. В качестве рекомендации дополнительно указаны основные правила заполнения. Также пользователь платформы должен кратко изложить запрос, чтобы сотрудники поддержки могли воспроизвести ошибку/ситуацию и дать быстрый ответ. При необходимости есть возможность прикрепить файл. Форма оказалась простой, понятной, и пользователи стали массово ее использовать. После оформления тикет отображается в интерфейсе у сотрудников поддержки, и они обрабатывают запрос. При обработке происходит диалог/переписка с клиентом. Каждый комментарий специально дублируется на почту пользователя платформы и на группу отдела поддержки.
С помощью Mantis клиент может отслеживать статусы тикетов, изменять приоритет обработки, видеть исполнителя, фактическое время выполнения. Если решение той или иной задачи ему понравилось, есть возможность поставить отметку “Like”. Все эти дополнения позволяют отслеживать количество поступивших, решенных запросов. Внутри отдела на основе этих данных собирается сводная информация по сотрудникам, что дает понимание об эффективности работы и объемах, выполненных каждым сотрудником. Такие сводки помогают руководителю принимать решения о назначении материальных бонусов.
Ниже на рисунке представлен рабочий интерфейс сотрудника поддержки.
Каждый элемент представленного интерфейса позволяет без лишних перемещений и кликов увидеть повышение приоритета тикета, публичный комментарий клиента или скрытый комментарий сотрудника, список сотрудников, отслеживающих тикет и так далее.
При работе с людьми большую роль играет человеческий фактор. Одни клиенты приветливые и понимающие, другие недружелюбные и всегда недовольные. От этого поддержке никуда не деться. Чем больше становилось пользователей, тем больше было попыток дать какую-то субъективную оценку по работе всего сервиса поддержки. Нас начали упрекать в том, что поддержка “плохо работает”, “мало обрабатывает запросов” и т.д… Для того, чтобы снизить градус недовольства и показать качество работы мы начали отображать в интерфейсе клиентов статистику по задачам: процент и количество выполненных и невыполненных (нерешенных) запросов за последний год. То есть мы наглядно показываем каждому из пользователей, какой процент и количество было обработано, а какое нет. Обработанных тикетов, конечно, намного больше. Это немного остужает пыл тех, кто жалуется на то, что ему не уделили достаточно внимания, не выполнили запрос и так далее. Все запросы хранятся, никуда не архивируются, не удаляются. Каждый может увидеть всю историю общения с поддержкой и просмотреть ранние обращения. Настроены оповещения по критичным для пользователя платформы событиям: приближение к порогу лимита услуги, сообщение о необходимости пополнить баланс во избежании попадания в стоп-лист, отчет об отсутствии результатов поиска по онлайн поставщику, новости о нововведениях платформы, отчеты о результатах обновления склада и так далее.
Для повышения качества поддержки сотрудники в баг-трекере видят каунтеры, подсчитывающие тикеты, в которых ожидается ответ поддержки. На почту поступают письма, оповещающие о том, кому из клиентов необходимо ответить. Мы постарались сделать интерфейс и в целом сервис поддержки максимально простым и быстрым.
Функционал платформы постоянно расширялся, добавлялись новые модули, настройки. Каждый сотрудник локально по конкретному запросу выяснял у разработчика тонкости реализации, отвечал клиенту, закрывал запрос. При поступлении через некоторое время подобного запроса другому сотруднику схема повторялась, так как никто уже не помнил, что ранее был обработан идентичный запрос. Поддержка столкнулась с проблемой коммуникации внутри отдела. Мы постоянно тратили время на совещания между собой, на консультации с разработчиками, которые всегда ругались, что их отвлекают.
Пришлось немного перестроить схему распределения запросов и коммуникации с другими отделами. Ее же используем и сейчас. Упрощенная схема взаимодействия представлена ниже (без детализации работы других отделов).
Запрос от клиента может поступать в форме звонка или запроса через Mantis. Во время звонка мы всегда уточняем, есть ли активный тикет. Если его нет — просим создать, чтобы перенести все коммуникации в него.Так происходит в 85% случаев. (Остальные 10 — звонки для перевода на других сотрудников, 5% — простые и быстрые консультации по телефону не более 2-3 минут). По сути любое обращение трансформируется в тикет. Они могут быть типичные и нестандартные. Типичные напрямую назначают себе сотрудники поддержки. Нестандартные забирает руководитель поддержки для выяснения деталей, ТЗ и т.д. При этом каждый комментарий по каждому запросу доступен к прочтению в почте всем сотрудникам. Таким образом, все в курсе того, какие запросы и как решает коллега. Такая схема позволяет руководителю всегда быть в курсе всех тикетов, сотрудникам — знать, что происходит в запросах у коллег. Это помогает избежать дублей, пересечений вопросов в запросах, контекстно повышать уровень знаний.
Конечно, есть такие запросы/ошибки, которые требуют вмешательства разработчиков для исправления/разработки. В этом случае сотрудник поддержки разбирает проблему, воспроизводит ее и пишет в дополнительной (скрытой от клиента) информации алгоритм получения ошибки для отдела разработки. Далее задача возвращается руководителю поддержки. Он еще раз проверяет ситуацию и, в случае ошибки платформы, передает задачу в отдел разработки. Далее назначается ответственный за решение и происходит обработка запроса. Важным моментом является то, что все вопросы с разработчиками решаются через руководителя поддержки, то есть разработчик отвлекается минимальное количество раз. Время, затраченное на консультации, списывается с клиентов, в случае если не было ошибки с нашей стороны.
В процессе работы пришло понимание, что соотношение количества клиентов к затрачиваемым на них ресурсам поддержки несоизмеримо. Это стало проблемой. Количество часов, затрачиваемых на поддержку через баг-трекер, не учитывалось. Обучение функционалу мы проводили персонально для КАЖДОГО вновь прибывшего пользователя платформы, используя телефонную связь и TeamViewer. Такое обучение в среднем занимало около двух часов на одного нового клиента. Более того, такой индивидуальный подход приводил к тому, что клиенты самостоятельно ничего не хотели настраивать, по самым простым вопросам звонили и создавали тикеты. Возникла острая необходимость в изменении процесса оказания поддержки.
Были внедрены следующие изменения:
Результат не заставил себя долго ждать. Мы получили огромную экономию ресурсов отдела. На самом первом графике в статье видно примерное количество поступающих в год тикетов. После реализованной автоматизации, перехода на вебинары и других мер, запросов поступило уже значительно меньше. Данная тенденция связана именно в оптимизацией многих процессов.
Каждое из перечисленных выше изменений в работе принесло свои плоды. Ограничение количества включенных в тарифные планы часов поддержки сильно повлияло на поток отправляемых тикетов. Клиенты стали больше обращаться к документации, видеоурокам, посещать вебинары. Никому не хотелось “упереться в лимит”, превысить его и дополнительно оплатить работы по оказанию техподдержки.
Хотелось бы подробнее рассмотреть выбор системы интерактивного обучения, так как после ее внедрения высвободилось больше всего ресурсов. Мы выбирали из многих предложений на рынке вебинаров, и выбор пал на продукт “Gotowebinar” от компании Citrix.
Основные критерии подбора:
В сводной таблице указаны программные продукты, которые были рассмотрены при поиске оптимального.
Найти подходящий продукт было очень сложно. В каждом из рассмотренных продуктов были какие-то подводные камни: ограниченное количество часов записи, неадекватная ценовая политика при необходимых нам критериях, ужасное качество отрисовки изображения.
Конечно, указанные в таблице критерии при выборе подобной системы могут быть другими, но наш выбор себя оправдал. Нет проблем с подключением у клиентов, видео записывается качественно, сохраняется локально. Записывается голос ведущего, а также участников вебинара.
Впереди еще много улучшений, но на текущий момент можно смело заявить, что все описанные выше шаги привели к становлению наиболее стабильной и оптимальной схемы взаимодействия с клиентами, позволили улучшить качество оказываемой поддержки, равномерно распределить ресурсы отдела.
P.S. Немного статистики на текущий момент:
Основная специфика сопровождения клиентов abcp заключается в том, что от качества поддержки зависят их продажи, а соответственно и прибыль. Чаще всего, те кто использует интернет-магазин на нашей платформе, ранее торговали в ларьках, магазинах, на авторынках. Есть и те, кто уже имели ресурс в интернете, однако поддерживать его самостоятельно не удалось. Определенный сегмент занимают крупные компании, которые готовы на аутсорсинг целого сайта. Время и постоянный технический прогресс также диктуют свои правила: кто не имел интернет-магазина, вынуждены его иметь (так как у конкурентов они появляются), кроме этого, это инструмент для уменьшения издержек, так как самостоятельная поддержка занимает много времени и отнимает много денег. В большинстве случаев возникшие вопросы и проблемы формируются клиентом “не отходя от кассы” и должны решаться быстро и эффективно. Основные темы обращений в техподдержку: некорректная цена на сайте, проблемы с оформлением заказа, проблемы с обновлением прайс-листа поставщика, проблемы с наполнением сайта контентом, загрузка и проверка информации о запчастях в товарных группах (масла, шины, диски) и т.д.
На текущий момент система насчитывает более восьмисот клиентов платформы, и положительная динамика прослеживается ежемесячно (см.график ниже). В условиях постоянного роста пользователей платформы поддержка должна быть быстрой и качественной, поэтому важно оптимизировать методы ее оказания.
Формирование методологии технического сопровождения
Все начиналось очень просто. До формирования полноценного отдела поддержки каждый сотрудник помогал пользователям платформы в телефонном режиме или по почте. В то время в компании работало всего несколько человек, поэтому всем приходилось заниматься всей поступающей работой. Рост количества клиентов привел к тому, что стало невозможно совмещать разработку и поддержку. Момент, когда необходимо было определиться с выбором системы регистрации запросов, настал. Основными критериями выбора конечно же стали стоимость, а точнее ее отсутствие, и возможность свободно модифицировать код. В разработке уже использовался Mantis в качестве баг-трекера, поэтому было решено быстро (а значит дёшево) адаптировать его и к обработке задач от клиентов. Мы встроили форму отправки запроса в панель управления сайтом, то есть дали возможность кратко изложить суть запроса, вести переписку с сотрудником, увидеть статус тикета и так далее.
Возвращаясь к выбранному баг-трекеру, стоит отметить, что базовая версия Mantis была дополнена множеством фишек, которые активно применяются и по сей день. Большинство из них (дополнительные кнопки, ссылки для перехода к информации о клиентах и т.д.) позволили оптимизировать переходы между интерфейсами, тем самым ускорить обработку запросов. Самой полезной доработкой стало встраивание формы отправки тикета в административную панель управления сайтом.
У клиентов появился раздел “Техподержка”, в котором стали доступны возможности создания нового запроса/тикета в support, ведение переписки в существующих запросах, отслеживание активных тикетов. Пример формы отправки запроса приведен ниже.
Форма нового запроса максимально проста. В качестве рекомендации дополнительно указаны основные правила заполнения. Также пользователь платформы должен кратко изложить запрос, чтобы сотрудники поддержки могли воспроизвести ошибку/ситуацию и дать быстрый ответ. При необходимости есть возможность прикрепить файл. Форма оказалась простой, понятной, и пользователи стали массово ее использовать. После оформления тикет отображается в интерфейсе у сотрудников поддержки, и они обрабатывают запрос. При обработке происходит диалог/переписка с клиентом. Каждый комментарий специально дублируется на почту пользователя платформы и на группу отдела поддержки.
С помощью Mantis клиент может отслеживать статусы тикетов, изменять приоритет обработки, видеть исполнителя, фактическое время выполнения. Если решение той или иной задачи ему понравилось, есть возможность поставить отметку “Like”. Все эти дополнения позволяют отслеживать количество поступивших, решенных запросов. Внутри отдела на основе этих данных собирается сводная информация по сотрудникам, что дает понимание об эффективности работы и объемах, выполненных каждым сотрудником. Такие сводки помогают руководителю принимать решения о назначении материальных бонусов.
Ниже на рисунке представлен рабочий интерфейс сотрудника поддержки.
Каждый элемент представленного интерфейса позволяет без лишних перемещений и кликов увидеть повышение приоритета тикета, публичный комментарий клиента или скрытый комментарий сотрудника, список сотрудников, отслеживающих тикет и так далее.
При работе с людьми большую роль играет человеческий фактор. Одни клиенты приветливые и понимающие, другие недружелюбные и всегда недовольные. От этого поддержке никуда не деться. Чем больше становилось пользователей, тем больше было попыток дать какую-то субъективную оценку по работе всего сервиса поддержки. Нас начали упрекать в том, что поддержка “плохо работает”, “мало обрабатывает запросов” и т.д… Для того, чтобы снизить градус недовольства и показать качество работы мы начали отображать в интерфейсе клиентов статистику по задачам: процент и количество выполненных и невыполненных (нерешенных) запросов за последний год. То есть мы наглядно показываем каждому из пользователей, какой процент и количество было обработано, а какое нет. Обработанных тикетов, конечно, намного больше. Это немного остужает пыл тех, кто жалуется на то, что ему не уделили достаточно внимания, не выполнили запрос и так далее. Все запросы хранятся, никуда не архивируются, не удаляются. Каждый может увидеть всю историю общения с поддержкой и просмотреть ранние обращения. Настроены оповещения по критичным для пользователя платформы событиям: приближение к порогу лимита услуги, сообщение о необходимости пополнить баланс во избежании попадания в стоп-лист, отчет об отсутствии результатов поиска по онлайн поставщику, новости о нововведениях платформы, отчеты о результатах обновления склада и так далее.
Для повышения качества поддержки сотрудники в баг-трекере видят каунтеры, подсчитывающие тикеты, в которых ожидается ответ поддержки. На почту поступают письма, оповещающие о том, кому из клиентов необходимо ответить. Мы постарались сделать интерфейс и в целом сервис поддержки максимально простым и быстрым.
Порядок распределения клиентских запросов
Функционал платформы постоянно расширялся, добавлялись новые модули, настройки. Каждый сотрудник локально по конкретному запросу выяснял у разработчика тонкости реализации, отвечал клиенту, закрывал запрос. При поступлении через некоторое время подобного запроса другому сотруднику схема повторялась, так как никто уже не помнил, что ранее был обработан идентичный запрос. Поддержка столкнулась с проблемой коммуникации внутри отдела. Мы постоянно тратили время на совещания между собой, на консультации с разработчиками, которые всегда ругались, что их отвлекают.
Пришлось немного перестроить схему распределения запросов и коммуникации с другими отделами. Ее же используем и сейчас. Упрощенная схема взаимодействия представлена ниже (без детализации работы других отделов).
Запрос от клиента может поступать в форме звонка или запроса через Mantis. Во время звонка мы всегда уточняем, есть ли активный тикет. Если его нет — просим создать, чтобы перенести все коммуникации в него.Так происходит в 85% случаев. (Остальные 10 — звонки для перевода на других сотрудников, 5% — простые и быстрые консультации по телефону не более 2-3 минут). По сути любое обращение трансформируется в тикет. Они могут быть типичные и нестандартные. Типичные напрямую назначают себе сотрудники поддержки. Нестандартные забирает руководитель поддержки для выяснения деталей, ТЗ и т.д. При этом каждый комментарий по каждому запросу доступен к прочтению в почте всем сотрудникам. Таким образом, все в курсе того, какие запросы и как решает коллега. Такая схема позволяет руководителю всегда быть в курсе всех тикетов, сотрудникам — знать, что происходит в запросах у коллег. Это помогает избежать дублей, пересечений вопросов в запросах, контекстно повышать уровень знаний.
Конечно, есть такие запросы/ошибки, которые требуют вмешательства разработчиков для исправления/разработки. В этом случае сотрудник поддержки разбирает проблему, воспроизводит ее и пишет в дополнительной (скрытой от клиента) информации алгоритм получения ошибки для отдела разработки. Далее задача возвращается руководителю поддержки. Он еще раз проверяет ситуацию и, в случае ошибки платформы, передает задачу в отдел разработки. Далее назначается ответственный за решение и происходит обработка запроса. Важным моментом является то, что все вопросы с разработчиками решаются через руководителя поддержки, то есть разработчик отвлекается минимальное количество раз. Время, затраченное на консультации, списывается с клиентов, в случае если не было ошибки с нашей стороны.
В процессе работы пришло понимание, что соотношение количества клиентов к затрачиваемым на них ресурсам поддержки несоизмеримо. Это стало проблемой. Количество часов, затрачиваемых на поддержку через баг-трекер, не учитывалось. Обучение функционалу мы проводили персонально для КАЖДОГО вновь прибывшего пользователя платформы, используя телефонную связь и TeamViewer. Такое обучение в среднем занимало около двух часов на одного нового клиента. Более того, такой индивидуальный подход приводил к тому, что клиенты самостоятельно ничего не хотели настраивать, по самым простым вопросам звонили и создавали тикеты. Возникла острая необходимость в изменении процесса оказания поддержки.
Были внедрены следующие изменения:
- Интерактивное обучение с помощью вебинаров раз в 2 недели для всех желающих.
- Количество часов поддержки стало лимитированным, в зависимости от выбранного при подключении тарифа.
- Мануалы по работе для клиентов были расширены и упорядочены.
- Произведена автоматизация части модулей платформы, чтобы клиент мог сам выполнить настройку без участия поддержки.
Результат не заставил себя долго ждать. Мы получили огромную экономию ресурсов отдела. На самом первом графике в статье видно примерное количество поступающих в год тикетов. После реализованной автоматизации, перехода на вебинары и других мер, запросов поступило уже значительно меньше. Данная тенденция связана именно в оптимизацией многих процессов.
Каждое из перечисленных выше изменений в работе принесло свои плоды. Ограничение количества включенных в тарифные планы часов поддержки сильно повлияло на поток отправляемых тикетов. Клиенты стали больше обращаться к документации, видеоурокам, посещать вебинары. Никому не хотелось “упереться в лимит”, превысить его и дополнительно оплатить работы по оказанию техподдержки.
Интерактивное обучение
Хотелось бы подробнее рассмотреть выбор системы интерактивного обучения, так как после ее внедрения высвободилось больше всего ресурсов. Мы выбирали из многих предложений на рынке вебинаров, и выбор пал на продукт “Gotowebinar” от компании Citrix.
Основные критерии подбора:
- качество отрисовки изображения;
- качественная обратная связь (возможность ведения диалога с подключившимся голосом и в переписке);
- большое количество одновременно подключенных слушателей;
- стоимость использования услуги;
- возможность записи вебинара.
В сводной таблице указаны программные продукты, которые были рассмотрены при поиске оптимального.
| webinar.ru | Gotowebinar.com | wiziq.com | webex.com | imind.ru | |
| Качество отрисовки изображения | хорошее | отличное | плохое | плохое | плохое |
| Качественная обратная связь | присутствует | присутствует | ? | ? | ? |
| Большое количество одновременно подключенных слушателей | до 500 человек одновременно | до 100 человек одновременно | ? | до 100 участников | до 1000 участников |
| Стоимость использования услуги | 100$ в месяц | ? | |||
| Возможность записи вебинара | да | да | ? | да | ? |
Найти подходящий продукт было очень сложно. В каждом из рассмотренных продуктов были какие-то подводные камни: ограниченное количество часов записи, неадекватная ценовая политика при необходимых нам критериях, ужасное качество отрисовки изображения.
Конечно, указанные в таблице критерии при выборе подобной системы могут быть другими, но наш выбор себя оправдал. Нет проблем с подключением у клиентов, видео записывается качественно, сохраняется локально. Записывается голос ведущего, а также участников вебинара.
Впереди еще много улучшений, но на текущий момент можно смело заявить, что все описанные выше шаги привели к становлению наиболее стабильной и оптимальной схемы взаимодействия с клиентами, позволили улучшить качество оказываемой поддержки, равномерно распределить ресурсы отдела.
P.S. Немного статистики на текущий момент:
- В день поступает от 40 до 90 тикетов от клиентов.
- В отдел поддержки входят 4 сотрудника и руководитель.
- В будний день поступает порядка 30 звонков на поддержку.
- В месяц один сотрудник может обработать около 300 тикетов
- За все время существования платформы было обработано порядка 66000 тикетов.
- За полный 2010 год поступило и было обработано 3620 тикетов от 65 клиентов
- За полный 2014 год — 17192 от 821 клиента
- Консультации — 70% от общей массы
- Ошибки — 15% от общей массы
- Запросы о желаемом, но не выполнимом — 15%