NexTool Solutions

Assigning each ticket to the right technician looks trivial, yet in real service desks that manual decision becomes a bottleneck: someone has to read the queue, understand the category and dispatch - and meanwhile the SLA clock is already running. NexTool's Smart Assign module automates that step by category, applying load balancing or sequential round-robin among the technicians of the group in charge the instant the ticket is created.

The problem

An operation without automatic assignment always has a single point of decision: someone opens the queue of newly created tickets, reads category and subject and decides where to route them. That role usually falls to the coordinator or the most experienced analyst - exactly the person you least want stuck doing repetitive triage.

The practical effect shows up in two ways. First, the queue grows during peak hours because no one has picked up the ticket yet; it exists, it is open, but it still has no owner while the deadline runs. Second, the distribution gets uneven: one technician piles up fifteen tickets while another has three, not because of skill but because of who happened to be looking at the screen. Both scenarios erode the SLA and the user's perception of quality.

Smart Assign removes that middleman. As soon as the ticket is created, the module evaluates the configured rules and sets the owner before the queue is even opened by a human. Triage stops depending on who is on screen duty.

How Smart Assign works

The module hooks into GLPI's ticket creation event: existing tickets are not redistributed. Distribution is turned on per category, the technician comes from the category's group in charge, and the distribution mode, chosen in the module's Features tab, applies to the whole environment:

• Distribution by category - in each ITIL category, the Smart Assign tab turns distribution on or off and shows the group in charge, the eligible technicians and the selection criterion. Ideal for specialized teams where each area (infrastructure, ERP, networks) has its own group.
• Technicians of the group in charge - the active technicians of the category's group in charge take part, with the option to leave the group's managers out; who receives the ticket is decided by one of the two modes below.
• Balancing mode (fewest tickets) - the ticket goes to the group technician with the smallest number of open tickets at that moment. It equalizes real load, not theoretical load.
• Round-robin mode (sequential) - tickets are distributed in order, one technician after another, regardless of load. Useful when everyone has equivalent capacity and volume is not the criterion.
• Automatic adaptation - when someone joins or leaves the group, round-robin and balancing adjust on their own, with no manual reconfiguration.
• Dedicated log - every decision is stored in the database and shown in the module's Logs tab, with the reason when the ticket is not distributed, giving traceability for process audits and for investigating "why did this ticket land on me" complaints.

Smart Assign vs native business rules

GLPI already solves part of this with Business rules for tickets (Setup > Rules). They can assign by criteria such as category, but statically: they always point to the same destination. The table below shows where each approach ends:

How to enable it

1. Install the NexTool plugin in GLPI.
2. Go to Setup > NexTool > Modules.
3. Enable the Smart Assign module.
4. In the module's Features tab, choose the distribution mode (balancing or round-robin), which applies to the whole environment, and how the load is counted (by group or by category). Then, in each ITIL category, turn distribution on in the Smart Assign tab and check the group in charge.
5. Open a test ticket in the configured category and confirm the assigned technician on the ticket itself and in the module's Logs tab.

What we learned running this

In client operations we sustain, the pattern that breaks most is not a missing rule - it is the "rule that points to one person". The customer creates a native business rule sending the whole "Network" category to technician X. It works for months, until technician X goes on vacation: tickets keep being assigned to them, they sit idle, and the SLA breaches silently because the queue "had an owner". The common mistake is confusing having an owner with being handled. That is why, for groups with more than three technicians, we migrate these static rules to Smart Assign's balancing mode: instead of a fixed name, the ticket lands on whoever has the least load at that minute, and whoever goes on vacation stops receiving tickets as soon as they are removed from the group in charge or deactivated in GLPI. A detail that only shows up in operation: balancing counts open tickets, not those closed during the day, so a technician who resolves quickly starts receiving again soon - that is how you equalize real load, not the theoretical one.

The same count the module uses to decide the destination can be reproduced in the database to audit the distribution. This query lists open tickets per assigned technician, exactly the number the balancing mode minimizes when load is counted by group, the default:

SELECT u.name AS technician, COUNT(t.id) AS open_tickets
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
WHERE t.status IN (1,2,3,4)   -- new, processing, planned, pending
  AND t.is_deleted = 0
GROUP BY u.id
ORDER BY open_tickets DESC;

And every decision is recorded in the module's Logs tab, in GLPI's standard grid, with filters by level, event, ticket and technician: who received the ticket and, when it was not assigned, the reason (inactive category, category without a group in charge or group without an eligible technician). That greatly shortens the "why did this ticket come to me" investigation.

Who it is for (and when not to use it)

Smart Assign delivers clear value in:

• Teams with three or more technicians where uneven distribution is recurring.
• Service desks with volume peaks where the coordinator becomes a triage bottleneck.
• Environments with well-defined categories and teams specialized by area.
• Operations that must prove, in an audit, how tickets were distributed.

When it is not worth it: in teams of one or two technicians the gain is marginal - manual sharing costs nothing. And when assignment depends on sensitive context (VIP customer, a specific expert for a critical system), that fine routing is still better in native business rules; in that case use Smart Assign for common volume and reserve native rules for exceptions, instead of stacking both decisions on the same ticket.

Compatibility

• GLPI: 10.x and 11.x
• Plan: FREE
• Plugin: NexTool 6.10.1+
• PHP: 8.0+

Next step

Smart Assign is part of NexTool, a modular plugin for GLPI. Explore the other modules or talk to the team for a demo in your environment.

Reviewed by the NexTool Solutions team.