Сначала разделите статусы, которые важны покупателю
Не выводите внутренние этапы один к одному. Составьте короткую цепочку, например: заказ принят, оплата подтверждена, заказ передан в доставку, заказ отменён. Отдельно укажите, какие события не требуют сообщения клиенту. «Заказ создан» не означает, что он оплачен; «оплачен» не сообщает, что посылка уже отправлена. Для каждого текста определите источник подтверждения и ответственного за спорный случай.
Сверяйте каждый переход с текущей записью заказа
Для пилота опишите ожидаемые переходы, например «создан → ожидает оплаты → оплачен → собирается → передан в доставку → завершён», и отдельные выходы «отменён» или «возврат проверяется». Это пример модели процесса, а не встроенные статусы SaleBot. Если интеграция прислала задержанное или повторное событие, перед отправкой сверяйте актуальный заказ с системой-источником: старый статус не должен заменять более новый. В журнале процесса храните идентификатор заказа, событие, время, уже отправленный шаблон и результат доставки. Если повтор нельзя однозначно распознать или последовательность событий не подтверждена, остановите автоматическое сообщение и передайте случай сотруднику.
Выберите событие в кабинете и проверьте его источник
В актуальной документации SaleBot для кабинета перечислены `cabinet_order_created`, `cabinet_order_paid`, `cabinet_order_stage` и `cabinet_order_cancelled`. События относятся к соответствующему модулю и поступают в схему только при включённом модуле и переключателе самого события. В настройках кабинета включайте только нужные сигналы. Эта схема относится к описанному кабинету покупателя: наличие события не подтверждает, что оно доступно для вашего внешнего магазина или подключённой службы доставки.
Не приравнивайте ручную отметку к проверке платежа
В документации SaleBot указано, что кнопка «Отметить оплаченным» в карточке заказа вызывает для клиента те же события и бонусы, что и онлайн-оплата. Поэтому `cabinet_order_paid` показывает состояние заказа внутри кабинета, но само по себе не доказывает, что платёжная система подтвердила списание. Если команда может менять статус вручную, определите, кто и по какому источнику проверяет платёж, и отдельно протестируйте этот путь. Не выдавайте товар и не обещайте возврат только на основании сообщения, которое ещё не сверено с платёжным источником.
Свяжите уведомление с правильным диалогом
Документация указывает `#{callback_order_id}` как номер заказа или заявки, к которой относится событие. Перед настройкой проверьте на тестовом заказе, какое значение появляется именно в вашем проекте и какие дополнительные поля доступны. Не подставляйте в сообщение внутренние комментарии, полные контактные данные или сведения другого заказа. Если покупатель не привязал мессенджер, документация описывает доставку текста в чат кабинета при включённом модуле «Чат»; проверьте, может ли клиент открыть этот чат.
Составьте короткие тексты для каждого события
Для `cabinet_order_created` сообщите, что заявка зарегистрирована, и назовите следующий подтверждённый шаг. Для `cabinet_order_paid` используйте формулировку об оплате только после фактического события. Для `cabinet_order_stage` переводите внутреннее значение в понятный покупателю этап, предварительно проверив варианты статусов. Для `cabinet_order_cancelled` укажите, что заказ отменён, и куда обратиться, если это произошло неожиданно. Не обещайте дату доставки, возврата средств или ответ сотрудника, если источник не гарантирует её.
Предотвратите повторные и противоречивые сообщения
Событие может прийти повторно из-за повторного действия, изменения заказа или настройки сценария. Не считайте, что сама настройка автоматически устранит дубли: определите для своего процесса, по какому номеру заказа и событию проверяется отправка, и как поступить при повторе. Отменённый заказ не должен затем получать текст «уже отправлен» из старого шага. Пройдите смену статуса вперёд, повтор события и позднее обновление; если порядок сигналов не подтверждён документацией интеграции, сверяйтесь с актуальным состоянием у ответственного.
Отделите сервисную информацию от предложений
Оставляйте в статусном сообщении только сведения о конкретном заказе и необходимый следующий шаг. Акцию или предложение новой покупки не добавляйте автоматически в каждый статусный текст: храните отдельный рекламный сценарий и отдельно проверяйте основание и согласие для его отправки по применимым правилам. Учтите системный отказ: документация SaleBot говорит, что `notSubscribed = 1` означает отписку, а сообщение клиенту не будет доставлено. Не обходите этот статус другим ботом или каналом; предусмотрите понятный способ связаться с магазином самостоятельно.
Передавайте исключение человеку вместе с контекстом
Направляйте сотруднику случай, когда оплата не совпадает с заказом, статус доставки неизвестен, произошла отмена после передачи перевозчику, событие пришло без номера или клиент оспаривает информацию. Зафиксируйте номер заказа, последнее подтверждённое событие, время проверки и уже отправленный текст. Официальная инструкция SaleBot показывает автоматизацию события с сообщением клиенту и задачей сотруднику; настройку и доступность проверьте в своём проекте. Пока идёт разбор, не запускайте цепочку, которая может сообщить клиенту обратное.
Проверьте сценарий перед запуском
Используйте тестовые заказы и реальные каналы проекта: создание без оплаты, подтверждённая оплата, переход к доставке, отмена, повтор одного события, неизвестный статус, отписка, непривязанный мессенджер и ручное исправление заказа. Для каждого случая запишите ожидаемый текст, получателя, число сообщений и очередь сотрудника. Проверьте отдельно Telegram, ВКонтакте и чат кабинета, если он предусмотрен. В пилоте считайте дубли, недоставленные сообщения и ручные эскалации; эти показатели описывают качество процесса, но сами по себе не доказывают рост продаж.
Вопросы и ответы
Какие события заказа описаны для кабинета SaleBot?
В документации перечислены создание заказа, оплата, смена этапа доставки и отмена: `cabinet_order_created`, `cabinet_order_paid`, `cabinet_order_stage` и `cabinet_order_cancelled`. Они требуют включённых модуля и переключателя события.
Подтверждает ли `cabinet_order_paid` фактическое списание денег?
Не обязательно. Документация SaleBot говорит, что ручная кнопка «Отметить оплаченным» тоже вызывает событие оплаты. Проверьте статус у платёжного источника и определите, кто вправе ставить ручную отметку.
Куда придёт сообщение, если мессенджер не привязан?
Для описанного кабинета SaleBot указывает чат кабинета при включённом модуле «Чат». Проверьте, что клиенту доступен этот путь; иначе не считайте сообщение доставленным.
Как не отправить клиенту статус оплаты до подтверждения?
Запускайте текст об оплате только от события фактического подтверждения и проверьте путь без оплаты. Не используйте создание заказа как синоним успешного платежа.
Можно ли добавить скидку в каждое уведомление?
Лучше оставить статусное сообщение операционным, а рекламные предложения вести отдельно с собственной проверкой правил и согласия. Учитывайте статус отписки; он не должен обходиться другим каналом.