Ситуация, когда заказчик начинает писать напрямую разработчику, дизайнеру или специалисту поддержки в обход руководителя, часто воспринимается как потеря контроля. Возникает риск, что клиент продавит бесплатные доработки, собьет приоритеты или получит сырой ответ, который выставит компанию в плохом свете. Но реагировать запретами сразу не стоит. Сначала нужно понять причину обхода и выстроить процесс так, чтобы коммуникация не ломала экономику и сроки проекта.
| Какой вопрос закроем | Что станет понятно |
| Как оценить масштаб проблемы | Увидите разницу между рабочим обсуждением и нарушением границ |
| Что сказать сотруднику и клиенту | Получите готовые формулировки для возврата коммуникации в нужное русло |
| Когда прямой контакт нужно оставить | Перестанете быть “бумажным фильтром” там, где ваша роль не нужна |
Главное правило и быстрый ответ
Если вы узнали, что клиент общается с вашей командой напрямую, никогда не начинайте с претензий к клиенту.
Быстрый алгоритм действий:
- Спросите сотрудника, о чем идет речь и комфортно ли ему это общение.
- Снабдите сотрудника скриптом ответа для перевода задач на вас.
- Напишите клиенту сами, обозначив заботу о проекте, а не уязвленное самолюбие.
- Создайте единый чат в Telegram или другой рабочей среде, где присутствуют все стороны, но задачи ставите только вы.
Почему клиент ушел к специалисту: три сценария и решения
Ваша реакция полностью зависит от того, почему заказчик решил обойти вас.
Сценарий 1. Клиенту так быстрее (и он не давит на сотрудника)
Заказчику нужно уточнить техническую деталь, передать доступы или спросить, как работает конкретная кнопка. Ему кажется нелогичным писать аккаунт-менеджеру, чтобы тот передал вопрос программисту и вернулся с ответом через три часа.
Что делать: Легализовать этот процесс, но ограничить его рамками.
Создайте общий чат. Объясните клиенту и команде правило: технические вопросы и консультации можно решать напрямую в общем чате, но новые задачи, сдвиги сроков и бюджеты обсуждаются только с вами.
Сценарий 2. Клиент продавливает бесплатные доработки или срочность
Заказчик понял, что вы защищаете границы проекта и требуете доплату за новые “хотелки”. Он идет напрямую к дизайнеру или верстальщику и пишет: “Слушай, там делов на пять минут, поправь цвет, не будем ради этого дергать руководство”. Сотрудник теряется и делает.
Что делать: Жестко перехватывать управление. Вы должны стать “плохим полицейским”, чтобы защитить “хорошего” специалиста.
Объясните сотруднику, что такие просьбы ломают график других проектов. Дайте ему право ссылаться на вас во всех непонятных ситуациях. Клиенту нужно мягко, но твердо напомнить регламент работы.
Сценарий 3. Вы – узкое горлышко
Вы требуете, чтобы все общение шло через вас, но при этом долго отвечаете, искажаете техническую информацию при передаче или не понимаете суть правок. Клиент идет к специалисту от безысходности.
Что делать: Признать проблему и выйти из роли передатчика. Оставьте за собой только административные функции (договоры, счета, контроль часов). Позвольте клиенту ставить задачи специалисту напрямую, но внедрите систему трекинга задач, чтобы вы видели, сколько времени уходит на работу.
Как перевести общение на себя: формулировки
Не пытайтесь запретить клиенту писать в личку – это вызовет только раздражение. Действуйте через регламенты и заботу о результате.
Шаг 1. Инструктаж сотрудника (что ему отвечать)
Сотрудник не должен вступать в конфликт с клиентом. Его задача – вежливо перевести стрелки на вас. Дайте ему готовые шаблоны ответов:
- На мелкую просьбу: “Иван, правку принял, сейчас перешлю нашему менеджеру Анне, она добавит это в мой план на сегодня/завтра и сориентирует вас по времени.”
- На попытку дать новую задачу: “Задачу понял, звучит интересно. Но у меня сейчас жесткий приоритет по текущему спринту. Напишите, пожалуйста, Алексею, он перестроит мой график, чтобы я мог за это взяться.”
- На технический вопрос в личку: “Ответил вам в общем чате, чтобы история переписки сохранилась для всей команды.”
Шаг 2. Разговор с клиентом (что писать вам)
Когда вы увидели, что клиент пытается рулить процессом напрямую, напишите ему сами. Формулировка должна подчеркивать, что вы делаете это ради качества его проекта.
Плохо: “Пожалуйста, не пишите моему дизайнеру, все задачи ставятся только через меня.” (Звучит как обида бюрократа).
Хорошо: “Иван, вижу, что вы обсуждаете с Олегом новые экраны. Чтобы Олег не отвлекался от кода и мы не сорвали сроки текущего релиза, давайте все новые вводные обсуждать со мной. Я сам распределю его нагрузку, а он будет заниматься только вашим продуктом.”
Частые ошибки руководителя
При попытке вернуть контроль легко совершить действия, которые только усугубят ситуацию.
Ошибка 1. Ругать сотрудника за то, что он ответил клиенту.
Рядовой специалист почти всегда воспринимает заказчика как начальство. Ему психологически сложно отказать человеку, который платит деньги компании. Возлагать на него ответственность за нарушение субординации – значит демотивировать его. Учите его защищаться, а не наказывайте.
Ошибка 2. Отчитывать клиента в общем чате.
Публичные разборки в духе “я здесь руководитель, пишите мне” заставляют клиента чувствовать себя отчитанным школьником. Любые корректировки форматов общения с заказчиком должны происходить один на один.
Ошибка 3. Искусственно усложнять доступ к телу.
Требовать, чтобы клиент заводил тикеты в Jira или писал на почту, если раньше вы нормально общались в Telegram. Если клиенту нужен быстрый контакт, дайте ему быстрый контакт с вами, а не бюрократию.
Ограничения и исключения: когда прямой контакт необходим
Есть ситуации, когда пытаться вклиниться между клиентом и исполнителем вредно и бессмысленно. Не применяйте описанные выше шаги в следующих случаях:
- Формат аутстаффинга. Если вы “сдали в аренду” разработчика на проект клиента, он фактически становится членом команды заказчика. Ваша роль заканчивается на подписании актов и контроле выгорания сотрудника.
- Глубокие технические интеграции. Когда ваш DevOps-инженер и CTO клиента настраивают сервера, аккаунт-менеджер в переписке будет только мешать. Оставьте их вдвоем, попросив вашего инженера сигнализировать, если задачи выйдут за рамки договора.
- Выделенная поддержка (SLA). Если клиент оплатил пакет часов поддержки, он должен иметь прямой доступ к специалистам для решения срочных инцидентов. Руководитель подключается только при разборе полетов или превышении лимита часов.
