Начните с правила: чат-бот напоминает об оплате по актуальному остатку счёта, а при споре о сумме или сообщении «уже оплатили» останавливает напоминания и передаёт вопрос бухгалтеру. Для этого свяжите бота с реестром счетов, задайте условия отправки и назначьте ответственного за исключения. Ниже разберём, какие сведения нужны для такого сценария, что писать клиенту и как проверить передачу диалога сотруднику. Такой порядок подойдёт небольшой компании, которая хочет контролировать платежи без ручного просмотра каждой переписки.
Какие данные нужны боту перед отправкой напоминания?
Выберите источник, по которому бухгалтер подтверждает оплату: учётную систему или реестр, который он обновляет после проверки поступлений. Если счета ведут в 1С, интеграцию бота логично строить вокруг этих записей. Связку, в которой 1С обновляет статус оплаты, а бот отправляет напоминания, описывает материал chatbot.by об автоматической генерации и отправке счетов через 1С.
Для каждого счёта подготовьте отдельную запись. Названия клиента недостаточно: у него могут одновременно оставаться открытыми счета за разные периоды. Бот должен понимать, к какому документу относится платёж и какую сумму ещё нужно получить.
- Номер счёта и основание платежа: заказ, договор или период услуги.
- Срок оплаты и актуальный остаток в BYN.
- Статус счёта и время последней проверки поступлений.
- Рабочий канал клиента и способ получить документ.
- Ответственный сотрудник и ближайшее действие по счёту.
Разделите статусы «клиент сообщил об оплате» и «бухгалтер подтвердил оплату». Первый ставит напоминания на паузу, второй закрывает их окончательно. Если объединить эти состояния, бот либо продолжит требовать деньги после ответа клиента, либо закроет долг без проверки.
Для частичных платежей передавайте боту остаток задолженности. Исходная сумма нужна в истории счёта, но подставлять её в очередное напоминание после частичной оплаты нельзя. Перед отправкой система должна заново прочитать остаток и проверить, нет ли запрета на сообщение.
Когда отправлять сообщения и что в них писать?
Настройте цепочку вокруг событий: счёт появился, срок оплаты приближается, срок прошёл. Не запускайте одинаковую рассылку по всем открытым счетам. Клиенту, который вчера сообщил о платеже, нужен ответ бухгалтера, а клиенту без копии документа нужна ссылка на счёт.
Для разовой покупки обычно достаточно сообщения о готовности счёта и напоминания перед окончанием срока. Дополнительное обращение оставляют для отдельной ситуации, например передачи вопроса бухгалтеру. Такой подход описан в материале smsinfo.by о настройке SMS-напоминаний об оплате счёта в 2026 году; при проектировании диалога бота его можно взять за основу.
Сообщение о новом счёте: «Подготовили счёт №[номер] на [сумма] BYN. Срок оплаты — [дата]. Документ: [ссылка на счёт]. Если нужно уточнить реквизиты или состав заказа, ответьте в этом чате».
Напоминание перед сроком: «Напоминаем: срок оплаты счёта №[номер] наступает [дата]. Остаток к оплате: [остаток] BYN. Если платёж уже отправлен, выберите “Уже оплатили”, чтобы бухгалтер проверил поступление».
Обращение после срока: «По данным учёта по счёту №[номер] остаётся [остаток] BYN. Подскажите, платёж уже отправлен или нужно уточнить счёт? Передадим ответ ответственному сотруднику».
Перед последним сообщением обязательно проверьте поступления. Если обмен с учётной системой завершился с ошибкой или данные давно не обновлялись, поставьте отправку на паузу и уведомите сотрудника. Отсутствие свежего статуса не подтверждает просрочку.
Оставьте клиенту понятные варианты ответа: «Уже оплатили», «Нужна копия счёта», «Есть вопрос по сумме», «Связаться с бухгалтером». Свободный текст тоже нужен: объяснение клиента не всегда укладывается в кнопку.
Как передать спорную задолженность бухгалтеру?
Задайте признаки, при которых бот прекращает автоматическую цепочку: клиент оспаривает сумму, сообщает о платеже, просит изменить документ или указывает на расхождение по услуге. Бот фиксирует причину и создаёт задачу сотруднику. Он не решает, кто прав, и не обещает изменить сумму долга.
Сам порядок бухгалтерского контроля и работы с просроченными долгами разобран в статье на belinfoclub.by. В сценарии чат-бота этот порядок нужно перевести в конкретные статусы, задачи и условия остановки сообщений.
- Поставьте напоминания по спорному счёту на паузу.
- Уточните причину обращения, если клиент ещё её не описал.
- Передайте бухгалтеру номер счёта, остаток, текст клиента и историю последних сообщений.
- Сообщите клиенту, кто продолжит разговор, без обещания срока, который сотрудник не подтвердил.
- Возобновите цепочку только после решения ответственного.
Если клиент пишет «оплатили», бот просит дату и сумму платежа, чтобы бухгалтер смог найти поступление. Если вопрос касается объёма работ, бухгалтер подключает сотрудника, который согласовывал заказ. Ответственного лучше выбирать по причине обращения: финансовый вопрос и разногласие по услуге требуют разных действий.
Логику уточняющих вопросов можно строить по тому же принципу, что и сбор данных для расчёта сметы и передача заявки специалисту: бот собирает только сведения, которых не хватает для следующего действия. Просить клиента заново вводить номер счёта, который уже открыт в диалоге, незачем.
Задача бухгалтеру должна содержать ближайшее действие, например «проверить поступление» или «сверить сумму с договором». Одной отметки «передано» недостаточно. Пока сотрудник разбирает вопрос, бот отвечает клиенту, что обращение находится у ответственного, и не запускает прежнее требование оплаты.
Как проверить интеграцию до запуска на клиентах?
Начните с тестового счёта и пройдите весь путь от первого сообщения до подтверждения оплаты. Проверьте не только текст, но и изменения в реестре: какую запись обновляет ответ клиента, кто получает задачу и что останавливает следующую отправку.
Принцип передачи обращения в рабочую систему похож на квалификацию лидов чат-ботом и передачу в CRM: результат диалога должен попасть к сотруднику вместе с контекстом. Для контроля оплаты таким результатом будет статус счёта или задача бухгалтеру, а не новая заявка на продажу.
- После подтверждения оплаты бот больше не отправляет сообщения по этому счёту.
- После частичного платежа в тексте появляется новый остаток.
- Ответ «Есть вопрос по сумме» останавливает цепочку и создаёт задачу.
- При сбое обмена бот не отправляет сообщение о просрочке по старым данным.
- Повторное событие из учётной системы не вызывает повторную отправку.
Последний пункт проверяйте отдельно. Интеграция может повторно получить одно событие, поэтому храните отметку об отправке для конкретного счёта и этапа цепочки. Иначе клиент получит одинаковые сообщения, хотя в реестре всё выглядит правильно.
Для разработки такой автоматизации подготовьте схему: откуда бот получает статус, какие ответы принимает и кому назначает задачи. Этого достаточно, чтобы обсуждать интеграцию и API предметно. Начальный сценарий можно ограничить уведомлением о счёте, напоминанием перед сроком и передачей спорного вопроса бухгалтеру.
Типичные ошибки при настройке напоминаний
- Бот считает доставку сообщения подтверждением оплаты. Исправление: закрывайте счёт только после проверки поступления.
- Любой ответ клиента запускает следующий шаблон. Исправление: сначала определяйте причину ответа, затем выбирайте действие.
- Напоминания продолжаются во время спора. Исправление: блокируйте цепочку на уровне счёта до решения ответственного.
- Бухгалтер получает пересказ без номера документа. Исправление: передавайте карточку счёта вместе с перепиской.
- После исправления суммы бот использует старый текст. Исправление: подставляйте остаток из актуальной записи перед каждой отправкой.
За две минуты откройте один неоплаченный счёт и запишите рядом с ним условие остановки бота: «Клиент сообщил об оплате или оспорил сумму — поставить напоминания на паузу и передать бухгалтеру».
