Реалізація бота для збору лідів у мобільному додатку
Бот для збору лідів у мобільному контексті — це не просто форма з полями «ім'я» та «телефон». Це управлінський діалог через Telegram Bot API або власний чат-інтерфейс, який кваліфікує користувача перед передачею даних у CRM.
Як влаштований збір лідів через бота
Мобільний додаток виступає як управління інтерфейс: оператор бачить вхідні ліди, налаштовує лійку запитань, отримує сповіщення. Сам бот працює на бекенді — через Telegram Bot API webhooks або власний чат-движок.
На практиці типова архітектура виглядає так: бот на сервері (Node.js + telegraf або Python + aiogram) отримує повідомлення користувачів, веде FSM (Finite State Machine) діалогу, зберігає зібрані дані в базу, а мобільний додаток через REST/WebSocket отримує нові ліди в реальному часі.
// iOS: отримання нового ліда через WebSocket (Starscream)
socket.onEvent = { [weak self] event in
switch event {
case .text(let text):
guard let lead = try? JSONDecoder().decode(Lead.self, from: Data(text.utf8)) else { return }
DispatchQueue.main.async {
self?.viewModel.appendLead(lead)
self?.triggerHaptic(.notification(.success))
}
default: break
}
}
Форма кваліфікації — це набір запитань із розгалуженнями. Наприклад: «Який у вас бюджет?» → якщо вибрано «до 50 000 ₽», бот позначає ліда як cold і не відправляє сповіщення. Це FSM зі станами, які зберігаються на сервері в Redis per chat_id.
Карточка ліда та модель статусу
Кожен лід проходить через кілька статусів: new → in_progress → qualified / rejected. Мобільний додаток показує список з групуванням або фільтруванням за статусом — new завжди вгорі з сортуванням за часом надходження.
Детальна карточка ліда містить відповіді на запитання лійки у вигляді пар «запитання — відповідь», а не сирого логу чату. Так оператор бачить відразу: ім'я, бюджет, тип запиту — без прокручування переписки. Відповіді структуруються на бекенді при завершенні діалогу.
Призначення менеджера — PATCH /leads/{id} з {assignee_id}. При призначенні відповідальному приходить push. Якщо ліда не взято в роботу за N хвилин — повторне сповіщення або переназначення за round-robin: логіка на бекенді, мобільний додаток тільки відображає статус.
Що входить у роботу
На мобільній стороні реалізуємо:
- Список лідів з фільтруванням за статусом (новий / у роботі / закритий)
- Push-сповіщення через FCM/APNs при надходженні нового ліда
- Детальна карточка: відповіді на запитання лійки, мітка часу, джерело
- Призначення ліда менеджеру (якщо у додатку кілька операторів)
- Експорт у CSV або пряма інтеграція з amoCRM / Bitrix24 через API
Push при новому ліді — критична функція. На Android використовуємо FCM з high priority та data payload (не notification), щоб додаток отримував сповіщення навіть у фоні через FirebaseMessagingService. На iOS — APNs з content-available: 1 для silent push плюс звичайний алерт.
Терміни
Мобільна частина (список лідів, push, карточка) — 2–3 робочих дні. Якщо потрібна інтеграція з CRM — додати 1 день. Бот-частина оцінюється окремо. Вартість розраховується індивідуально після аналізу вимог.