Agent expertise graph

Support leads already carry a mental map of who handles what. The expertise graph writes that map down from ticket history. Each edge says an agent closed tickets on a topic and the tickets stayed closed. That is the whole claim. It is not a rating of skill, and it is not a performance review.

The output feeds routing as one input among several. A ticket tagged for imaging integration can be shown the three agents with the strongest history on that topic. Queue depth, shift coverage, and seniority still apply. The graph narrows the field. It does not pick the name.

Topic quality decides graph quality. If tickets carry coarse categories, every agent looks expert in billing and nobody looks expert in anything useful. Fine-grained tags give the graph edges worth reading. That upstream work sits with consistent topic tags applied across the whole ticket corpus.

Resolution summaries are the cleanest source of edges. A structured record of problem, cause, and fix names the work an agent actually did. Graphs built from structured problem-cause-fix records at close beat graphs built from ticket subject lines.

An edge should only form when a ticket ended well. Support ops has to define that. A closed status is not enough, because tickets close for many reasons. Reopened within a week is not a success. Closed after transfer credits the wrong person.

Four rules need writing down first. Which ticket outcomes create an edge. How much of the work an agent must have done to earn credit. Whether a satisfaction score is required or optional. How far back the history window reaches.

Credit for shared tickets is the rule people skip. A ticket touched by three agents can credit all three, the last one, or the one who wrote the resolution. Each choice produces a different graph. Crediting everyone who commented turns the graph into an attendance record.

New agents start with no edges, and the graph must say so plainly. Empty is a real state. A routing rule that reads an empty profile as low skill will starve a new hire of the tickets they need. Reserve a share of each topic for agents with thin history.

The graph should also refuse to run on a thin history. A team with three months of tickets and loose tagging will produce edges that look confident and mean nothing. Wait for the volume, or start with a hand-written skill list and let the graph confirm it later.

Not every closed ticket carries the same evidence. Weight an edge by how many tickets, how recent they were, and how hard those tickets were. Ten straightforward password tickets say less than two long escalations on the same topic.

Decay matters more than most teams expect. Products change, and a strong edge from two years ago describes a version nobody runs. Let weights fall as the tickets age. An agent who stops working a topic should drift down the ranking without anyone editing a profile.

Topics connect to each other as well. An agent strong on invoice adjustments is often usable on refund disputes, because the two share a system and a set of screens. Those neighbor links let the graph suggest someone when the exact topic has no history. Keep the hop count to one. Two hops produces recommendations nobody can explain.

Every suggestion should show its evidence. Three ticket numbers under a name let a lead check the claim in a minute. A ranked list with no links behind it gets ignored the first time it is wrong. The same evidence habit helps profiles built from the language of past resolutions.

The situation below is hypothetical. A vendor sells practice management software to small animal clinics. Support runs twenty-two agents across two sites. The topic list holds sixty tags. One of them is imaging device integration. That tag covers x-ray and ultrasound units that write files into the patient record.

A clinic reports that ultrasound studies stopped attaching after a firmware update. Triage tags it imaging device integration and marks it high priority. The graph returns three names. Priya has eleven recent closes on the tag, all in the last quarter. Devin has nineteen closes, but the newest is eight months old. Sam has two closes and a strong edge on a neighboring tag for scanner drivers.

Decay puts Priya first, ahead of Devin's larger raw count. She is on shift and holds four open tickets. Routing assigns her, and the ticket page shows the three closes that earned the recommendation. Total elapsed time is under a second, and no human touched the decision.

The team lead changes it an hour later. Priya is preparing a customer call that afternoon, which the graph cannot see. The lead moves the ticket to Sam and adds Priya as a watcher. Sam closes it two days later, and that close creates his third edge on the tag. The override is how the graph learns who is growing.

The main risk is not a bad recommendation. It is a graph that freezes the team in place. Strong edges attract tickets, those tickets create stronger edges, and after six months three people own a topic that nine could handle. The loop is quiet and it runs on its own.

Cap how much of a topic any one agent can receive. A simple share limit breaks the loop without a policy debate. Watch the count of distinct agents per topic each month. When that number falls, the graph is concentrating work rather than spreading it.

Departures leave holes that look like coverage. An agent who left in March still holds the top edge on four topics until someone removes them. Tie the graph to the current roster and rebuild it on a schedule.

Training and shadowing never appear in ticket history. An agent can finish a week of certification on a module and still show a blank profile. Leads need a way to add a provisional edge by hand, marked as such, that expires if no real closes follow.

Coarse tags produce flattering nonsense. If the taxonomy has one tag for integrations, the graph will rank agents on a topic that means six different things. The fix is upstream, in the label that decides which team should look, not in the graph.

Assignment stays a management decision. The graph ranks candidates and the routing rule picks one, but a lead can reassign any ticket without justifying it. That override needs to be one action, not a form. Leads who have to explain themselves stop correcting the system.

Agents should see their own profile and challenge it. A wrong edge usually means a mistagged ticket, and the agent is the person who knows. Give them a link from the profile to the tickets behind each topic.

Keep the graph out of reviews. The moment edge counts appear in a performance conversation, agents start choosing tickets that build their profile. Cherry-picking is rational once the record is scored. Use the graph for routing and use separate measures for evaluation, such as full-coverage quality scoring on closed tickets.

Coverage planning is the lead's real use for this. Topics with one strong agent are staffing risks, and the graph names them before a resignation does. Pair a thin topic with a deliberate assignment, then check the next month. Routing that also respects queue depth and shift coverage makes those deliberate placements survivable for the rest of the queue.