Routing support tickets with Python and NLP

A routing system should shorten the journey from a support request to someone capable of handling it. Producing a queue label quickly helps only when that label advances the journey. A customer whose ticket repeatedly changes teams may see faster automation and a longer wait at the same time.

Natural language processing can classify ticket text, but its usefulness depends on the category definitions, examples and handoff process surrounding the prediction. The result proposes a destination. It does not diagnose the underlying fault or establish that the receiving team has accepted responsibility.

A keyword router with a human-triage result

The complete Python example below uses keywords, not a trained NLP model. It proposes a queue when exactly one category matches; zero matches or overlapping categories produce human triage. Save it as route_ticket.py and run it with Python 3. This gives a later model a transparent baseline to improve on.

import re

KEYWORDS = {
    "Network Team": {"network", "dns", "vpn"},
    "Security Team": {"phishing", "malware"},
    "Software Team": {"application", "software"},
    "Hardware Team": {"hardware", "battery"},
}

def propose_queue(text):
    words = set(re.findall(r"[a-z]+", text.lower()))
    matches = [team for team, keys in KEYWORDS.items() if words & keys]
    return matches[0] if len(matches) == 1 else "Human triage"

if __name__ == "__main__":
    ticket = "I'm having trouble accessing a specific website."
    print(propose_queue(ticket))

The sample prints Human triage because none of the defined keywords appears in the ticket. The same fallback handles a message whose words match more than one category. The rule is easy to inspect, but its category match is still only a proposal: keywords do not understand negation or establish operational ownership.

Consider a hypothetical report of an intermittent login failure. A classifier sends it to networking; that team's triager rejects it as an identity issue. Predicting again from the same ambiguous text can recreate the same handoff loop. A triage owner needs to obtain the missing operational detail and resolve who will investigate before another reassignment merely restarts the cycle.

The keyword baseline has an ordinary abstention path

Read diagram description

This illustrates the published example, not a production NLP classifier. Exactly one matching category proposes a queue; zero or multiple matches go to human triage. Keywords do not understand negation or establish ownership. Diagram labels: Ticket text: Tokenize and compare category keywords; Exactly one category matches: Propose that queue; Zero or multiple matches: Send to human triage.

For the login ticket, the useful measure runs until a capable team accepts the investigation. Label accuracy alone misses the repeated handoffs after the first prediction. Including that elapsed time and keeping a manual route for unresolved ambiguity shows whether classification actually shortens the customer’s wait.

Human triage also consumes capacity and can make mistakes. It is useful when additional attention can resolve uncertainty or handle a consequential case. When the same ambiguity repeatedly reflects unclear team ownership, repairing the categories and handoff process may help more than sending an increasing share of tickets to the fallback.

The first queue may differ from the team that resolved the ticket

Historical assignment data may say where tickets began rather than who ultimately resolved them. Decide which label fits the intended routing task before training. Otherwise a model can learn to reproduce the old starting queue while being judged as though it learned successful resolution ownership.

Protect customer data before reuse and remove duplicate cases across training and evaluation sets. Hold out a later period to expose changes in vocabulary and ownership. This checks whether the approach still works when the wording or team structure differs from the examples it learned.

Inspect results by queue and consequential ticket type, not only in aggregate. A rare destination that is almost never selected correctly can disappear inside a favorable overall accuracy score. Scikit-learn’s evaluation documentation covers precision, recall and confusion matrices that help make those errors visible.

Thresholds and correction after a wrong assignment

For a learned classifier, choose routing thresholds using examples outside training and the cost of a wrong destination. A score is not automatically the probability that its answer is correct. Cases below the chosen threshold need a staffed route for resolution so uncertainty does not leave the request ownerless.

Begin with suggestions a triager can review. Include correction effort, handoffs and time to capable ownership in the comparison with the keyword baseline. Severe incidents must retain their established escalation route; text classification should not silently downgrade urgency while trying to select a queue.

When teams or products change, revisit the evaluation and keep the ticket history and reason for each reassignment. That record lets the receiving team continue the investigation rather than rediscover why the earlier route failed. Customer reliability engineering connects that history with service impact.

The intermittent-login case supplies a useful end-to-end test. Does the new approach obtain the detail needed to reach an accepting team, or does it simply predict networking more quickly? A learned model has earned its additional complexity when it improves that complete journey, with its corrections and unresolved cases still visible.