Lead Generation Bot Implementation in Mobile Applications
A lead generation bot in mobile context is not just a form with "name" and "phone" fields. It's a managed dialogue through Telegram Bot API or a custom chat interface that qualifies users before passing their data to a CRM system.
How Lead Collection Through Bots Works
A mobile application serves as the management interface: operators see incoming leads, configure the question funnel, and receive notifications. The bot itself runs on the backend through Telegram Bot API webhooks or a custom chat engine.
In practice, the typical architecture looks like this: a bot on the server (Node.js + telegraf or Python + aiogram) receives user messages, conducts FSM (Finite State Machine) dialogue, stores collected data in a database, and the mobile application receives new leads in real-time through REST/WebSocket.
// iOS: receiving a new lead through 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
}
}
The qualification form is a set of branching questions. For example: "What is your budget?" → if "up to 50,000 rubles" is selected, the bot marks the lead as cold and doesn't send a notification. This is an FSM with states stored on the server in Redis per chat_id.
Lead Card and Status Model
Each lead goes through multiple statuses: new → in_progress → qualified / rejected. The mobile application displays a list with filtering or grouping by status — new always appears at the top, sorted by arrival time.
The detailed lead card contains answers to the funnel questions as question-answer pairs, not raw chat logs. This way the operator immediately sees: name, budget, request type — without scrolling through messages. Answers are structured on the backend when the dialogue is completed.
Assigning a manager happens through PATCH /leads/{id} with {assignee_id}. The responsible person receives a push notification upon assignment. If a lead isn't picked up for N minutes — repeated notification or round-robin reassignment: this logic runs on the backend, the mobile application only displays the status.
What's Included in the Work
On the mobile side we implement:
- Lead list with status filtering (new / in progress / closed)
- Push notifications through FCM/APNs when a new lead arrives
- Detailed card: answers to funnel questions, timestamp, source
- Assigning a lead to a manager (if there are multiple operators in the application)
- Export to CSV or direct integration with amoCRM / Bitrix24 through API
Push notifications for new leads are a critical function. On Android we use FCM with high priority and data payload (not notification), so the application receives notifications even in the background through FirebaseMessagingService. On iOS — APNs with content-available: 1 for silent push plus a regular alert.
Timeline
Mobile component (lead list, push, card) — 2–3 business days. If CRM integration is needed — add 1 day. The bot component is estimated separately. Pricing is calculated individually after requirements analysis.