In late Q3 2024, we started working with a logistics company that operates parcel delivery across seven LATAM countries. Their support team of eleven agents was fielding roughly 25,000 tickets per month — shipment status inquiries, customs delay questions, address change requests, and the occasional escalation from a business customer who'd had a package sit in a Bogotá warehouse for eight days. Average first-response time was creeping toward three hours on a good day. Average resolution time had reached 11.2 hours. Two agents had quit in the previous quarter, citing ticket volume.
What follows is a fairly honest account of how that changed over 90 days. We're not presenting this as a marketing case study — we're writing it because the onboarding process surfaced things about multilingual queue structure that we hadn't fully anticipated, and the lessons are worth sharing.
The Baseline Problem: Not Just Volume
When we first looked at their ticket data, the volume was real but not unusual for a business at that stage. What stood out was the language distribution. Spanish accounted for about 68% of tickets, but that number masked meaningful variation: Colombian Spanish, Argentine Spanish, and Mexican Spanish were producing different vocabulary for the same underlying intents. A Colombian customer asking about a package "retenido en aduana" (held in customs) used slightly different phrasing than an Argentine customer asking about something "demorado en la aduana" — and the existing Zendesk macros weren't matching either consistently.
The remaining 32% was split between Portuguese (Brazil-routed shipments), English (business accounts), and a small but growing set of Haitian Creole tickets that were being manually translated before routing. Every Haitian Creole ticket added roughly eight minutes of handling time just to identify the correct queue.
The instinct before working with us had been to hire more agents. Two were budgeted for Q4. We argued they'd be better off spending that budget on automation tooling and retraining the existing team on complex cases — the ones automation genuinely can't handle.
Days 1–21: Taxonomy First
We don't start by routing tickets. We start by building a resolution taxonomy with the customer's own team, and this is the step that most buyers underestimate.
For this logistics company, the first two weeks involved nothing more dramatic than cataloguing ticket types: status inquiry, customs delay, address modification, delivery failure, refund request, business account billing, and a catch-all "other" bucket that turned out to contain 14% of volume. The "other" bucket is always where the interesting edge cases hide — in this case, it included a surprisingly large number of Spanish-language messages that were actually complaints forwarded from WhatsApp, a channel they weren't officially supporting but customers were using anyway.
The taxonomy work also surfaced a mismatch between how agents were categorizing tickets and how the underlying business wanted them categorized. Agents had developed informal sub-categories — "angry customs" versus "routine customs" — that weren't captured anywhere formal. We built those distinctions into the intent classification layer, because the difference mattered for tone and escalation policy.
Days 22–45: Classifier Training on Real Ticket History
With the taxonomy established, we spent the second three-week block running our language classifier against 90 days of historical ticket data. The goal was to establish a confidence baseline per intent per language variant before going live with automation.
A few things we found during this phase that required adjustment:
First, the Portuguese ticket pool was too small for robust classifier performance in isolation. Brazilian Portuguese support had only launched 14 months earlier, and the historical ticket volume didn't give us enough labeled examples for three of the seven intent categories. We handled this by expanding the training set with internally-generated synthetic examples written by a native speaker on our team — not by borrowing from a generic Portuguese corpus, which would have introduced vocabulary that didn't match the actual customer register.
Second, the "address modification" intent was being confused with "delivery failure" at a rate that would have caused problems in production. Both often contained the phrase "no recibí el paquete" (I didn't receive the package), but one was a proactive address fix and the other was a complaint post-missed delivery. The disambiguation required a secondary signal: the presence of a tracking number in a specific state in the message thread.
Third, we found that Colombian customers were nearly twice as likely as Mexican customers to include polite opening phrases in their initial message. This wasn't a linguistic curiosity — it was causing the classifier to slightly delay intent detection because the opening pleasantries occupied the first two sentences. We adjusted the feature weighting so opening social markers didn't push intent signals later in the context window to secondary importance.
Days 46–70: Live Routing with Conservative Deflection Thresholds
We went live with automation on day 46, but we didn't immediately try to deflect everything. Initial deflection threshold was set at 92% confidence — meaning any ticket where the model wasn't at least 92% confident in both the intent and the appropriate resolution would be passed to a human queue with an AI-drafted suggested response attached.
At 92% confidence, deflection rate was around 41% in the first two weeks. That's not the headline number, but it's the right starting point. A 41% deflection at high confidence is far more valuable than a 70% deflection at 75% confidence — the latter means roughly one in four automated resolutions has a meaningful error risk.
During this phase, we also ran daily review sessions with their support lead. Every morning, she would pull 20 randomly sampled automated resolutions from the previous day and score them: correct resolution, wrong tone, wrong language variant, or incorrect. This feedback loop is not optional — it's how we catch the classifier errors that don't show up in the confidence metrics.
The most common issue in weeks seven and eight was tone calibration for Argentine Spanish. The resolution templates had been written with a slightly more formal register than Argentine customers expected. The fix wasn't technical — it was rewriting six templates with a native Argentine reviewer.
Days 71–90: Pushing Toward Full Deflection Rate
By day 71, the classifier had seen enough live traffic to warrant lowering the confidence threshold. We moved to 87% on the two highest-volume intent categories (status inquiry and customs delay), while keeping the threshold at 92% for address modifications (higher risk if wrong) and leaving refund requests at 95%.
That tiered threshold approach is important. We're not saying every ticket category should be treated identically — the cost of a wrong automated resolution varies by ticket type, and the threshold should reflect that asymmetry. A wrong customs delay response wastes the customer's time. A wrong address modification can misdirect a shipment. Those aren't the same risk level.
By the end of day 90, overall deflection was sitting at 68.4%. Resolution time for deflected tickets: 2.4 hours (down from 11.2). Human-handled tickets were receiving richer context in the routing handoff — intent classification, suggested resolution, and the full conversation history — which cut the per-ticket agent handling time by about 35% even on escalations.
What Didn't Go as Planned
The Haitian Creole tickets remained a problem throughout the 90 days. Our Creole classifier performs well on standard Haitian Creole, but a significant share of these tickets were written in a French-Creole mix that reflected the sender's background rather than a single clean language. Detection was unreliable. We ended up routing all Haitian Creole tickets to a dedicated human queue with an automated translation assist — not full deflection, but meaningfully faster than the previous manual process. Full automation for that ticket type is a Q2 project.
We also underestimated the onboarding time required for the support team. Agents needed to trust the system before they'd fully use the context Queryvine surfaces during escalations. That trust built gradually, and it built through the daily review sessions more than any onboarding documentation. If we were running this again, we'd schedule more direct agent-facing time in weeks four and five specifically.
The Honest Numbers at Day 90
Deflection rate: 68.4% (target was 70%; we're comfortable calling this a near-miss on target, not a failure).
Average resolution time: 2.4 hours (down from 11.2 hours).
Human agent ticket volume: down 52% per agent per day.
Customer-reported satisfaction on automated resolutions: 4.1 / 5 average over the final two weeks.
Haitian Creole: still routed to human queue with translation assist — full automation deferred.
The two new agents they had budgeted for Q4? They weren't hired. That headcount budget was reallocated to a customer success role that handles onboarding for their business accounts — the segment where automation still needs a human hand.