заметки о подходе «я передал специалисту, вам перезвонят»
А вы встречали должность-называется она «я передал». — Ваш запрос принят. — Ваш запрос передан. — Ваш запрос находится у специалиста. — Какого специалиста? — Очень хорошего. Наверное. И всё.
Менеджер выдохнул. Задача покинула его и перекочевала другому человеку/отделу, вместе с ответственностью.
Где-то в CRM вспыхнула зелёная галочка. Где-то руководитель увидел красное уведомление.
А клиент сидит с телефоном и думает: «Мне-то теперь что делать?»
В силу опыта , встречаются такие ситуации: внутри компании может быть семь отделов, три линии поддержки, программист, консультант, менеджер, руководитель проекта и загадочный Сергей, который «точно знает, как это решить».
Но клиенту Сергей неинтересен.
Клиент пришёл не знакомиться с вашей оргструктурой. Он пришёл решить вопрос. Поэтому, в работе применяю иной подход - когда я или сотрудник принимаем запрос, важно понять, что человек вообще хочет получить в результате?
Потому что фраза клиента «у нас не работает отчёт» иногда означает бремя, стресс на его плечах: — отчёт не открывается; — цифры неправильные; — бухгалтер завтра сдаёт отчётность и уже смотрит в сторону окна; — директор хочет видеть прибыль, а видит какую-то бухгалтерскую мифологию,
который мы можем забрать и решить благополучно, при этом облегчить жизнь клиенту.
Вот почему я всегда за общую вовлечённость. Не обязательно знать ответ на всё. Но если запрос пришёл к тебе — нужно сохранить его реальный смысл. Понять ожидание клиента, передать контекст. Проверить, что специалист понял задачу так же. Вернуться к клиенту, сориентировать его и чтобы он понимал, что ты его будешь держать по прогрессу. Обязательно убедиться, что результат совпал с тем, чего он ждал. Для меня важно сформировать другой подход к клиенту. Менеджер может не знать технический ответ. Может подключить консультанта, программиста и т.д — это нормально.
Но он должен понимать, что происходит с запросом дальше, не терять контекст и оставаться для клиента тем человеком, который помогает довести вопрос до понятного результата. Именно этому подходу я обучаю сотрудников: принял клиента — значит, не потерял его по дороге.
Последствия потери обычно шире.
Сначала клиент чувствует, что его вопрос никому по-настоящему не принадлежит. Он снова объясняет ситуацию, сам ищет ответственного, сам напоминает о себе. Доверие начинает падать.
Дальше растёт раздражение. Даже если технически вопрос потом решат, впечатление от компании уже испорчено.
Потом появляются уже бизнес-последствия: клиент меньше готов покупать дополнительно, сложнее соглашается на новые проекты, охотнее сравнивает вас с конкурентами и при удобном случае уходит.
Важная задача-научить команду не просто передавать задачи, а сохранять ответственность за клиентский результат, задавая стандарты работы.
· 17.08
Спвсибо, это звучит логично абсолютно, но компании чаще глубоко индефферентно. Вон с ПИКом переписывался - срочная ситуация, надо быстро реагировать - но оператор создает заявку, и кроме этого действия больше ничего не может вообще. Ругайся, нет - эта функция может только передавать и создавать заявки и глушить любые альтернативные каналы коммуникации. И еще спасибо, что не ии
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 18.08
Соглашусь, есть куча исключений в разных сферах-загрузка, жесткие регламенты, большой спрос за результаи, но незначительно наделенные права.
И конечно же, какой результат для компании идеальный-качать права сотрудниками внутри команды , или чтобы все же вопрос клиента/партнера был решен качественно и быстро, и он остался в компании лояльный.
Отлаженные внутренние коммуникации в команде не менее важны.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён