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-маршрутизации для мобильных приложений. Чтобы узнать, как эта технология может улучшить ваше приложение, свяжитесь с нами — мы проведём аудит текущей системы и предложим оптимальное решение.