A ticket arrives in your queue: “Outlook keeps crashing on Sarah’s laptop.” Right now, a technician has to read it, look up Sarah, find her device, check for recent patches, search for known issues, categorize the ticket, and decide who should handle it. That process takes 5 to 15 minutes — and it happens dozens of times a day. The hidden cost of that triage loop is one of the biggest drags on MSP help desk efficiency.
Junto’s AI processors change the equation. When a ticket arrives, a pipeline of specialized processors runs automatically — classifying the request, pulling context from across your tool stack, enriching the ticket with relevant information, and routing it to the right person. The result: your technician opens a ticket that’s already triaged, contextualized, and ready for action.
Processors are discrete AI modules that each handle one step in the triage pipeline. Rather than one monolithic AI trying to do everything, Junto breaks triage into specialized tasks and assigns each to a purpose-built processor. This modular design means each processor can be tuned, enabled, or disabled independently based on how your MSP operates.
Think of it like an assembly line. Each processor adds something to the ticket — a classification, a piece of context, a routing decision — and passes it along. By the time the ticket reaches a technician, it’s been through every relevant processor and arrives fully enriched.
Here’s what happens when a new ticket enters Junto, step by step.
The first processor reads the ticket subject and body, then classifies it by type and category. Is this a password reset? A hardware failure? A new user onboarding request? A billing question that shouldn’t be in the tech queue at all?
Classification happens in seconds and uses the context of the ticket — not just keyword matching. “I can’t get into my email” gets classified as an access/authentication issue, not an email server problem, because the processor understands intent.
Based on the classification, client SLA tier, and the nature of the request, a priority processor assigns urgency. A password reset for a single user gets a different priority than “the entire office can’t access the file server.” This replaces the manual judgment call that technicians make — often inconsistently — on every ticket.
The processor identifies who submitted the ticket and pulls their profile from ConnectWise, Microsoft 365, and Active Directory. Now the ticket includes the user’s role, department, device assignments, license information, and contact history. A technician no longer needs to open three tools to know who they’re dealing with.
If the ticket references a device — or if the submitting user has assigned devices — the processor queries NinjaOne or your RMM to pull the current device status. Recent patch history, uptime, disk space, installed software, and any active alerts are all attached to the ticket automatically.
This is one of the highest-value processors. It searches ITGlue, Hudu, or your documentation platform for articles related to the ticket’s classification and the client’s environment. If there’s a known workaround, a client-specific configuration note, or a standard operating procedure for this type of issue, it surfaces — attached directly to the ticket rather than buried in a documentation tool the technician might not think to check.
The processor searches ConnectWise for previous tickets from the same user, device, or client that match the current issue pattern. Recurring problems become immediately visible. If Sarah’s Outlook has crashed three times in the past month, the technician sees that pattern without having to search for it.
Beyond the technical classification, a processor reads the tone of the ticket. A frustrated client writing in all caps with “URGENT” gets flagged differently than a routine request. This helps dispatchers and technicians prioritize the human element, not just the technical severity.
Based on everything the pipeline has gathered — classification, context, documentation, history — a processor drafts a suggested initial response. The technician can review, edit, and send it, or discard it entirely. The goal isn’t to auto-reply; it’s to eliminate the blank-page problem where a technician spends minutes composing what is often a templated acknowledgment.
With the ticket fully classified and enriched, the routing processor determines who should handle it. L1, L2, a specialized team, or a specific technician with expertise in this area. Routing rules combine your MSP’s configuration with the AI’s understanding of the ticket to make smart assignments — not just round-robin distribution.
Once routed, a processor attaches the relevant SLA timelines based on the client’s contract and the ticket priority. Response and resolution deadlines are calculated and tracked from the moment the ticket is created, not from when a technician first looks at it.
Not every email that creates a ticket is a real request. The catchall processor identifies automated notifications, marketing emails, and spam that shouldn’t be in the queue. It can auto-close junk tickets and flag edge cases for review, keeping your board clean without manual intervention.
After all 11 processors run — which takes seconds, not minutes — the technician opens a ticket that looks nothing like a raw email. They see:
The technician’s job shifts from researcher to decision-maker. They review the context, confirm or adjust the classification, and start working the actual problem. The 10 minutes of manual triage becomes 30 seconds of review.
The processor architecture isn’t just a technical choice — it’s an operational one. Every MSP runs differently. Some have deep ITGlue documentation; others rely on SharePoint. Some want aggressive auto-routing; others prefer manual dispatch. Some deal with heavy spam; others don’t have a catchall inbox.
Because each processor is independent, you configure what makes sense for your operation. You don’t have to adopt the entire pipeline at once, and you can tune individual processors as your team’s comfort with AI grows.
The traditional triage loop — read, research, contextualize, categorize, route — is manual, repetitive, and inconsistent. It depends on who’s working the queue and whether they know where to look. AI is transforming the MSP help desk by replacing that loop with a consistent, thorough, and instant pipeline.
The processors don’t replace the technician’s judgment. They replace the technician’s research time. Every ticket gets the same depth of triage, regardless of who’s on shift. And because the enrichment happens before a human touches the ticket, your team starts every interaction from a position of knowledge rather than a position of “let me look into that.”
That’s the difference between a queue that buries your team and a queue that empowers them.
Want to see how Junto’s processors handle your tickets? Try it on your queue and see the difference in your first hour. Check out the processor documentation for setup details.