Ресторан теряет деньги каждый раз, когда гость бронирует столик и не приходит. SMS-сценарий из трёх сообщений — подтверждение брони, напоминание за пару часов и обработка отмены — закрывает эту проблему без участия администратора. В статье разберём, какие сообщения отправлять, когда именно, как связать сценарий с системой бронирования через API или SMPP-шлюз и каких ошибок избегать при настройке.
Зачем ресторану автоматические SMS-уведомления?
Администратор обзванивает гостей вручную — тратит 10–15 минут в час на рутину. Часть звонков уходит на автоответчик или сбрасывается. SMS доходит за секунды и не требует, чтобы человек взял трубку. Гость видит текст, когда ему удобно, и может ответить одним словом: «да» или «отмена».
Автоматизация через SMS-шлюз убирает человеческий фактор. Система сама отправляет нужное сообщение в нужный момент: сразу после оформления брони, за два часа до визита, при отмене. Администратор подключается только в нештатных ситуациях. Это особенно заметно в пятницу вечером, когда поток бронирований плотный, а персонал занят залом.
Какие сообщения входят в базовый сценарий?
Три типа SMS покрывают весь цикл бронирования. Вот как они работают на практике:
| Тип сообщения | Когда отправлять | Пример текста |
|---|---|---|
| Подтверждение брони | Сразу после оформления (до 30 секунд) | «Столик на 2 забронирован на 19:00, 22 сент. Адрес: пр-т Независимости, 48. Для отмены ответьте ОТМЕНА» |
| Напоминание | За 2–3 часа до визита | «Напоминаем: ждём вас сегодня в 19:00. Столик 7, зал у окна. Если планы изменились — ответьте ОТМЕНА» |
| Обработка отмены | Сразу после получения ответа «ОТМЕНА» | «Бронь отменена. Будем рады видеть вас в другой день. Забронировать снова: +375 29 XXX-XX-XX» |
Каждое сообщение укладывается в 160 символов латиницей или 70 кириллицей. Кириллица привычнее для гостей в Беларуси, но съедает объём вдвое быстрее. Поэтому текст нужно редактировать жёстко: убрать «уважаемый гость», «мы рады сообщить» и прочие формальности. Имя ресторана гость увидит в поле отправителя.
Как подключить сценарий к системе бронирования?
Связать систему бронирования с SMS-отправкой можно двумя путями: через HTTP API или SMPP-протокол. Для ресторана с 20–50 бронями в день API подойдёт. Настройка проще: система бронирования делает HTTP-запрос на шлюз при каждом событии, шлюз отправляет SMS и возвращает статус доставки.
Если заведение принимает сотни бронирований — сеть ресторанов или банкетная площадка — стоит смотреть в сторону SMPP. Протокол работает через постоянное соединение со шлюзом, без установки нового подключения на каждое сообщение. По данным ePochta, это заметно повышает скорость передачи SMS (ePochta SMS). Одно сообщение обрабатывается за менее чем 0,05 секунды (ssms.su). При пиковых нагрузках — например, массовой рассылке напоминаний в 17:00 — разница ощутима.
Для настройки SMPP-подключения нужны параметры: адрес сервера, порт, режим transceiver, TON/NPI и лимиты отправки. Конкретные значения зависят от поставщика шлюза. Подробнее о параметрах подключения и маршрутизации при сбоях SMPP стоит разобраться до запуска в продакшн.
Обработка входящих ответов
Гость отвечает «ОТМЕНА» — система должна это распознать. Входящее SMS попадает на шлюз, шлюз передаёт его в систему бронирования через вебхук или DLR-отчёт. Система меняет статус брони и отправляет подтверждение отмены. Весь цикл занимает 5–10 секунд. Администратор видит уже обновлённый список бронирований.
Если шлюз не поддерживает входящие SMS, можно заменить ответ ссылкой на мини-форму: «Для отмены перейдите: ...». Но текстовый ответ проще для гостя — он не переключается между приложениями.
Типичные ошибки при настройке SMS-сценария
- Напоминание за 5 минут до визита. Гость уже в пути или передумал — менять планы поздно. Оптимальное окно — 2–3 часа, чтобы человек успел отменить, а ресторан перераспределил столик.
- Длинные сообщения на кириллице. Текст больше 70 символов разбивается на два SMS. Гость получает обрывок, а ресторан платит вдвое. Проверяйте длину перед запуском.
- Нет обработки ответа «ОТМЕНА». Гость пишет ответ, но ничего не происходит. Бронь висит, столик простаивает, а человек думает, что всё отменено. Если нет технической возможности обрабатывать входящие — уберите предложение ответить из текста SMS.
- Отправка без имени отправителя. Сообщение приходит с неизвестного номера — гость принимает его за спам. Зарегистрированное имя отправителя (Sender ID) решает проблему.
- Игнорирование статусов доставки. Проблемы с доставкой SMS возникают из-за технических сбоев, фильтрации операторами, ошибок в номере (smsblog.ru). Если не отслеживать DLR-отчёты, часть гостей просто не получит напоминание — и ресторан об этом не узнает.
Как расширить сценарий за пределы бронирования?
Базовый сценарий «бронь — напоминание — отмена» работает как фундамент. Поверх него можно добавить триггерные SMS: поздравление с днём рождения постоянного гостя или напоминание тому, кто давно не заходил. Логика та же — событие в базе данных запускает отправку через шлюз. Подробнее о настройке подобных триггерных SMS по дню рождения и брошенной корзине — принципы одинаковы для ресторана и магазина.
Ещё один полезный ход — fallback на Viber. Если SMS не доставлено за 60 секунд, сообщение уходит через мессенджер. Это снижает процент потерянных уведомлений, особенно когда телефон гостя вне зоны покрытия. О том, как настроить переотправку с Viber на SMS, есть отдельный разбор.
Три шага, чтобы запустить SMS-сценарий для ресторана на этой неделе:
- Составьте тексты трёх сообщений (подтверждение, напоминание, отмена) — каждый до 70 символов кириллицей. Проверьте, что в каждом есть конкретика: время, дата, адрес.
- Выберите способ подключения — HTTP API для небольшого потока или SMPP для высокой нагрузки — и запросите тестовый доступ у поставщика шлюза. Отправьте 5–10 тестовых SMS на свои номера, проверьте статусы доставки.
- Настройте обработку входящих ответов или замените механику ответа на ссылку для отмены. Проведите тестовое бронирование от начала до конца и убедитесь, что каждое сообщение приходит вовремя.
