Представьте: ваше мобильное приложение обрабатывает сотни обращений в день. Каждое нужно мгновенно направить в нужный отдел — техподдержку, бухгалтерию, аккаунтинг. Без умной маршрутизации агенты тонут в хаосе, а пользователи ждут часами. Мы проектируем и внедряем AI-решения, которые анализируют метаданные заявки и за доли секунды назначают лучшего агента.
Классификация говорит «что это», маршрутизация решает «кому это отдать». Разница принципиальная. Заявка помечена как «технический сбой» — но какому конкретно агенту или очереди она попадёт? Опытный сотрудник, агент с нужной специализацией, свободный агент в правильном часовом поясе. Без AI это ручные правила в Zendesk, которые рассыпаются при масштабировании.
Как собрать контекст на мобильном клиенте?
Мобильное приложение — точка входа заявки. Маршрутизация происходит на стороне сервера, клиент только отправляет обращение с набором метаданных. Но именно от того, какие метаданные клиент соберёт и передаст, зависит качество маршрутизации. Правильный сбор контекста — половина успеха.
Минимальный набор метаданных для нормальной маршрутизации:
-
user_id+ история предыдущих обращений (загружается из кэша) -
platform(iOS/Android),app_version,os_version -
last_screen— на каком экране был пользователь перед обращением -
session_events— последние 20 действий из аналитики (Firebase AnalyticslogEvent) - Категория из классификатора (если уже реализован)
-
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-ранжирование (LightGBM) | Высокая | Высокая (обучается на данных) | Средняя | Низкая (инференс быстрый) |
| LLM (GPT-4o-mini) | Средняя | Очень высокая (zero-shot) | Низкая (без обучения) | Средняя (~$0.0001/запрос) |
Правила лучше критических сценариев, 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 → логирование переназначений для улучшения модели.
Что входит в работу
| Этап | Результат |
|---|---|
| Анализ текущей системы поддержки | Схема очередей, критерии распределения, точки сбора данных |
| Разработка клиентского SDK | Библиотека сбора метаданных для iOS/Android |
| Интеграция с серверным routing engine | REST/GraphQL эндпоинт с ML-моделью |
| Real-time статусы | WebSocket/SSE канал, UI-виджеты |
| Тестирование и отладка | A/B-тест, метрики точности и времени обработки |
| Документация и обучение команды | API-документация, дашборды мониторинга |
Ориентиры по срокам
Базовая маршрутизация на правилах с контекстом от клиента — от 5 дней. Гибридная схема с ML-ранжированием — от 3 недель. Real-time WebSocket статус — от 3 дней отдельно. Полный цикл внедрения — от 2 месяцев.
Наша команда имеет 5+ лет опыта в автоматизации поддержки, реализовано более 40 проектов по внедрению AI-маршрутизации для мобильных приложений. Чтобы узнать, как эта технология может улучшить ваше приложение, свяжитесь с нами — мы проведём бесплатный аудит текущей системы и предложим оптимальное решение.