Оператору нужен доступ к чат-ботам в реальном времени, но не всегда под рукой компьютер. Мобильное приложение для управления ботами решает эту задачу: мониторинг диалогов, ручное вмешательство, смена сценариев — всё с телефона. Наш опыт показывает, что такая панель ускоряет реакцию на инциденты в 3 раза по сравнению с десктопным решением. Например, для сети розничных магазинов с 20 операторами мы внедрили приложение — время ответа на диалог сократилось с 45 до 15 секунд. Свяжитесь с нами, чтобы получить индивидуальный просчёт и понять, как решение впишется в вашу инфраструктуру.
Какие проблемы решаем
Human Takeover — центральная функция. Бот не справился или пользователь запросил оператора — диалог передаётся человеку. Оператор получает push, открывает чат, отвечает и возвращает управление боту. Задержка критична: если не обработать быстро, клиент уходит. Мы используем FCM high priority с data payload на Android и APNs на iOS — приложение просыпается даже в Doze. WebSocket держит соединение для мгновенного обмена сообщениями. Типичная задержка доставки push — менее 2 секунд, что подтверждается тестами на устройствах в режиме ожидания.
Управление сценариями — не все операторы должны редактировать ответы. Ролевая модель разделяет права: оператор только чат, администратор ещё и сценарии. Это снижает риск случайных ошибок в продакшене. В одном из проектов мы зафиксировали сокращение числа непреднамеренных изменений на 90% после внедрения ролей.
Мониторинг активных диалогов и статуса бота. Видно, сколько ждут оператора, сколько в работе, какие зависли. Сортировка по времени ожидания позволяет первыми обрабатывать самые критичные. Статистика: при нагрузке 500 диалогов в час среднее время обработки критических диалогов не превышает 10 секунд.
Как устроена очередь диалогов с SLA?
Очередь работает на основе RabbitMQ: при передаче диалога оператору событие публикуется в exchange, привязанный к очереди свободных операторов. Если все операторы заняты, диалог помещается в очередь ожидания, и запускается SLA-таймер. По истечении N минут (настраивается) отправляется повторное push-уведомление всем операторам. При освобождении оператора ему назначается самый «долгоожидающий» диалог. Этот механизм гарантирует, что ни один клиент не будет забыт. Для over-engineer используем подтверждение от оператора (ack), иначе диалог возвращается в очередь.
Как мы это делаем: стек и пример
Используем Swift 5.9+ (SwiftUI) для iOS, Kotlin (Jetpack Compose) для Android, Flutter 3.x для кросс-платформы. Ниже — ключевой фрагмент чата оператора на iOS:
class OperatorChatViewModel: ObservableObject { @Published var messages: [Message] = [] @Published var isConnected = false private var wsTask: URLSessionWebSocketTask? func connect(conversationId: String) { let url = URL(string: "wss://api.example.com/operator/conversations/\(conversationId)/ws")! wsTask = URLSession.shared.webSocketTask(with: url) wsTask?.resume() isConnected = true receiveNext() } private func receiveNext() { wsTask?.receive { [weak self] result in guard let self else { return } if case .success(let msg) = result, case .string(let text) = msg, let decoded = try? JSONDecoder().decode(Message.self, from: Data(text.utf8)) { DispatchQueue.main.async { self.messages.append(decoded) } } self.receiveNext() } } func send(_ text: String) { let msg = OutgoingMessage(text: text, conversationId: conversationId) let payload = try! JSONEncoder().encode(msg) wsTask?.send(.string(String(data: payload, encoding: .utf8)!)) { _ in } } func returnToBot() { Task { await conversationService.handoff(conversationId, to: .bot) } } } Очередь операторов: если несколько свободных — round robin или кто первый нажал. Если все заняты — диалог в очередь, SLA-таймер стартует. Повторный push через N минут.
Почему FCM high priority, а не обычный notification?
Обычный notification на Android не пробуждает приложение в Doze. data payload с high priority доставляется всегда. Это гарантирует, что оператор получит вызов даже на телефоне в спящем режиме. На iOS используем APNs с аналогичным приоритетом. Сравните:
| Технология | Приоритет | Поведение в Doze | Задержка типичная |
|---|---|---|---|
| FCM data + high priority | Высокий | Пробуждает | < 5 с |
| FCM notification | Норма | Не пробуждает | > 30 с |
| APNs critical alert | Критический | Пробуждает | < 2 с |
Сравнение платформ: iOS vs Android
| Параметр | iOS | Android |
|---|---|---|
| Push-сертификация | APNs через Keychain | FCM по проекту |
| Background режим | Background fetch с 30 с лимитом | Doze с окнами |
| WebSocket выживаемость | До 30 мин | До 10 мин |
| Deep linking | Universal Links | App Links |
Что входит в работу
- Список диалогов с группировкой по статусу и real-time обновлением
- Чат-экран оператора с WebSocket
- Push-уведомления о новых диалогах (FCM высокий приоритет)
- Очередь с SLA-таймером и повторными уведомлениями
- Ролевая модель (оператор / администратор)
- Управление сценариями (включение/выключение, редактирование ответов)
- Аналитика: время ответа, количество переданных диалогов, SLA-нарушения
Сроки и гарантии
Ориентировочные сроки: от 8 до 14 рабочих дней. Стоимость рассчитывается индивидуально — она зависит от числа каналов, сложности сценариев и платформ. Внедрение мобильной панели оператора окупается за 3-6 месяцев за счёт ускорения обработки диалогов и снижения нагрузки на дежурных специалистов. Мы гарантируем SLA по времени отклика push-уведомлений (не более 5 секунд) и бесперебойную работу WebSocket-соединения. За 5 лет мы реализовали более 20 проектов по управлению ботами — получите консультацию, чтобы обсудить ваши задачи и оценить экономический эффект от внедрения мобильной панели оператора.