Rarity Solutions used to have a dispatcher. One person, sitting between every incoming ticket and the tech who'd actually work it, deciding what it was, how urgent it was, and where it should go. That job doesn't exist at Rarity anymore.
Rarity Solutions is a white glove MSP serving architecture, engineering, and construction clients. The dispatcher role wasn't cut for cost reasons or restructured into something else. It was automated out, almost entirely, and nobody replaced it.
"We just had one, but his quality was lower than Thread's," says Vance, who runs Rarity. "It's usually the low man on the totem pole going through, making sure it's in the right queue, making sure it's the right work type, all these little different things. And Thread automates that. I'd say we're about 99 percent with Thread."
Dispatch was never the safe, boring part of the service desk
Every MSP has some version of dispatch, even if nobody calls it that. It's the ticket getting re-routed after the wrong category gets picked. It's the coordinator chasing down which tech should take an escalation. It's the five minutes here and three minutes there that never show up as a line item but show up everywhere else, in handle time, in SLA misses, in techs doing traffic control instead of technical work.
Rarity's AEC client base makes this worse than average. Complex environments, and end users who are engineers. "They already know how it works and they could fix it themselves, but they don't have the access," Vance says. "That's always a fun conversation with a room full of engineers."
That combination, technical complexity plus users who think they know the fix, is exactly the kind of environment where manual dispatch quietly eats a service desk alive. It's also why Rarity went looking for automation in the first place, long before "AI" was the word anyone used for it.
Going from one dispatcher to zero is the hard part
Plenty of MSPs can point to automation that trims a dispatch team down. Fewer can point to eliminating the role entirely. Vance is direct about why that gap exists: going from a few dispatchers to fewer is a tooling problem. Going from one to zero is an organizational one.
Rarity's answer was to create a coordinator role that absorbs whatever hasn't been automated yet, merging duplicate tickets, refining workflow logic, and feeding fixes back into the automated triage system. "His side quest, if you will, is to say, hey, I need this to be taken care of like this, and so we can go create the workflow," Vance explains. The coordinator doesn't do dispatch. He shrinks the amount of dispatch that's left to do, one workflow at a time, until the role disappears.
That's the part most MSPs skip. Automating the easy 80 percent of triage is straightforward. Building the internal process to keep chasing the last 1 percent, and treating what's left as your team's problem to solve rather than the software's failure to deliver, is what actually gets a service desk to zero.
New techs are productive on day one, not week three
The dispatcher story isn't the only place the labor math changed. Eighteen months ago, Vance told Thread it took 45 minutes to train a new tech on Inbox, versus four days to train the same tech on ConnectWise Manage. Asked if that still holds, his answer has sharpened rather than softened: "I think it takes longer now for them to learn the ITIL work type and ticket type than anything else, honestly, the Inbox process."
The result shows up in ticket volume almost immediately. Rarity's newest hire had four days of training total before going live on the service desk. His first day, he closed 20 tickets. The team now runs 36 to 40 tickets per tech per day, against what Vance describes as an industry baseline of 5 to 8 a few years back.
None of that is techs working faster. It's techs spending less time figuring out what to do and more time doing it, because triage, categorization, and routing already happened before the ticket hit their queue.
The margin case shows up somewhere you wouldn't expect: billing
Dispatch automation is the headline, but it's not the only place Rarity is finding money it was already owed. The team now uses Client Intelligence for billing QC, with the billing admin asking natural language questions about onboarding and offboarding tickets to catch work that never got coded or closed out.
"If you can eliminate questions on the bill, that's the first thing," Vance says. "But also it's the leakage. That's the bigger bucket most MSPs have to deal with, the leakage on internal effort, because everybody just wants to get it done and make the customer happy. Capturing that effort, that's the hardest challenge in any MSP."
It's a different buyer's problem than dispatch. Dispatch automation is a service ops story. Billing leakage is a CFO story. Rarity is running both off the same platform.
What it adds up to
Put the pieces together and you get a service desk that can absorb a serious hit without falling apart. Rarity ran at roughly 26 percent net margin before losing four major clients to acquisition this year, well above the peer group average Vance cites of 11 to 13 percent. That 26 percent figure predates this year's client losses, but the operational efficiency behind it didn't disappear when the clients did. It's part of why the business is still standing.
Rarity is now building a lower cost, automation first service tier alongside its existing white glove offering, a bet that the labor savings behind dispatch elimination can be passed on as a new pricing option rather than kept as pure margin. It hasn't closed a deal on it yet, so it's a direction, not a result. But it's the same logic playing out one level further down the P&L.
Vance's take on why any of this is worth doing isn't complicated. "If you do it right, it'll make you money. If you don't do it, you won't be competitive."
See how Thread's automated triage eliminates dispatch work on your service desk. Book a demo.
Want the full picture of how other MSPs are using Thread to change their service economics? See more success stories.