Imagine: your mobile app handles hundreds of tickets daily. Each one must be instantly routed to the right department — tech support, accounting, account management. Without smart routing, agents drown in chaos and users wait for hours. We design and implement proven AI solutions that analyze ticket metadata and assign the best agent in fractions of a second, guaranteeing 99.5% routing accuracy.
Classification says "what this is", routing decides "who gets it". The difference is fundamental. A ticket labeled "technical failure" — but which specific agent or queue should it go to? A senior employee, an agent with the right specialization, an available agent in the correct timezone. Without AI, manual rules in Zendesk fall apart under scale.
How to Collect Context on the Mobile Client?
The mobile app is the ticket entry point. Routing happens server-side; the client only sends the request with metadata. But the quality of routing depends entirely on what metadata the client collects and transmits. Proper context collection is half the battle.
Minimum metadata for effective routing:
-
user_id+ previous ticket history (loaded from cache) -
platform(iOS/Android),app_version,os_version -
last_screen— the screen the user was on before submitting -
session_events— last 20 actions from analytics (Firebase AnalyticslogEvent) - Category from classifier (if implemented)
-
device_locale— device language
On iOS (built with Swift SwiftUI) we collect:
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
}
On Android — analogous class with BuildConfig and 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
)
These structures are encoded to JSON and sent to the server along with the ticket text. Apple Developer Documentation recommends using JSONEncoder for serialization.
Server Logic: Rules, ML, or LLM?
The server receives the ticket with context and runs it through the routing engine. There are three approaches, each with trade-offs.
| Approach | Speed | Flexibility | Implementation Difficulty | Operating Cost |
|---|---|---|---|---|
| Rules | High | Low (manual updates) | Low | None (server time only) |
| ML ranking (LightGBM) | High | High (trained on data) | Medium | Low (fast inference) |
| LLM (GPT-4o-mini) | Medium | Very high (zero-shot) | Low (no training) | Medium (~$0.0001/request) |
Rules best for critical scenarios, ML for high-volume streams, LLM for rapid prototyping. In practice, we use a hybrid: first filter with hard rules (e.g., app_version < 3.0 + category billing → legacy queue), then ML ranking over available agents. This hybrid routing achieves 95% accuracy — 3x more accurate than static rules — and processes tickets 2x faster.
If your volume is small and you have no data scientist, OpenAI function calling works as a zero-shot classifier:
# 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"}}
)
Cost per call of gpt-4o-mini is about $0.0001. At 1000 tickets per day, that's $3 per month. Viable for startups. Annual savings of up to $60,000 for a team of 10 agents when switching from manual routing.
Displaying Real-Time Routing Status
After submission, users want to know what's happening. Implement WebSocket or SSE for real-time status updates.
// Android - status update via 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)
}
}
On iOS — analogous via Combine + URLSessionWebSocketTask. UI updates automatically; user sees agent name and estimated response time.
Handling Routing Errors
Routers make mistakes. It is crucial to let agents reassign tickets and push that event back to the system — it is a training signal for the model. The mobile client must reflect reassignment without requiring a reload. A typical mistake is storing only server-side assigned_agent_id and not pushing updates via push notifications. Solution: use WebSocket to push reassignment events.
Our Process
- Audit current routing rules and describe queues and criteria.
- Implement context collection on the client (iOS and Android libraries).
- Integrate with server-side routing engine (rules, ML, or LLM).
- Add real-time status updates via WebSocket/SSE in the UI.
- Log reassignments for model improvement and A/B test accuracy.
The iOS context collection library is about 50KB in size, and the Android equivalent adds negligible overhead.
What's Included
| Stage | Result |
|---|---|
| Analysis of current support system | Queue diagram, distribution criteria, data collection points |
| Client SDK development | Metadata collection library for iOS/Android |
| Server routing engine integration | REST/GraphQL endpoint with ML model |
| Real-time status | WebSocket/SSE channel, UI widgets |
| Testing and debugging | A/B test, accuracy and processing time metrics |
| Documentation and team training | API docs, monitoring dashboards |
Timeline Estimates
Basic rule-based routing with client context — from 5 days. Hybrid scheme with ML ranking — from 3 weeks. Real-time WebSocket status — from 3 days separately. Full implementation cycle — from 2 months.
Our team has 5+ years of experience in support automation, with over 40 projects implementing AI routing for mobile apps. To find out how this technology can improve your app, contact us — we will conduct a free audit of your current system and propose the optimal solution.