SMS вимкнено за замовчуванням — і черга не збирається
Усі вихідні повідомлення спершу записуються, і лише потім хтось їх надсилає. Сервіс сперечається з клієнтами «ви мені не повідомляли», тож збережений текст і час — це доказ. Але доказ чого саме?
Як було
Поки шлюз не налаштований, система писала в аутбокс усе, що надіслала б, зі статусом «пропущено». Задум був симпатичний: видно, що саме пішло б клієнту, ще до того як платити за перше SMS.
На практиці вийшов список, який росте місяцями. Не доказ, а те, що згодом треба комусь пояснювати: «ні, це не надіслані повідомлення, це…».
Як стало
Поки шлюз не ввімкнено — не пишеться нічого. Аутбокс існує, щоб довести, що сервіс сказав клієнту. Сервіс без шлюзу не сказав нікому нічого. А те, що клієнт отримав би, видно там, де це справді потрібно: у підтвердженні, яке приймальник бачить перед зміною статусу.
Умова — обидва вимикачі: платформи і власний шлюз організації.
Три межі, які варто знати
Нагадування все одно штампуються
Завдання, час якого настав при вимкненому шлюзі, помічається як «нагадано», хоча SMS не пішла. Інакше в момент увімкнення шлюзу полетіла б купа простроченої давнини людям, яких це вже не цікавить. Нагадування всередині системи — список і бейдж — рахується з дат і жодного рядка не потребує.
Клієнт без телефону — навпаки
Тут рядок пишеться, зі причиною «немає адреси». Цей сервіс писати вміє і саме в цьому замовленні не мав куди. Це відповідь на питання «чому клієнту нічого не прийшло», а не сміття.
Інтерфейс не питає про те, чого не буде
Діалог «надіслати SMS?» показується лише коли надіслати справді є чим. Питання, відповідь на яке ні на що не впливає, гірше за його відсутність.
Шлюз належить вашій організації: свій договір, своє альфа-імʼя, свій рахунок. Один ключ на всіх означав би повідомлення одного сервісу під підписом іншого.