Реалізація 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 днів окремо.