Начните с проверки одного события на тестовом заказе и оставьте отправку клиентам выключенной. Чтобы принять SMS-интеграцию после разработки с помощью ИИ, проверьте условия запуска, защиту от дублей, обработку ошибок и фактическую доставку на свой телефон. Ответ API ещё не подтверждает получение сообщения. Ниже — порядок приёмки для бизнеса в Беларуси: какие доказательства запросить у разработчика, как провести контрольную отправку и при каких результатах оставить интеграцию в тестовом режиме.
Что зафиксировать до проверки SMS-интеграции?
Выберите событие, которое сайт уже распознаёт: например, сотрудник переводит заказ в статус «Готов к выдаче». Для приёмки нужна чёткая граница отправки. Если сотрудник затем исправит комментарий и снова сохранит заказ, новое SMS уходить не должно.
Запишите сценарий в короткую карточку. По ней предприниматель проверит поведение сайта, а разработчик подготовит тесты:
- Событие: заказ впервые получил статус «Готов к выдаче».
- Условие: уведомление для этого события ещё не запускалось.
- Текст: согласованный шаблон с номером заказа и понятным действием для покупателя.
- Результат: сотрудник видит, принял ли SMS-сервис запрос и появился ли отчёт о доставке.
- Остановка: отдельная настройка отключает отправку без правок кода.
Если уведомление запускает облачная CRM, отдельно укажите событие вебхука — автоматического запроса из CRM в ваш сервис. Например, вебхук на новую бронь передаёт серверу повод отправить SMS. Такой способ подключения описан в материале об интеграции SMS с облачной CRM (messages.by). При проверке повторите тот же вебхук и убедитесь, что второй запрос не создаёт дубль.
Общий путь от задания модели до проверки результата разобран в статье на tit.by. Для приёмки подготовьте собственную карточку: с названием события, вашим шаблоном и ожидаемым статусом в интерфейсе.
Какие доказательства запросить у разработчика или ИИ?
Попросите показать, откуда приложение запускает отправку и какой серверный модуль обращается к SMS-сервису. Реквизиты доступа должны оставаться на сервере. Если браузер сам отправляет запрос с рабочим паролем, интеграция требует исправления до реального теста.
Дайте разработчику конкретное задание: «Покажи точку запуска SMS, способ защиты от повторной отправки и команды проверки. Приложи фактический вывод тестов. Отдельно перечисли проверки, которые ещё предстоит выполнить вручную». Ответ модели «готово, всё работает» без результатов запуска не подтверждает работоспособность.
Сверьте запрос с актуальной документацией провайдера. Здесь есть деталь, которую легко пропустить: JSON в ответе сервиса ничего не говорит о формате входящего запроса. API может принимать поля формы. Пусть разработчик покажет соответствие метода, названий полей и формата запроса документации.
Для защиты от дублей попросите проверить одновременную обработку одного события. Блокировка кнопки в интерфейсе этого не решает: запросы могут прийти повторно или параллельно. Сервер должен закреплять право на отправку за одним обработчиком, например через уникальную запись события в базе.
Такую приёмку можно оформить отдельной задачей по подключению уведомлений. Её результат — серверная интеграция, настройки запуска, журнал событий и инструкция для сотрудника. Для дальнейшей аналитики сразу договоритесь, где смотреть принятые запросы, ошибки и отчёты о доставке.
Как проверить ошибки без реальной отправки SMS?
Включите тестовый режим, в котором приложение получает заранее заданные ответы вместо обращения к SMS-сервису. Попросите показать в журнале, что внешний запрос действительно не ушёл. Затем выполните проверки по порядку:
- Верните успешный ответ с идентификатором сообщения. Интерфейс должен показать, что сервис принял запрос, без отметки о подтверждённой доставке.
- Верните отказ сервиса. Проверьте, что сотрудник видит причину, а приложение не запускает бесконечные повторы.
- Сымитируйте отсутствие ответа. Система должна сохранить неопределённый результат и не отправлять сообщение заново вслепую.
- Повторно сохраните заказ с тем же статусом. Новое уведомление появляться не должно.
- Запустите обработку одного события одновременно. В журнале должна остаться одна попытка обращения к провайдеру.
Тайм-аут требует отдельного внимания. Приложение перестало ждать ответ, но сервис уже мог принять сообщение. Разработчику нужно согласовать дальнейшее действие с возможностями API: проверить состояние запроса или использовать предусмотренную провайдером защиту повторов. Пока результат неизвестен, автоматическая повторная отправка создаёт риск дубля.
После этих проверок отключите отправку общей настройкой и снова измените статус тестового заказа. Событие должно сохраниться, а обращение к провайдеру — отсутствовать. Так сотрудник сможет остановить уведомления при сбое без ожидания новой версии сайта.
Как провести контрольную отправку и оценить результат?
Разрешите реальные отправки только на свои тестовые номера и запустите тот же сценарий через сайт. Ручная отправка из кабинета SMS-сервиса проверяет лишь часть цепочки: она обходит событие заказа и серверный код интеграции.
Перед массовой рассылкой нужно проверить весь маршрут сообщения: API или SMPP-соединение, имя отправителя и статусы обработки (smpp.by). Для вашей проверки это означает пройти путь от смены статуса заказа до SMS на телефоне. Не меняйте одновременно текст, способ подключения и условие запуска, иначе причину ошибки будет сложнее найти.
Начните с короткого сообщения без ссылки, затем отправьте рабочий шаблон. Такой порядок контрольных отправок предлагают в чек-листе недоставки SMS (mobizon.by). Если результаты различаются, сохраните оба текста и соответствующие записи журнала для разбора.
Для каждой попытки запишите событие, время запуска, идентификатор сообщения и ответ сервиса. Отдельно отметьте фактическое получение на телефоне. Таблица с событием, текстом, тестовым номером и ожидаемым результатом помогает сверять такие проверки; этот подход описан в материале о работе малого бизнеса с SMS в Беларуси (smska.by).
Проверьте окончательный текст после подстановки номера заказа или времени записи. Переменные меняют длину сообщения, поэтому перед запуском пригодится проверка числа SMS-сегментов. Сохраните тот вариант, который реально получил телефон, включая имя отправителя и ссылку, если она предусмотрена.
Отчёт о доставке и реакция покупателя — разные результаты. Если провайдер передаёт статус доставки, покажите его отдельно от принятия запроса. Факт получения SMS сам по себе не подтверждает, что клиент прочитал текст или выполнил действие.
Типичные ошибки: что исправить перед запуском?
- Рабочие реквизиты видны в браузере. Перенесите запрос к SMS-сервису на сервер; если секрет раскрылся посторонним, замените его.
- Интерфейс сразу пишет «Доставлено». Разделите статусы принятия запроса и доставки по данным провайдера.
- Любой сетевой сбой вызывает повтор. Добавьте статус неопределённого результата и проверку состояния перед новой попыткой.
- Один заказ запускает отправку из разных обработчиков. Оставьте одну точку запуска и повторите тест одновременных запросов.
- Проверили только пример без переменных. Прогоните рабочий шаблон с реальными по формату значениями и прочитайте сообщение на телефоне.
Переходить к отправкам клиентам стоит после того, как тестовое событие создаёт одно уведомление, ошибки видны сотруднику, а отключение отправки работает. Сохраните карточку сценария и результаты проверок: они понадобятся после изменения сайта или шаблона. Только затем добавляйте другие задачи, например SMS-напоминания о повторной покупке, с отдельными условиями запуска.
Сейчас за две минуты запишите один критерий приёмки: «Повторное сохранение заказа в статусе “Готов к выдаче” не отправляет второе SMS».
