AI-чат поддержки по трекингу 24/7

01Бизнес-задача

В 3PL и крупных экспедициях 70–85% входящих обращений клиентов — однотипные запросы статуса: «где мой груз», «когда привезут», «изменился адрес доставки», «нужны документы». Диспетчер тратит 60–70% времени на эти вопросы вместо реальных проблем: задержки, повреждения, претензии, нестандартные маршруты. При большом потоке клиенты ждут ответа часами, лояльность падает.

Чат подключается к WMS/TMS, видит статус каждого груза в реальном времени и отвечает мгновенно, с конкретикой: «ваш груз №12345 сейчас на терминале в Екатеринбурге, отправлен сегодня в 14:30, прибытие в Челябинск завтра до 18:00». Сложные случаи — претензии, многоплечевые маршруты, ВЭД — передаёт живому диспетчеру с уже собранным контекстом: кто клиент, что за груз, какой статус, в чём вопрос.

02Типовой ROI

Параметры расчёта:

• Поток обращений по трекингу — от 100 в день для значимой экономики
• Среднее время диспетчера на типовое обращение — 4–7 минут
• Доля типовых запросов, которые AI закрывает полностью — 60–80%
• Доля запросов, переданных диспетчеру с собранным контекстом — 20–35%
• Среднее время ответа клиенту — секунды против минут/часов

Второй эффект — рост лояльности клиентов и меньше оттока. В B2B-логистике скорость ответа на «где мой груз» в час пик — это разница между «работаем» и «перевозчик нас бросил».

03На чём собрано — обсуждается под клиента

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

Что одинаково на всех проектах: данные клиента (грузы, маршруты, персональные данные водителей) остаются в инфраструктуре заказчика, я — подрядчик. Письменные гарантии по срокам и показатели (доля запросов без передачи диспетчеру, точность статусов, время ответа) прописаны в договоре. Журнал диалогов ведётся в системе клиента.

04Что нужно на старте

• API-доступ к WMS/TMS — главное и единственное обязательное условие. Без актуальных статусов чат бесполезен
• 500–1000 архивных диалогов диспетчеров с клиентами — чтобы настроить ответы и границы передачи диспетчеру
• Каналы коммуникации: сайт-виджет, Telegram-бот, WhatsApp Business (минимум один, лучше связка из 2–3)
• Правила передачи диспетчеру — какие запросы чат обрабатывает сам, какие отдаёт человеку (претензии, опасные грузы, ВЭД)
• Контакты ответственного у клиента в карточках сделок — чтобы знать, к кому обращаться при передаче
• Дежурный диспетчер для сложных случаев — даже круглосуточный чат должен иметь человека за плечом

05Точки риска

1. Устаревшие данные в WMS/TMS. Водитель доставил, но не отметил — чат отвечает «в пути». Защита: метрика свежести данных, явная приписка, если статус не обновлялся дольше заданного срока, авто-передача диспетчеру при подозрении на устаревание.
2. Конфликтный клиент в пиковый сезон. «Мой груз должны были привезти вчера, где он?!» — на эмоциональный запрос чат должен отвечать «передаю диспетчеру», а не «по нашим данным…». Защита: распознавание эмоций и мгновенная передача человеку на любом сигнале конфликта.
3. Блокировка WhatsApp Business за «массовую рассылку» при попытке слать уведомления первыми. Защита: только служебные сообщения с одобренными шаблонами Meta, никаких рекламных рассылок через канал поддержки.
4. Выдуманные ставки и сроки. «По нашему опыту обычно везут 3 дня». Защита: строгая инструкция — отвечать только по данным WMS/TMS, никаких прогнозов «из контекста». Любой срок прибытия — только из явных моделей доставки, не из нейросети.
5. Персональные данные водителей и грузополучателей. Чат не должен раскрывать клиенту телефоны и адреса водителей. Защита: явные правила фильтрации полей, маскирование, доступ только тем ролям, у кого есть право видеть.

06Анти-сценарий

• Меньше 50 обращений в день. Внедрение не окупается. Один диспетчер справится.
• Нет API у WMS/TMS или закрытая самописная система без поддержки. Сначала сделать доступ по API (это отдельный ценный проект), потом чат поверх.
• Уникальные грузы с нестандартным жизненным циклом (нефть наливом, негабарит с эскортом, фарма с температурным режимом). Слишком высокая цена ошибки даже на типовых вопросах, лучше живой диспетчер.
• Клиенты ждут человеческого контакта. Если привыкли звонить и говорить с конкретным менеджером по именам, чат вызовет негатив. Лучше делать помощника диспетчеру, а не замену.
• Регуляторные ограничения на автоматизацию коммуникаций (например, обязательная подпись лица в ответе по опасным грузам).

07Связанные сценарии

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