Доставка сообщения ИИ-продавца: отправлено, получено и прочитано

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

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

Что именно подтверждает квитанция канала

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

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

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

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

Три разных вопроса за одним словом «доставлено»

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

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

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

Почему каналы отвечают по-разному

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

В обычном Telegram Bot API успешный sendMessage возвращает объект Message. Это подтверждает создание сообщения средствами API, но не является квитанцией прочтения человеком или универсальным статусом доставки на его устройство. Но даже там подтверждение доставки не равно подтверждению прочтения: бот узнаёт о событии в чате, а не о том, что человек открыл экран и прочитал текст. Набор доступных событий нужно сверять с Bot API и FAQ: обычному боту нельзя приписывать универсальное событие прочтения его сообщения. Это не недостаток конкретного продукта, а свойство канала.

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

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

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

Блокировка: когда канал честно говорит «нет»

Условный эпизод: клиент когда-то получал рассылки и нажал «Заблокировать» в мессенджере. ИИ-продавец отправляет очередное сообщение, канал возвращает ошибку о невозможности доставки. Система помечает контакт как недоступный и... останавливается. Менеджер видит красную метку, но не понимает, что делать дальше.

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

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

Недоступный канал и просроченная квитанция

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

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

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

Дубли: как отличить повтор от нового сообщения

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

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

Это не защита от всех дублей, но она закрывает большинство бытовых случаев. Важно, чтобы проверка была видимой: менеджер должен понимать, почему система спрашивает «вы уверены?», а не воспринимать это как помеху.

Ошибка вебхука: когда квитанция потерялась по дороге

Вебхук — это механизм, которым канал сообщает нам о событии. Если он настроен неправильно или сервер не ответил вовремя, квитанция теряется, хотя сообщение доставлено. Снаружи это выглядит как «статус завис», и менеджер начинает действовать наугад.

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

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

Прочитано, но нет ответа — это не отказ

Самая опасная интерпретация — считать молчание после прочтения отказом. Человек открыл сообщение, увидел его, но не ответил: занят, обдумывает, отложил. Автоматика, которая через час помечает такого клиента как «не заинтересован», отсекает живые возможности.

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

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

Квитанция конкретного сообщения: что хранить рядом с сообщением

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

Форма не обязана быть сложной. Достаточно, чтобы по каждому сообщению можно было восстановить цепочку: когда отправлено, что подтверждено, что делать дальше. Тогда спор «мы же отправили» решается за минуту, а не за час переписки.

Квитанция конкретного сообщения на экране сотрудника

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

Хорошая строка в карточке клиента выглядит так: «Сообщение отправлено 14:30, доставлено, прочтения нет. Следующий шаг: позвонить после 16:00». Здесь нет ни одного лишнего технического слова, но есть всё, что нужно для решения. Если сообщение заблокировано — «Канал закрыт клиентом, выберите другой способ связи». Если ошибка — «Не доставлено: неверный номер, проверьте контакт».

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

Как проверить свою схему статусов

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

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

Результат проверки удобно свести в короткий список: какие состояния есть, какие подтверждены, какие действия предусмотрены. Это и есть ваша карта доставки.

Практикум: разбор одного зависшего сообщения

Возьмём условный случай. Клиент жалуется, что не получил счёт, менеджер утверждает, что отправил. В системе — зелёная галочка «доставлено». Что делать?

Сначала смотрим на канал и время. Если это мессенджер и подтверждение пришло через минуту после отправки — вероятно, сообщение дошло до аккаунта, но человек мог его не открыть. Если это SMS и подтверждение пришло от оператора — сообщение дошло до устройства, но симка могла быть перевыпущена. Дальше проверяем, не было ли дублей и не менялся ли номер. Затем — не помечен ли контакт как заблокировавший канал.

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

Проверка на практике: квитанция конкретного сообщения

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

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

Часы канала и часы CRM: почему нельзя сортировать только по приходу вебхука

Представим условное сообщение, которое сервис принял в 10:00. Событие доставки относится к 10:01, но CRM получает его лишь в 10:06. За эти пять минут менеджер уже открыл карточку и увидел статус «ждём подтверждения». Если приложение сохраняет только время входящего вебхука, возникает ложная история: будто сообщение доставлялось шесть минут. Если сохраняет только время провайдера, пропадает задержка самой интеграции. Поэтому полезно держать обе отметки с явной часовой зоной: когда событие произошло в канале и когда его зарегистрировала наша система.

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

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

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