It depends what you count

I was designing how our support desk shares out new tickets. The old round robin did not work, so we needed something fair: each new ticket goes to someone, and over a day the load evens out.

Claude’s first proposal sounded sensible. Give the next ticket to whoever has the fewest open tickets.

Who that rewards

Think about who has the fewest open tickets at any moment. It is the person who closes them fastest. Under that rule, the most efficient person on the team keeps getting the next ticket, and the next, because they always look free. Someone who works slowly, or lets tickets sit, looks busy and gets fewer. The rule rewards exactly the behaviour you do not want.

We switched to counting tickets assigned during a shift, not tickets still open. Everyone on shift gets their turn, however quickly they clear them. Being fast no longer earns you more work, and being slow no longer earns you less.

Then I added shifts properly: routing only considers people who are actually on shift, and shifts stay fixed until a team lead changes them.

The same idea, applied to data

The same question, what are you actually counting, came up again when we planned bringing years of support history across from our old tool.

Claude asked which customer list it should match tickets against. I pointed out that it could not know our customers at all: they only exist in production. So the design became: clean and prepare the data locally, then match on the server.

When we did look at real production data, through a read-only export I ran myself, the counts held surprises. No customer had any approved email domains configured, which meant a live verification check had probably been failing quietly. One support mailbox pointed to a customer that did not exist under that name. None of this was visible until we counted.

And the clean-up itself became a counting decision. Reviewing unmatched tickets one by one would have meant thousands of decisions. Reviewing them by brand and by email domain turned it into about a hundred.

The lesson

Fairness, quality and effort all depend on the unit you choose. Count open tickets and you punish speed. Review per ticket and a clean-up takes a month; review per domain and it takes an afternoon. Before designing the rule, ask what it counts, and who that rewards.