AI-маршрутизация заявок в мобильном приложении

Представьте: ваше мобильное приложение обрабатывает сотни обращений в день. Каждое нужно мгновенно направить в нужный отдел — техподдержку, бухгалтерию, аккаунтинг. Без умной маршрутизации агенты тонут в хаосе, а пользователи ждут часами. Мы проектируем и внедряем AI-решения, которые анализируют метаданные заявки и за доли секунды назначают лучшего агента.

Классификация говорит «что это», маршрутизация решает «кому это отдать». Разница принципиальная. Заявка помечена как «технический сбой» — но какому конкретно агенту или очереди она попадёт? Опытный сотрудник, агент с нужной специализацией, свободный агент в правильном часовом поясе. Без AI это ручные правила в Zendesk, которые рассыпаются при масштабировании.

Как собрать контекст на мобильном клиенте?

Мобильное приложение — точка входа заявки. Маршрутизация происходит на стороне сервера, клиент только отправляет обращение с набором метаданных. Но именно от того, какие метаданные клиент соберёт и передаст, зависит качество маршрутизации. Правильный сбор контекста — половина успеха.

Минимальный набор метаданных для нормальной маршрутизации:

• user_id + история предыдущих обращений (загружается из кэша)
• platform (iOS/Android), app_version, os_version
• last_screen — на каком экране был пользователь перед обращением
• session_events — последние 20 действий из аналитики (Firebase Analytics logEvent)
• Категория из классификатора (если уже реализован)
• device_locale — язык устройства

На iOS собираем:

struct TicketContext: Encodable { let userId: String let platform = "ios" let appVersion: String = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? "" let osVersion: String = UIDevice.current.systemVersion let lastScreen: String let sessionEvents: [String] let locale: String = Locale.current.identifier let previousTicketsCount: Int } 

На Android — аналогичный класс с BuildConfig и Build.VERSION:

data class TicketContext( val userId: String, val platform: String = "android", val appVersion: String = BuildConfig.VERSION_NAME, val osVersion: String = Build.VERSION.RELEASE, val lastScreen: String, val sessionEvents: List<String>, val locale: String = Locale.getDefault().toLanguageTag(), val previousTicketsCount: Int ) 

Эти структуры кодируются в JSON и отправляются на сервер вместе с текстом обращения. Apple Developer Documentation рекомендует использовать JSONEncoder для сериализации.

Серверная логика: правила, ML или LLM?

Сервер получает заявку с контекстом и прогоняет через routing engine. Есть три подхода, каждый со своими компромиссами.

Правила лучше критических сценариев, ML — для массовых потоков, LLM — для быстрого прототипирования. На практике мы используем гибрид: первый фильтр — жёсткие правила (например, app_version < 3.0 и категория billing — сразу в legacy-очередь), затем ML-ранжирование по свободным агентам. Так достигается 95% точности и устойчивость к изменениям.

Если у вас небольшой объём и нет датасайентиста, OpenAI function calling справится как zero-shot классификатор:

# Backend (Python) routing_response = openai.chat.completions.create( model="gpt-4o-mini", messages=[{ "role": "system", "content": f"Available queues: {json.dumps(queue_descriptions)}. Route the ticket." }, { "role": "user", "content": ticket_text }], tools=[route_ticket_tool], tool_choice={"type": "function", "function": {"name": "route_ticket"}} ) 

Стоимость одного вызова gpt-4o-mini — около $0.0001. При 1000 заявок в день это $3 в месяц. Для старта вполне.

Отображение статуса маршрутизации в реальном времени

После отправки пользователь хочет знать, что происходит. Реализуем WebSocket или SSE для real-time обновления статуса.

// Android - обновление статуса через StateFlow class TicketStatusViewModel : ViewModel() { private val _status = MutableStateFlow<TicketStatus>(TicketStatus.Sent) val status = _status.asStateFlow() fun observeTicket(ticketId: String) { webSocketManager.observe(ticketId) .onEach { event -> when (event) { is TicketEvent.Routed -> _status.value = TicketStatus.Routed(event.agentName, event.estimatedTime) is TicketEvent.AgentAssigned -> _status.value = TicketStatus.InProgress(event.agentName) is TicketEvent.Resolved -> _status.value = TicketStatus.Resolved } } .launchIn(viewModelScope) } } 

На iOS — аналог через Combine + URLSessionWebSocketTask. UI обновляется автоматически, пользователь видит имя агента и примерное время ответа.

Что делать при ошибках маршрутизации?

Маршрутизатор ошибается. Важно дать агенту возможность переназначить заявку и передать это событие обратно в систему — это обучающий сигнал для модели. Мобильный клиент должен показывать пользователю переназначение без перезагрузки.

Типичная ошибка: хранить assigned_agent_id только на сервере и не проталкивать обновление в мобильный клиент через push. Пользователь видит «обращение принято» и не знает, что агент уже сменился. Решение — использовать WebSocket для отправки события переназначения.

Процесс работы

Аудит текущих правил маршрутизации → описание очередей и критериев → реализация сбора контекста на клиенте → интеграция с серверным routing engine → real-time статус в UI → логирование переназначений для улучшения модели.

Что входит в работу

Ориентиры по срокам

Базовая маршрутизация на правилах с контекстом от клиента — от 5 дней. Гибридная схема с ML-ранжированием — от 3 недель. Real-time WebSocket статус — от 3 дней отдельно. Полный цикл внедрения — от 2 месяцев.

Наша команда имеет 5+ лет опыта в автоматизации поддержки, реализовано более 40 проектов по внедрению AI-маршрутизации для мобильных приложений. Чтобы узнать, как эта технология может улучшить ваше приложение, свяжитесь с нами — мы проведём бесплатный аудит текущей системы и предложим оптимальное решение.