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

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

В прошлой статье (ссылка) я разобрал конвейер между агентом и клиентом: теги, регулярки, абзацы по 180 символов. Осталось два больших пояснения - что происходит со сделкой в amoCRM, когда диалог дошёл до неё, и стоп-кран, которым человек перехватывает диалог у бота. Поэтому сегодня показываю два Salesbot’а, которые замыкают контур: "Раздатчик" (диспетчеризация задач менеджерам) и "Идентификатор" (оцифровка старой базы).

Хочу начать с вопроса, который оставался за кадром всех предыдущих статей. Нода IF: Is New User? в начале ветки проверяет Redis-ключ связки: пустой - значит клиент новый, запускаем синхронизацию со сделкой. А если клиент старый - заведён в CRM руками за год до внедрения ИИ? Если к примеру как в данном проекте, из-за внутренних решений касательно бизнес логики у заказчика сделки хранятся до последнего момента, наверное пока их не наступит больше чем за 30000 штук (P.S. про это я позже расскажу чуть позже - точнее про то КАК это ломает работу воркфлоу)? У него связки тоже нет. Формально он выглядит как новый. Обычная система в этот момент создаёт вторую сделку на первого же старого клиента, который написал ночью. Дубль. Добро пожаловать в слепую зону.

Всем привет!) Напомню: в первой статье я показал дебаунс на Redis, который склеивает дробные сообщения клиента. Во второй — модуль привязки «чат = сделка» и то, почему вебхуки стоит держать в изолированных ключах. Обе части заканчиваются примерно одинаково: «...и текст уходит ИИ‑агенту». Это, пожалуй, тот финал, на котором обычно ставят точку и заливают демо на GitHub... Но не в данном случае!)

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

Есть ошибки, которые невозможно предотвратить внимательностью.

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

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

Меня зовут Михаил Аймаутов, я отвечаю за ИТ и автоматизацию в Wollmer — компании, которая занимается бытовой техникой. Расскажу, как мы перестроили самый ручной процесс в компании, и почему бо́льшая часть работы оказалась не про код.

«Интеграция с телефонией» — фраза, за которой может стоять что угодно. От «раз в сутки подтягиваем список звонков» до «менеджер разговаривает с клиентом во вкладке браузера, а карточка клиента открылась сама, ещё до того как он сказал „алло“».

Мы делаем FARA CRM и прошли этот путь целиком: сначала перенесли рабочий модуль Asterisk, потом привели к одному контракту облачные АТС, потом сделали трубку прямо в браузере — а под конец обнаружили, что без собственного TURN-релея половина этой красоты «то соединяется, то нет». И добавили релей в поставку.

В статье — три вещи: