Три верных способа испортить отношения саппорта и разработки

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

Клиент: Добрый день! Я не могу открыть ваше приложение

Саппорт: Здравствуйте! Принял. Отдаю в разработку. Как только они что-то прояснится, я вам перезвоню.

Саппорт: Кэп, у нас проблема. Клиент не может открыть наше приложение. Что это может быть?

Разработка: Наконец добрался до твоего вопроса. Я только что открыл приложение. Всё работает. Не знаю, что там у клиента не открывается.

Саппорт: $#*@%!!!

Клиент: Добрый день! Я не могу открыть ваше приложение.

Саппорт: Здравствуйте! Давайте вместе с вами попробуем его открыть. Ваше первое действие?

Клиент: Ну, я захожу на сайт и не могу зайти в программу.

Саппорт: Ага. Я правильно понимаю, что вы хотите зайти в систему через браузер на компьютере, а не приложение на телефоне?

Клиент: Ну да!

Саппорт: Понял вас. Проверяю. У меня всё работает. Давайте ещё раз попробуем вместе. Введите пароль. Возможно, вы по ошибке указали не тот?

Клиент: Пароль правильный, у меня всё записано. Вот он, пароль….. Аааааа. Стоп. У меня же капслок включён. Теперь всё работает. Спасибо! Извините.

Саппорт: Рад помочь. Обращайтесь.

Катерина Виноходова

сооснователь Юздеска

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

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

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

А ещё массовость проблемы сразу повышает уровень её критичности — об этом дальше.

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

Возмущенный клиент пожаловался на саппорт и мы начали разбираться

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

Последний шаг — быстро решить проблему. Клиент доволен, конфликт исчерпан

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

Уровни критичности

1 Совсем не влияет на работу, просто создаёт неудобства


2 Влияет на работу, но не критично


3 Критично влияет на работу, но можно потерпеть пару дней


4 Полностью останавливает работу пользователя

Примеры

✓ Календарь выглядит некрасиво
✓ Неудобно выбирать период в календаре
✓ При сохранении настроек изредка выскакивает ошибка, хотя настройки сохраняются
✓ На десять случаев применения шаблона один раз слетает вёрстка
✓ Не работает раздел отчётов
✓ Система не открывается
✓ В систему не приходят письма
✓ Не работает правило автоматизации

3. Описание проблемы по шаблону. Без шаблона оператор напишет сочинение на вольную тему, а разработка будет разгадывать этот ребус и сильно материться. Но стоит дать оператору шаблон, и ему останется просто заполнить все пункты: указать ID компании, отметить массовость проблемы, определить уровень критичности, расписать по шагам все действия клиента, после которых возникает ошибка, указать URL с проблемой, добавить скриншоты. А разработчик сможет быстро пробежаться по знакомой структуре, понять суть проблемы и решить, что и когда делать.

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

Вы можете использовать наш шаблон или на его основе создать свой → скачать шаблон постановки задачи разработчикам (.pdf).

Саппорт: Кэп, у нас проблема. У клиента прила не работает. Отправил тебе инфу.

Разработка: Ага, пробежался по диагонали, через два часа смогу глянуть внимательно.

Саппорт: Но это же Иван Иванович, я же там тебе написал в конце документа приписку. Он сам звонил и ругался. Если сразу не сделаем, будет разрыв мозга.

Разработка: $#*@%!!! Так бы сразу и сказал, я не дочитал... Смотрю …. А что именно у него не работает?

Саппорт: Эммм… Сейчас перешлю тебе скрин… Вот...

Разработка: Тааак, вижу. А после чего возникает эта проблема?

Саппорт: Я же написал.

Разработка: $#*@%!!! Где? Не вижу.

Саппорт: В четвёртом абзаце пятое предложение.

Разработка: Ага, нашёл. А есть URL ошибки?

Саппорт: $#*@%!!!

Саппорт: Кэп, у нас проблема. У клиента прила не работает. Отправил тебе инфу.

Разработка: Ага, вижу, это снова Иван Иванович. По скринам вижу, быстро сможем поправить. Да, вижу ошибку, всё понял. Сразу берём в работу.

Саппорт: Отлично! Он ждёт.

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

Чтобы эта система работала нужно:

1. Назначить администратора со стороны разработки. Администратор по задачам со стороны разработки принимает задачи от саппорта и распределяет их среди разработчиков. Если такого человека нет, операторы будут постоянно дёргать разработчиков и отвлекать от работы, что приведёт к конфликтам. Функцию администратора может взять на себя руководитель отдела разработки, менеджер проекта или можно нанять на эту работу специального человека. Он будет контролировать нагрузку каждого сотрудника и равномерно распределять задачи в зависимости от их сложности и сроков.

2. Установить сроки для разных задач. Разработка постепенно берёт в работу задачи в зависимости от уровня их критичности. Например, задачи с четвёртым уровнем критичности берут в работу сразу, с третьим — на следующей неделе, со вторым — через неделю, с первым — через две недели. Так разработчики получат равномерную нагрузку, а операторы саппорта будут точно знать сроки выполнения всех своих задач и смогут сразу предупредить клиентов, когда будет движение по их вопросу.

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

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

4. Наладить обратную связь разработка → саппорт. Бывает, у разработчика в процессе решения задачи возникают дополнительные вопросы к саппорту. Без ответа он не может продолжать работу. У нас был случай, когда разработчики писали в Jira вопросы к задачам. Комментарии приходили сотрудникам саппорта в корпоративную почту, но те её не читали. В результате у нас зависло много задач. Когда это выяснилось, мы настроили систему так, чтобы сообщения с упоминаниями операторов приходили им в виде тикетов в Юздеск, как от клиентов, и проблема решилась. Чтобы задачи не зависали из-за проблем коммуникации, обеспечьте разработке возможность получить от саппорта обратную связь.

5. Создать отдельный чат для критичных задач. Для особо критичных задач у нас есть отдельный чат, куда операторы их дополнительно скидывают, как только поставили задачу в Jira. А иногда бывает так, что проблема понятна, решение тоже, но на формулирование задачи по шаблону нужно время, которого нет. Тогда оператор описывает задачу в чате, и её сразу начинают смотреть разработчики, после чего её формулируют в Jira. Разработка в первую очередь берёт в работу задачи из чата.

Саппорт: Кэп, я вчера кидал тебе одну задачку. Что с ней? Когда сможешь посмотреть?

Разработчик: Собирался вчера, но совсем замотался. Сегодня тоже всё горит. Завтра точно посмотрю.
….

Саппорт: Ну как там моя задача? Мне бы побыстрее, а то клиент снова звонил. Что ему сказать?

Разработка: $#*@%!!! Братан, прости, не успеваю. Можешь Ивана попросить глянуть?

Саппорт: $#*@%!!!

Саппорт: Поставил задачу, она горит, поэтому дублирую в чат.

Администратор: Понял. Смотрю…. Вижу, задача горит. У Ивана сейчас как раз есть окошко. Отдаю задачу ему и ставлю срок послезавтра.

Саппорт: Отлично! Спасибо.