Fixing case routing in a ticketing system

Diagnosing why work was falling through the queues, delivering new-hire IT onboarding myself, and standing up a proper dev toolkit.

A ticketing system that routes cases wrong is worse than no ticketing system, because the work disappears instead of piling up where someone can see it. This week I tracked down a routing problem that was doing exactly that.

Case routing in a tool like Salesforce is driven by queues and rules. A case lands in a queue based on criteria, and the wrong criteria send it to the wrong team, where it sits. I found cases bouncing between two queues instead of reaching the people who could act, worked out the rule that was misrouting them, fixed it, and restored access to a couple of reporting tools that had broken alongside it. The queue told the story once I knew how the rules fit together.

I also ran the new-hire IT and security overview myself for three people that week, in the training room, which was a good reminder that I can carry the teaching part of onboarding, not just the setup. And I set up a proper development toolkit on my workstation, a modern editor, PowerShell 7, and the command-line git client, and got access to the team's operational-script repository. That last part mattered more than it sounds: it was the groundwork for the onboarding automation I built the following week.

The lesson is that a misconfigured queue quietly hides work, and most of what looks like a process problem is actually a configuration problem. If you understand the routing rules, you can find the cases that are falling through, and you can fix the rule instead of apologizing for the delay.

Learn how your systems decide where work goes. Then check that they are deciding correctly. It is the same mindset as an access review, applied to the flow of tickets instead of the scope of permissions.

← All writing · Portfolio