We have encountered situations where support operators manually sort 500+ tickets a day: billing, technical issues, complaints. This is a bottleneck leading to delays and errors. Our team offers an AI solution for automatic ticket classification directly in your mobile app—on the client or on the server. Turnkey implementation with accuracy guarantee and training support. Average support budget savings after AI classification implementation is 30–50%.
How AI distributes support tickets
The classification process begins by converting the ticket text into a numerical vector using a pre-trained NLP model (e.g., bert-base-multilingual-cased). The model then computes probabilities for each category. The label with the highest probability is selected—this is the predicted category. The result can be displayed to the user or automatically route the ticket to the appropriate department.
Where classification lives: on-device or server?
The most common question is whether an on-device model is needed or a simple API call suffices. The answer depends on two things: traffic volume and latency requirements.
For most support applications, the scheme looks like this: the ticket text goes to the backend, classified via an LLM or fine-tuned BERT, and the response returns in 300–800 ms. On the mobile client, this is just a URLSession/OkHttp request. No Core ML needed.
If offline capability or minimal latency is required, then on-device. On iOS, use CoreML with a distilled model (e.g., MobileNet-class, ~10–20 MB). On Android, use TensorFlow Lite with GPU or NNAPI delegate. ROIC is achieved within 2–3 months by reducing operator workload.
How we build the classifier
Fine-tuned BERT via Hugging Face Inference API
The fastest path to production is to take bert-base-multilingual-cased or distilbert-base-multilingual-cased, fine-tune on a dataset of your historical tickets (minimum 200–300 examples per category), and deploy via Hugging Face Inference Endpoints.
The mobile client sends a POST:
// iOS
struct ClassifyRequest: Encodable {
let inputs: String
}
struct ClassifyResponse: Decodable {
let label: String
let score: Float
}
func classifyTicket(_ text: String) async throws -> ClassifyResponse {
var request = URLRequest(url: URL(string: "https://api-inference.huggingface.co/models/your-model")!)
request.httpMethod = "POST"
request.setValue("Bearer \(apiKey)", forHTTPHeaderField: "Authorization")
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
request.httpBody = try JSONEncoder().encode(ClassifyRequest(inputs: text))
let (data, _) = try await URLSession.shared.data(for: request)
return try JSONDecoder().decode([ClassifyResponse].self, from: data).first!
}
On Android, the equivalent uses Retrofit + kotlinx.serialization. Result: operator time savings of 3–5x.
On-device via CoreML (iOS)
If offline reliability is critical, we export the model as .mlpackage. Input is tokenized text, output is a probability vector over N categories.
import CoreML
import NaturalLanguage
// Tokenization via NLTokenizer + embedding
let model = try TicketClassifier(configuration: MLModelConfiguration())
let prediction = try model.prediction(
input_ids: inputIds, // MLMultiArray
attention_mask: attentionMask
)
let categoryIndex = prediction.logits.argmax() // custom extension
A nuance: NLEmbedding provides ready word embeddings without a server call, but for classification over 10+ categories, accuracy is lower than a fine-tuned model.
Text preprocessing
Before sending to the model, we always:
- Truncate to 512 tokens (BERT limit)—long texts are cut from the end, keeping the beginning where the problem description usually is
- Normalize Unicode:
text.folding(options: .diacriticInsensitive, locale: .current)—Cyrillic with yat letters or Latin letters in Russian text break the tokenizer - Remove personal data before sending to the server: card numbers, phones via regex on the client side
Fine-tuning BERT on domain data yields up to 10–20% F1 improvement over general models. — Devlin et al.
Integrating into the UI form
Classification is triggered not on 'Send' button press, but with a debounce on the input field's onChange—after a 1.5–2 second pause in typing. The user sees the suggested category and can adjust manually.
// Android, Compose
val ticketText by viewModel.ticketText.collectAsState()
val suggestedCategory by viewModel.suggestedCategory.collectAsState()
// ViewModel
private val _ticketText = MutableStateFlow("")
init {
_ticketText
.debounce(1500)
.filter { it.length > 20 }
.mapLatest { text -> classifyUseCase(text) }
.onEach { _suggestedCategory.value = it }
.launchIn(viewModelScope)
}
mapLatest cancels the previous request on new input—no net calls accumulate.
Typical mistakes
Too few categories. The "Other" category should not exceed 15% of real traffic—otherwise everything unclear falls into it and the classifier loses meaning. If "Other" > 30%, the taxonomy needs auditing.
Not logging confidence score. If score < 0.6, show the user manual selection, don't force the category. This can be seen in Firebase Crashlytics events if custom attributes are set correctly.
Model is not retrained. The classifier degrades as the product expands: new types of inquiries appear, old categories change. Set up a retraining pipeline at least once a quarter using accumulated operator corrections.
Why fine-tuned BERT over ready APIs?
Ready APIs (OpenAI, Google NLP) work 'as is'—you don't control the taxonomy and pay per request. Fine-tuned BERT on your data gives 10–20% higher F1, doesn't leak data to third parties, and inference cost (via Hugging Face Inference Endpoints) is 2–3x lower for 500+ daily requests. If offline is important, CoreML/TFLite delivers 5–10 ms per classification without network.
Process overview
| Stage | Content | Duration (range) |
|---|---|---|
| Ticket taxonomy audit | Collect historical data, identify 5–20 categories | 1–2 days |
| Training dataset annotation | Annotate 500–1000 examples per category | 2–5 days |
| Architecture selection | API vs on-device: analyze speed and security requirements | 1 day |
| Training and validation | Fine-tune BERT, test (80/20 split), achieve F1 > 0.9 | 5–8 days |
| Client integration | Code for iOS/Android, debounce, UI suggestion | 3–5 days |
| A/B test | Manual vs AI classification on 10% of traffic | 3–7 days |
| Deployment and monitoring | Launch, logging, alert on accuracy drop | 2 days |
Architecture comparison
| Criterion | Server-side (API) | On-device (CoreML/TFLite) |
|---|---|---|
| Latency | 300–800 ms | 5–10 ms |
| Offline | Requires internet | Fully offline |
| Model size | Unlimited | 10–20 MB |
| Accuracy | 90–95% (fine-tuned) | 80–90% (distilled) |
| Inference cost | Pay per request | Zero |
Deliverables included
Deliverables breakdown
- Documentation: architecture description, API specification, operator guide
- Integration code for iOS (Swift) and Android (Kotlin) with comments
- Team training: 2 online sessions on setup and maintenance
- Technical support for 1 month after deployment
- Model retraining pipeline (automation with GitHub Actions)
Timeline benchmarks
Integration with a ready classification API (OpenAI, Hugging Face) — 3–5 days. Fine-tuning own model + integration — 2–4 weeks. On-device CoreML/TFLite with model export — plus 1 week. We evaluate your project free of charge and propose an optimal plan.
How to start?
Contact us: we analyze your ticket flow, select a model, and set timelines. Our team has 5+ years in mobile development and over 20 projects with AI classification. We guarantee accuracy of at least 90% on a validation set. Order implementation and get a turnkey solution with training support. See the effectiveness: request a consultation today.