eng
Заказать звонок
Заказать демо
Чат

Техподдержка: работа на предупреждение

Рубрика:Презентация
Дата публикации: 12 Декабря 2018
Автор:Аделия Животовская


Главные задачи саппорта «Системных Технологий» — помочь пользователю сейчас и исключить повторение проблемы в будущем. Это непросто, но возможно: рассказывает Аделия Животовская.

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

Если потребность обратиться в саппорт все-таки возникает, «Системные Технологии» предоставляют пять каналов для коммуникации: мобильный портал (с доступом из приложения «ST Мобильная Торговля»), web-портал, телефон, e-mail и скайп.

Консультация «на будущее»

Нам важно не просто ответить на вопрос, а объяснить, как поступать в аналогичных случаях. Чтобы сотрудник клиента тратил как можно меньше времени на общение с нашими специалистами. Например, к нам обратился торговый представитель, у которого не идет обмен данными из-за отсутствия доступа к интернету. Мы объясняем, как проверить настройки и подключение к сети. И если ситуация повторится, человек уже будет знать, что делать. Этот подход дает свои плоды: по статистике, всего 1% агентов дважды обращается к нам с одной и той же проблемой.

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

Аделия Животовская рассказывает о работе технической поддержки на конференции SFA-2018

От процессов до терминологии

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

  1. Обходные пути.
  2. Если возникает дефект, мы оперативно предоставляем решение, которое позволит сотруднику клиента продолжить работу на маршруте. А сами досконально изучаем причину возникновения ошибки и ее последствия и устраняем неполадку совместно с разработчиками. Затем проверяем решение, и, как правило, ошибки не повторяются.

  3. Экспертиза в бизнес-процессах.
  4. Когда выходит новая доработка для клиента, технические клиент-менеджеры (ТКМы) изучают ее, а затем доносят информацию до остальных сотрудников службы поддержки. Это существенно экономит время при решении обращений: инженер, погруженный в проект, уже на этапе анализа запроса может понять, в чем ошибка.

  5. Оценка эффективности проектов.
  6. ТКМ оценивает также эффективность использования программного обеспечения на стороне клиента и дает рекомендации. Есть такой пример: уже после внедрения нашей системы клиент продолжал пользоваться программой для составления ряда отчетов. Менеджер выявил эту ситуацию и показал, как аналогичный функционал работает в «ST Чикаго», позволив клиенту сэкономить на ПО.

    Когда поступают запросы на доработку, ТКМ смотрит — не покрывает ли имеющийся функционал этот запрос. Клиент зачастую не может полностью оценить все возможности «ST Чикаго». ТКМ ему в этом помогает.

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

Работа над оценками

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

оценка.jpg

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

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

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

Мобильный портал

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

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

мобильный портал3.png

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

Новые услуги

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

Сверка данных

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

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

Если клиент делает сверку самостоятельно: оператор каждый месяц запрашивает отчет у дистрибьютора, выгружает данные в «ST Чикаго» и делает сверку. Если найдено расхождение, оператор пытается понять, откуда оно взялось, делает детализацию вплоть до товара, до даты. Работа по анализу данных одного дистрибьютора занимает 3-6 часов. И уже после этого оператор обращается в техподдержку, и мы проверяем интеграцию, смотрим синхронизацию и при необходимости связываемся с дистрибьютором и решаем вопрос. Причины могут быть самыми разными, например, дистрибьютор выгрузил отчет с некорректными единицами измерения товара — надо в коробках, а он отправил в штуках.

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

2 недели * 4 часа * 50 дистрибьюторов = 400 часов в месяц на сверку данных.

Это без учета времени на то, чтобы наши сотрудники научили операторов делать сверки.

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

Проверка соответствия форматов файлов, поступающих от дистрибьюторов

Это еще одна новая услуга, которая помогает экономить ресурсы клиента. Мы анализируем лог-файлы на ошибки в форматах файлов и контролируем их устранение со стороны дистрибьютора. Дополнительно для ИТ-специалистов дистрибьютора настраиваем соответствующие автоинформаторы. И только если есть проблемы в коммуникации с дистрибьютором, если он не устраняет ошибку, мы оповещаем центральный офис клиента.

Лог-файлы (logs или логи) — это файлы, в которых ведутся записи абсолютно всех событий, происходящих в системе. В первую очередь, мы анализируем их для отслеживания работоспособности системы. Если у одного дистрибьютора выявляется много ошибок — значит, что-то идет не так. И к нам еще не пришел никакой запрос, а мы уже реагируем и исправляем ситуацию.

Оценка корректности справочных данных

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

Full SLA и HDA

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

  1. В процессе консультации сотрудника клиента, мы повышаем его уровень знания ПО, даем рекомендации по самостоятельному устранению сложностей в будущем. И, как правило, с одним и тем же запросом агенты к нам не обращаются. При формате поддержки HDA специалисту клиента сложно выделить достаточно времени на обучение конечных пользователей системы. А значит, с одними и теми же вопросами к нему приходят снова и снова. Кроме того, технический специалист клиента не всегда может полноценно проконсультировать с точки зрения знания всего функционала, и он вынужден обращаться к нам.
  2. Только на Full SLA есть мобильный портал технической поддержки для быстрой регистрации обращений конечных пользователей.
  3. Обновление системы проектной командой с привлечением специалистов разработки. Значит, обеспечивается максимальное качество проверки согласованных с клиентом объектов системы. Возможные неполадки устраняются в кратчайшие сроки. То есть когда за процесс обновления отвечаем мы, все проходит максимально качественно.

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

Сбор обратной связи от клиентов — обязательный для нас шаг при работе с любым клиентом. Мы сами обзваниваем конечных пользователей, находящихся на Full SLA и уточняем, все ли в порядке. Иногда выявляем случаи, когда сотрудники стесняются позвонить и что-то спросить, и в итоге их KPI ухудшаются.

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



Вам также могут быть интересны статьи: