Телеграм-бот для замовлень — це інтерфейс, який проводить покупця від вибору до підтвердженої заявки, а бізнесу передає повний і однозначний запис для виконання.
Слово «підтвердженої» відділяє робочий бот від меню з кнопками. Повідомлення «дякуємо за замовлення» ще не означає, що товар зарезервовано, оплату отримано, а менеджер бачить адресу й склад кошика. Для цього потрібен не лише діалог, а модель станів: що вже сталося, хто відповідає за наступний крок і як система поводиться, якщо відповідь або платіж не надійшли.
Життєвий цикл заявки
У хорошому сценарії людина завжди розуміє, де перебуває, а система — що дозволено робити далі. Неможливо перейти до виконання, якщо не підтверджено склад; не можна назвати замовлення оплаченим лише тому, що рахунок створено.
- ВибірПокупець обирає товар, послугу або доступний варіант без введення службових кодів.
- УточненняБот збирає тільки дані, потрібні для ціни, доставки й виконання.
- ПеревіркаЛюдина бачить склад, суму та умови й може виправити помилку до підтвердження.
- СтворенняСистема записує замовлення з унікальним ідентифікатором та початковим статусом.
- ОплатаРахунок і підтверджений платіж зберігаються як різні події.
- ВиконанняВідповідальний отримує склад, контакти, доставку та вже відомі винятки.
- ЗавершенняПокупець отримує результат або повідомлення про скасування з чітким наступним кроком.
Ця послідовність не вимагає показувати покупцеві технічні назви статусів. Вона потрібна системі. У чаті можна сказати «перевіряємо оплату», але всередині має бути зрозуміло, чи рахунок тільки сформовано, чи провайдер уже підтвердив платіж.
Повторне натискання також треба вважати нормальним сценарієм, а не помилкою користувача. Якщо людина двічі натиснула «підтвердити», бізнес не повинен отримати два однакові замовлення. Для цього кожна спроба прив’язується до вже створеного запису, доки його стан не вимагає нової операції.
Чат, Mini App і облік виконують різні ролі
Telegram дає два зручні способи побудувати інтерфейс. Кнопки в чаті підходять для короткого вибору. Mini Apps дають змогу запускати всередині Telegram окремий інтерфейс на JavaScript — корисний для каталогу, кошика й складніших форм. Але жоден із них не повинен ставати єдиним місцем зберігання замовлення.
Кнопки в чаті
- короткий асортимент або запис
- лінійний вибір без складних фільтрів
- видима історія відповідей
- швидкий перехід до оператора
Telegram Mini App
- каталог із варіантами й пошуком
- кошик із кількома позиціями
- складніша адреса або конфігурація
- власний екран перевірки замовлення
Вибирати Mini App тільки тому, що він виглядає сучасніше, не варто. Якщо замовлення складається з послуги, часу й телефона, окремий застосунок додає розробку, але не цінність. Якщо ж покупець порівнює варіанти, змінює кількість і повертається до каталогу, довгий ланцюг повідомлень стає незручним.
Де зберігати операційні дані
Історія чату корисна для людини, але погано працює як операційний реєстр. Повідомлення можна не помітити, порядок змінюється через уточнення, а команді потрібні фільтри за оплатою, доставкою й відповідальним. Тому бот передає дані в CRM, систему обліку, магазин або іншу базу, де кожне замовлення має один поточний стан.
Ця ієрархія також визначає конфлікти. Якщо чат показує стару ціну, а облікова система — нову, бот не повинен мовчки оформити суперечливе замовлення. Якщо провайдер не підтвердив платіж, повідомлення покупця зі словами «я оплатив» є приводом для перевірки, а не новим статусом.
Оплата не дорівнює кнопці «сплатити»
За документацією Telegram Payments, бот надсилає рахунок, а гроші обробляє сторонній платіжний провайдер. Telegram не бере комісію за сам Payments API, однак власні умови можуть мати провайдер і банк. Питання спорів та повернень також залишаються між покупцем, продавцем, провайдером і банками.
Практичний наслідок простий: створення рахунку, успішна оплата й повернення — різні події. Їх не можна звести до одного прапорця. Бот повинен уміти показати людині зрозумілий стан, а оператор — побачити технічне підтвердження й історію зміни.
Винятки, які слід спроєктувати до запуску
| Ситуація | Автоматична дія | Хто завершує |
|---|---|---|
| Товар закінчився | зупинити підтвердження й запропонувати вибір | оператор або покупець |
| Платіж очікується | зберегти замовлення без статусу «оплачено» | провайдер або оператор |
| Подвійне натискання | повернути вже створене замовлення | система |
| Неповна адреса | попросити конкретне відсутнє поле | покупець |
| Потрібне повернення | зафіксувати звернення й передати історію | відповідальний менеджер |
Автоматизація закінчується там, де потрібне рішення, але контекст до оператора має дійти без повторного опитування покупця.
Передача людині — не аварійний вихід із погано продуманого бота. Це окрема гілка для ситуацій, де потрібне рішення: заміна товару, нестандартна доставка, спірний платіж. Бот збирає відоме й передає його разом зі станом замовлення, щоб оператор не починав діалог заново.
Перед розробкою корисно пройти ширший чекліст чат-бота, а межу між автоматизацією та розмовою з менеджером визначити за схемою чат-бот чи жива людина.