Реализация AI-маршрутизации заявок (Ticket Routing) в мобильном приложении
Классификация говорит «что это», маршрутизация решает «кому это отдать». Разница принципиальная. Заявка помечена как «технический сбой» — но какому конкретно агенту или очереди она попадёт? Опытный сотрудник, агент с нужной специализацией, свободный агент в правильном часовом поясе. Без 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
}
Серверная логика маршрутизации
Сервер получает заявку с контекстом и прогоняет через routing engine. Есть два подхода:
Rules + ML гибрид
Первый фильтр — жёсткие правила. Если app_version < "3.0" и категория billing — сразу в очередь legacy-биллинга, там знают эту версию. Эти правила в кодбазе, не в модели — они меняются бизнесом, а не датасайентистом.
Второй фильтр — ML-ранжирование по свободным агентам. Используем simple multi-armed bandit или gradient boosting (LightGBM) на фичах: тема заявки, язык, рейтинг агента по похожим заявкам, текущая загруженность.
LLM-based routing
Если у вас небольшой объём и нет датасайентиста, 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.
Переназначение и эскалация
Маршрутизатор ошибается. Важно дать агенту возможность переназначить заявку и передать это событие обратно в систему — это обучающий сигнал для модели. Мобильный клиент должен показывать пользователю переназначение без перезагрузки.
Типичная ошибка: хранить assigned_agent_id только на сервере и не проталкивать обновление в мобильный клиент через push. Пользователь видит «обращение принято» и не знает, что агент уже сменился.
Процесс работы
Аудит текущих правил маршрутизации → описание очередей и критериев → реализация сбора контекста на клиенте → интеграция с серверным routing engine → real-time статус в UI → логирование переназначений для улучшения модели.
Ориентиры по срокам
Базовая маршрутизация на правилах с контекстом от клиента — 1 неделя. Гибридная схема с ML-ранжированием — 3–5 недель. Real-time WebSocket статус — 3–5 дней отдельно.