Входящие обращения: все каналы в одном окне

Клиент пишет в мессенджер, звонит на мобильный, отправляет форму с сайта и через день дублирует всё на почту. Четыре обращения — а человек один, и он уверен, что уже всё объяснил.

Мы собирали такую обработку обращений клиентов у себя и в проектах клиентов: все каналы сходятся в одну очередь. Расскажу, как это устроено внутри, сколько заняло и на чём мы спотыкались — без общих слов про «омниканальность».

Что такое входящие обращения

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

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

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

Почему заявки теряются

Причина не в невнимательных менеджерах. Причина в том, что у обращения нет одного места, где оно живёт.

Пока каналов два-три, всё держится на памяти конкретного человека: он помнит, что «этот из мессенджера — тот самый, что вчера звонил». Как только каналов становится больше, а менеджеров двое, память перестаёт работать. Один ответил в переписке, другой перезвонил, третий не знал ни о том, ни о другом.

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

«Одно окно» — это не общий чат

Обработка обращений клиентов начинается не с выбора программы, а с решения, где обращение живёт. Первое, что обычно предлагают: заведите общий чат, куда всё пересылается. Так делать не стоит — это перекладывание бардака в другое место. Через неделю там каша, из которой ничего не найти, и половина обращений без ответа, потому что «я думал, ты ответил».

Слева очередь: канал у каждого обращения свой, а список общий. В шапке диалога — состояние и срок: «Ждём клиента, до конца рабочего дня». Отвечает оператор оттуда же, не переключаясь в мессенджер или почту.

Все каналы — одной полосой. Переключатель сверху фильтрует очередь, но очередь общая: обращение не «живёт в мессенджере», оно живёт в системе.

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

Обработка входящих обращений: три состояния вместо «прочитано»

Обработку входящих мы переделывали дважды, поэтому расскажу подробно — это самая неочевидная часть.

Соблазн сделать два состояния: новое и закрытое. На практике нужно три:

• ждёт нашего ответа — клиент написал, мяч на нашей стороне, идёт отсчёт просрочки;
• ждём клиента — мы ответили, теперь ждём его; отсчёт не идёт, но диалог живой и на виду;
• закрыт — вопрос решён.

Ключевое правило: автоматика никогда не закрывает диалог сама. Закрыть может только человек, кнопкой. У нас была ошибка, когда система закрывала диалог после ответа оператора — и обращения пропадали из воронки, а вместе с ними лиды, по которым никто не перезвонил.

И отдельно: просмотр диалога не считается обработкой. Открыл, прочитал, отвлёкся — обращение всё ещё ждёт ответа. Снимается только ответом, закрытием или обратным звонком. Иначе счётчик показывает картину благополучия, которой нет.

Сколько ждёт клиент: у каждого канала свой срок

Общий норматив «отвечаем за 15 минут» не работает, потому что ожидания в каналах разные. Человек, который написал в мессенджер, ждёт ответа как в переписке с приятелем. Человек, отправивший письмо, готов ждать до конца дня. А тот, кто позвонил и не дозвонился, ждёт обратного звонка прямо сейчас.

Поэтому срок ответа задаётся по каждому каналу отдельно. У нас нормативы по умолчанию такие:

Канал	Срок ответа	Почему так
Телефон	сразу	пропущенный звонок — это клиент, который уже ждёт; перезваниваем в первую очередь
Чат на сайте	10 минут	человек сидит на странице прямо сейчас, через 10 минут он уйдёт
Мессенджеры	10 минут	ожидания те же, что в личной переписке
Почта	до конца рабочего дня	письмо пишут, когда готовы ждать

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

Отдельная логика у телефонии. Пропущенный входящий — это «ждёт нашего ответа» со всей просрочкой. Принятый — «ждём клиента»: поговорили, мяч на его стороне. Исходящий — тоже «ждём клиента». Без этого разделения принятые звонки висели в просроченных, и сводка по загрузке врала.

Интеграция мессенджеров с CRM и остальных каналов

Технически каждый канал подключается своим способом, и почти в каждом есть подвох.

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

Отдельная тонкость — вложения. Файлы и голосовые узел не пересылает ссылкой, а забирает у нашего хранилища и отдаёт в мессенджер байтами: по ссылке вложение на стороне клиента просто не открывается.

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

• Токен бота хранится только на узле. На сервере портала его нет вовсе — сервер знает лишь адрес узла и общий секрет. Даже полный доступ к серверу не даёт возможности писать клиентам от имени компании.
• Каждый запрос подписан секретом. Без него узел не принимает ничего: адрес его открыт, но отправить через него сообщение посторонний не может.
• Секреты в браузер не уходят. Отправкой занимается сервер, а не страница у оператора — иначе ключ оказался бы у каждого, кто открыл вкладку разработчика.
• У бота минимум прав. Только то, что нужно для переписки: отправлять, править и удалять свои сообщения. Ни изменения настроек канала, ни приглашений, ни назначения администраторов.
• Узел ничего не хранит. Он транзитный: принял сообщение, передал дальше, забыл. Ни переписки, ни файлов, ни истории обращений — всё это лежит в системе, где ему и место, под вашими правилами доступа. Даже если узел окажется скомпрометирован, забирать там нечего: только то, что проходит через него в эту секунду.

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

Почта. Хостинг принимал почтовые подключения только со своих адресов, поэтому мост поставили на сервер сайта: он забирает письма и передаёт их в очередь, а ответы отправляет обратно.

Со стороны клиента это выглядит просто: он выбирает привычный ему способ. Куда обращение попадёт дальше — не его забота.

Чат на сайте. Виджет с поллингом — окно раз в несколько секунд спрашивает, нет ли ответа. Ставить постоянное соединение ради чата, которым пользуются десятки раз в день, смысла нет. Заодно виджет показывает имя специалиста и «печатает…», когда оператор набирает ответ, — мелочь, но человек перестаёт уходить со страницы.

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

Согласие на обработку данных: в каждом канале, а не один раз

Как только обращения сходятся в одно место, у вас появляется база персональных данных: имена, телефоны, почты, история переписки. Дальше вопрос не в удобстве, а в том, на каком основании вы всё это храните.

Согласие нужно получать в каждом канале, где человек оставляет данные, а не один раз галочкой где-то на сайте. Форма на сайте, чат, заявка на обратный звонок — везде своя точка входа и своё согласие.

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

Три правила, которые мы заложили сразу:

• Журнал только пополняется. Записи нельзя изменить или удалить задним числом — ни из интерфейса, ни случайной правкой. Журнал, который можно поправить, ничего не доказывает.
• Отзыв — такая же запись, а не удаление прежней. Человек написал «удалите мои данные» — фиксируем отзыв и видно, что было дальше. История остаётся целой.
• Рекламные рассылки — отдельное согласие. Согласие на обработку данных и согласие на рекламу это разные вещи, и путать их не стоит: первое позволяет вам обработать заявку, второе — писать человеку потом.

Отдельно про то, чего мы намеренно не храним: IP-адрес. Его часто пишут «на всякий случай», но для подтверждения согласия он ничего не даёт, а данных о человеке добавляет. Меньше собрали — меньше рисков.

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

Склейка: один человек, а не три записи

Клиент пишет с личного аккаунта, звонит с рабочего номера и оформляет заказ на почту жены. Для системы это три разных контакта — и если их не связать, история рассыпается.

Мы сводим сначала по телефону, приводя номер к единому виду и сравнивая последние десять цифр, потом по почте. Это закрывает большинство случаев. Остаётся хвост, который автоматика связать не может — например, контакт из мессенджера, где нет ни телефона, ни почты. Для него нужна ручная кнопка «объединить»: выбрать вторую запись, и все каналы, диалоги и заказы переезжают на основную.

Одно правило про объединение стоит заложить сразу: главной остаётся та запись, у которой есть личный кабинет. Иначе менеджер случайно объединит «в другую сторону» и снесёт учётную запись вместе с историей заказов.

Сколько это заняло

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

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

На чём мы спотыкались

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

Не договорились, что считать закрытым. Одни закрывали сразу после ответа, другие держали до оплаты. Отчёты в такой ситуации показывают погоду на Марсе.

Считали не то. Отчёт «сколько всего обращений» бесполезен — он растёт вместе с рекламой. Смотреть надо на просроченные, на повторные обращения (клиент написал второй раз, не дождавшись) и на то, по каким каналам просрочка чаще. Последнее обычно и вскрывает узкое место.

На что смотреть, если выбираете программу

Программ для обработки заявок много, и список поддерживаемых каналов у всех примерно одинаковый. Смотреть стоит на другое:

• закрывает ли она исходящие — то есть можно ли из неё ответить в каждый канал, а не только принять оттуда;
• можно ли задать свой срок ответа по каждому каналу, а не один общий норматив;
• кто закрывает диалог — человек или автоматика;
• как объединяются контакты, когда один человек пришёл с трёх сторон;
• что происходит при отзыве согласия на обработку данных.

Ответы на эти пять вопросов расходятся у систем сильнее, чем список каналов.

Что в итоге

Единое окно даёт не столько скорость, сколько предсказуемость. Клиент перестаёт чувствовать, что его обращение может провалиться, а менеджер перестаёт держать в голове десяток переписок.

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

Как устроена система, частью которой эта очередь является, — в разборе CRM, ERP или портал.

Как устроен сам сайт, из которого приходят и обращения, и заказы, — в разборе про интернет-магазин и его связь с CRM.

Как в эту же очередь попадают заявки с сайта — в статье про заявки с сайта в Telegram и MAX, а как подключается отдельный мессенджер со своим ботом, файлами и правовым основанием переписки — в разборе про MAX для бизнеса.

Единое окно редко остаётся единственной задачей: следом обычно идёт автоматизация бизнес-процессов целиком — заказы, документы, деньги.

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