Чат-бот для расчёта доставки в логистике

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

Когда прайс в базе знаний, он тут же устаревает

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

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

Как агент собирает параметры груза

Агент не спросит всё сразу — это отпугивает. Вместо списка он ведёт диалог: откуда везти, куда везти, какой вес. Если клиент написал только «груз в Тверь», агент спросит точный адрес, потому что именно адрес передаётся в расчёт ставки, а не просто город.

В инструкции агента для этого используется раздел о переменных. Вы описываете, какие данные нужны для расчёта — например, city_from, city_to, weight_kg, size_category — и агент следит, чтобы все переменные собрались перед вызовом функции расчёта. Если чего-то не хватает, он сам спросит. Если клиент написал вес без единиц измерения, агент уточнит, килограммы или тонны.

Порядок вопросов можно настроить так, чтобы уточнять сначала параметры, которые чаще влияют на цену. Например, вес и дальность обычно критичнее, чем цвет коробки.

Вебхук для расчёта в системе грузовщика

Когда все данные собраны, агент вызывает действие типа «Вебхук» — один из видов действий агента, рядом с отправкой уведомления или остановкой диалога. Вебхук — это просто HTTP-запрос на адрес вашей системы расчёта, например https://your-tms.local/api/calculate-rate, с параметрами в теле запроса (город откуда, куда, вес, срок).

Вебхук может быть GET или POST; какой метод использует ваша система расчёта — указываете вы. В инструкции агента прописано, что функция называется, например, calculate_delivery_rate, и что в неё нужно передать. При вызове агент подставляет собранные от клиента значения, вебхук летит на сервер, и через доли секунды возвращается ответ: ставка 1500 рублей.

Если сервер не отвечает или ошибка (например, маршрут в закрытый город), вебхук может вернуть сообщение об ошибке, и агент покажет клиенту понятный текст вместо технического кода. Например: «К сожалению, в этот регион доставка временно недоступна. Позовите менеджера».

Контроль, что расчёт действительно произошёл

Есть грань между тем, что агент рассчитал, и тем, что агент просто сказал. Контроль действий следит за этой гранью.

Представьте сценарий: агент должен вызвать вебхук расчёта, получить ставку от 1500 до 3000 рублей, и только потом предложить клиенту подтвердить. Но если в инструкции слово «рассчитаем» стоит раньше, чем вызов функции, агент может случайно написать клиенту «ставка примерно 1800 рублей» без проверки. Контроль действий это поймает: агент подтверждает выполнение действия (назвал ставку) без вызова функции — и диалог либо остановится, либо пришлёт сигнал менеджеру для страховки.

Это требует одной настройки в кабинете: включить флаг «Контроль действий» и написать, что должно произойти при нарушении. Например: «Уведомить менеджера о попытке подтверждения без расчёта».

Лимит вызовов одной функции — 10 за весь диалог. Если клиент попросил пересчитать ставку пять раз (менял маршрут, вес, срок), это в пределах лимита. Но если агент начнёт звать функцию без причины, 10-й вызов будет последний.

Документы и статусы груза в одном чате

После подтверждения заказа клиент часто пишет: а где мой груз? Агент может тут же выкинуть вебхук в вашу систему отслеживания — запросить по номеру квитанции статус из 1С, Битрикса или собственного сервиса. Функция называется, например, get_shipment_status, и в неё идёт номер, который клиент называет.

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

Таким же вебхуком можно запросить документы. Если клиент просит накладную или смету, агент вызывает функцию get_shipment_docs, получает ссылку из системы и пересылает клиенту.

Документы остаются на вашей стороне, агент только ссылается на них. Нет дублирования данных в чате, нет потери файлов.

Разовые клиенты и постоянные — две разные логики

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

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

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

Отметьте в своём расписании, когда обновлять тарифы

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

Если вы используете таблицу со скидками в самой платформе Савви, составьте расписание: каждый понедельник утром вы заходите в базу знаний, скачиваете новый файл со скидками от отдела продаж и загружаете его в агента. Триггер можно автоматизировать через рассылку внутри системы: напоминание в Telegram, чтобы не забыть.

Точно так же, если вебхук обращается в 1С или кастомный сервис, проверьте на стороне API: есть ли логирование ошибок? Если сервис долго не отвечает, агент получит таймаут и скажет клиенту, что сейчас расчёт недоступен. Это лучше, чем молчание или случайный номер.

Автор: Команда платформы Савви
Обновлено: 15 сентября 2026

Частые вопросы