The Remote Access Use Case Nobody's Talking About

There's a version of remote access that every IT team knows: something breaks, you connect, you fix it. It's reactive, it's necessary, and it's what every remote access vendor leads with.

Bob Parsons leads IT at Ghost Robotics, a defense contractor building some of the most advanced autonomous systems in the world. His team is distributed: engineers working globally, often in the field, often far from HQ. When Bob started using Rippling's remote access, he expected to get faster at the reactive piece. What he didn't expect was that his team would figure out how to eliminate the tickets before they ever got filed.

Ticket volume in one category dropped by 35 to 45 percent. Not resolution time. Volume.

Here's what they did differently.

The problem with how IT thinks about tickets

Most IT teams manage tickets like a queue. The goal is to keep it short: respond fast, resolve fast, and then close the ticket. The better your remote access tool, the faster you can move through the queue.

But there's a more interesting question: why does the queue refill?

For Bob, a big chunk of recurring tickets came from one source: a major platform migration. Ghost Robotics had moved entirely from Google Workspace to Microsoft 365 GCC High, a government-compliant tenant with significantly tighter permissions and a completely different workflow logic than Google Drive. For engineers who had spent years in Google's environment, almost everything about how files, sharing permissions, and collaborative workflows operated was now different.

The tickets weren't the result of a broken system. The system was working exactly as designed. The tickets were the result of a learning curve that never quite resolved, because the way the learning was happening was not actually sticking.

What "hand over hand" actually looks like

Bob started doing something that he described, a little sheepishly, as unconventional: one-on-one training sessions using remote access as the delivery mechanism.

The format is straightforward. Bob opens a remote session on the employee's machine. He demonstrates the workflow: exactly the steps, exactly the interface, exactly what a correctly-configured SharePoint permission looks like versus what an incorrectly-configured one looks like. Then he resets it. Then the employee walks through the same steps while Bob watches. If they make a mistake, Bob can see it in real time and course-correct without anyone having to describe what they're looking at.

Bob called it "hand over hand." The concept isn't new. It's how good in-person training has always worked. What's new is being able to do it with an engineer who's in a different time zone, on a different device, in a field environment, without anyone having to travel or schedule a video call where screen sharing reliability is always fifty-fifty.

Why this works when other formats don't

Group training sessions have an obvious efficiency argument: cover the same ground with ten people instead of one. But in practice, group sessions have a passive audience problem. Someone is always multitasking. Someone zones out when the scenario doesn't apply to their specific workflow. The knowledge transfer rate is lower than it appears.

Recorded training videos are worse. They're watched once, filed away, and forgotten by the time the actual problem shows up. Nobody rewinds a video when they're stuck in the moment. They file a ticket.

A one-on-one remote session eliminates the passivity problem. The employee has to do the thing. Bob can see whether they understand or are just following steps mechanically. And crucially, the session happens at the moment that the problem is actually present, which is the highest-motivation learning moment there is.

The quality of the remote connection matters here. A laggy, low-resolution session that drops out defeats the purpose. The value of the format is immediacy: the ability to show something in real time, pause, redirect, and confirm the employee got it. That requires a session that behaves like you're sitting next to them.

The capacity argument

For a one-person or small IT team, every ticket is a tax on time that could go toward infrastructure, security, strategic projects, or anything that isn't answering the same SharePoint question for the twelfth time this month.

The conventional argument for remote access tools is that they make resolution faster. That's true and it matters. But faster resolution on a recurring ticket category is still spending time on tickets. Eliminating the category entirely is a different order of magnitude.

The math scales. Ghost Robotics has a globally distributed workforce with specialized technical roles: a profile that creates high-volume, recurring, user-education-category tickets almost structurally. If your team has any version of that (a recent migration, a new tool rollout, a non-technical workforce using technical systems), the same approach applies.

His IT team isn't bigger than it was before the migration. His ticket queue is.

What this requires you to rethink

The only thing standing between most IT teams and this approach is the mental model that remote access is a break/fix tool. It is that. It's also a training delivery mechanism, a proactive onboarding tool, and a way to systematically reduce the volume of work you're going to have to do over the next six months.

The session doesn't have to be long. Bob described a typical training session as quick enough that you could fit it into someone's lunch break without interrupting anything. In and out before they finish eating.

The time investment is front-loaded and one-time. The return keeps compounding every month a ticket doesn't get filed.

Ghost Robotics uses Rippling's remote access to manage IT across a globally distributed, field-deployed workforce. Rippling Remote Access is powered by Splashtop and lives natively inside Rippling's device management platform, so remote sessions start from the same place where you manage your fleet.