Remote Incident Manager (RIM) From Pneuma Solutions

Remote Support That Finally Works for Everyone: Remote Incident Manager From Pneum Solutions

I’ve spent most of my career watching the same pattern repeat itself:

An organization adopts a powerful remote support tool.

It works well for most employees.

Blind and low vision staff are quietly excluded from either using that tool or working in the roles that depend on it.

On paper, the organization has “remote support covered.” In reality, they’ve built a critical workflow on infrastructure that simply doesn’t work for everyone.

Remote Incident Manager (RIM) from Pneuma Solutions exists to change this. It’s a full-featured remote desktop platform designed from the ground up so blind, low vision, and sighted technicians can all support users on equal terms, without sacrificing security, performance, or administrative control.

This post is for the people who own that problem: IT leaders, service desk managers, accessibility professionals, and anyone who’s responsible for making sure remote support is both effective and inclusive.

The Hidden Accessibility Gap in Remote Support

Remote support tools are now mission-critical:

Service desks troubleshoot employees’ laptops, servers, and SaaS integrations.
Vendors support their customers’ environments.
Trainers and AT specialists deliver remote instruction.

But almost all mainstream tools share two design assumptions:

The person giving support is sighted.
The user interface is primarily visual, with audio treated as an optional extra.

For blind or low vision technicians and users, those assumptions break down in very practical ways.

What This Looks Like In The Real World

If you’ve ever seen any of these, your current tool has an accessibility problem:

A blind technician asking a user to put their phone on speaker near the computer so they can hear the screen reader, while also trying to control the machine through a remote tool.
A support engineer unable to help because “I can’t hear what your screen reader is saying on your end.”
A blind technologist who could do remote support work, but is kept out of the rotation because the tool the team uses is unusable for them.
A blind end user forced into long, inefficient “tell me what you see” calls because the remote tool can’t be driven effectively with a screen reader.

From a business perspective, that means:

Longer resolution times.
Less consistent support for blind employees or customers.
Talented blind IT professionals sidelined from frontline roles.
A growing gap between your accessibility commitments and day-to-day reality.

The truth is simple: when remote support tools are not accessible, your remote support process isn’t accessible.

What Accessible Remote Support Really Requires

When we started thinking seriously about how to fix this, we defined a set of non-negotiables from both an engineering and an accessibility standpoint.

To make remote support genuinely inclusive, a tool needs to:

Stream the target machine’s audio
Not just voice chat. We need the actual system audio from the remote machine: screen reader speech, system sounds, error chimes, even application audio where relevant. If a blind technician can’t hear what the target machine is saying, they’re flying blind.
Treat keyboard access as a first-class input method
Every critical control in the UI must be reachable and understandable from the keyboard and a screen reader. No mouse-only dialogs. No unlabeled buttons. No ambiguous status messages.
Support both attended and unattended access
Real-world IT requires quick one-off sessions and managed fleets of unattended machines. Accessibility can’t be limited to just one of those modes.
Maintain enterprise-grade security and governance
Accessibility is not a license to relax controls. Security teams still need encryption, clear consent models, strong authentication, and the option for on-prem or private deployments.
Work for everyone, not just blind users
The best accessibility features are ones that also make life better for sighted staff. A tool that forces you to run two parallel remote support platforms, one for blind techs and one for everyone else, is not a sustainable answer.

Remote Incident Manager exists because existing tools rarely meet all of those requirements at once.

Introducing Remote Incident Manager (RIM)

RIM is a remote desktop platform where accessibility is not an add-on, it’s part of the core design.

At a high level, RIM lets a controller (the person giving help) connect to a target (the machine/user receiving help) over a secure connection. Once connected, the controller can:

See and control the remote screen.
Hear the remote machine’s audio (including screen readers).
Talk to the user via integrated voice chat.
Transfer files, share the clipboard, and even reboot and reconnect in unattended scenarios.

The difference is that all of this is designed to work just as well for a blind technician using a screen reader as for a sighted one.

Audio As A First-Class Signal

The single most important architectural decision in RIM is that it streams the target computer’s system audio to the controller.

That means:

A blind technician can hear NVDA, JAWS, Narrator, or VoiceOver running on the remote machine, not just their own.
They can track system sounds and error cues exactly as a local user would.
They no longer have to ask the user to install or configure a screen reader; they can do it themselves over RIM if needed.

From an engineering standpoint, we treat audio like telemetry: it’s as critical to understanding the state of the remote system as what’s on the screen.

A Connection Model That Doesn’t Get In The Way

We also wanted the connection flow to be simple enough that anyone could use it without training.

A typical attended session looks like this:

The technician opens RIM and generates a short, human-readable session keyword.
They share that keyword with the user (phone, email, chat, ticket, etc.).
The user runs RIM, enters the keyword, and confirms they want to allow access.
RIM’s coordination service brokers the connection and, when possible, establishes a direct, encrypted session between the two machines.
The technician now has full control, plus audio and voice chat, until the session ends.

There’s no complicated PIN scheme, and the same app is used by both sides. For the user, it’s “enter the word, click OK, and you’re connected.”

For unattended scenarios, RIM uses explicit enrollment rather than “magic backdoors.” Machines are configured ahead of time (manually or via silent installers in enterprise deployments), grouped, and assigned to the appropriate technicians or teams.

Built for Real IT and Support Teams

RIM is not a “niche tool for blind techies.” It’s designed to function as a primary remote support platform in serious environments.

A Feature Set You’d Expect From A Modern Remote Tool

Once connected, technicians can:

Use full keyboard and mouse control.
Transfer files securely in both directions.
Share clipboard content between local and remote.
Switch between multiple monitors on the target machine.
Flip control mid-session (for training and demonstration scenarios).
Reboot the remote machine and reconnect automatically when it comes back online (including for unattended servers and workstations).

From an engineering perspective, you shouldn’t have to choose between accessibility and capability. RIM is built so you can have both.

Cross-Platform Where It Matters

RIM supports:

Controllers on Windows and macOS.
Targets on Windows and macOS.

That covers the majority of enterprise endpoints today. We designed the protocols and client architecture so that as ecosystems evolve, new platforms can be integrated without rethinking everything from scratch.

Security and Compliance by Design

Any time you say “remote access,” security teams (rightly) start asking hard questions. As an engineer, I expect those conversations, and I’d worry if they didn’t happen.

RIM is built with several security principles in mind:

End-To-End Encryption

Session traffic between controller and target is encrypted so that no intermediate server, even ours, can inspect the contents:

When peer-to-peer connections are possible, traffic flows directly between endpoints.
When relays are necessary (due to firewalls/NAT), they forward encrypted packets without the ability to decrypt them.

Explicit Consent And Controlled Unattended Access

For attended support:

The target must take a deliberate action to accept each connection.
When the RIM app on the target is closed, no further connections can be made.

For unattended access:

A machine must be explicitly enrolled and assigned to a technician or group.
Enterprise deployments can integrate with existing identity systems and permission models.

We want security teams to see RIM as predictable, auditable infrastructure, not a shadow IT workaround.

Enterprise Deployment Options

Different organizations have different risk appetites and regulatory environments. RIM can be:

Used as a cloud-orchestrated service, ideal for many businesses and nonprofits.
Deployed in a private environment, where the coordination and relay services run in infrastructure you control (data centers, private clouds, or locked-down VPCs).

In both cases, RIM works within your existing security policies, rather than forcing you to weaken them.

Why This Matters for Your Organization

It’s easy to think of RIM purely in terms of accessibility, and it is a major accessibility enabler. But the business impact is broader.

Faster, More Accurate Support

When technicians (blind or sighted) can both see and hear what the remote machine is doing:

They diagnose problems faster.
They avoid miscommunication and guesswork (“What exactly did that dialog say?”).
They can handle more issues in a single interaction, rather than bouncing tickets between teams.

In practice, that translates to shorter resolution times and higher first-call resolution rates.

One Tool For The Whole Team

With RIM, you don’t have to maintain two parallel remote support stacks:

One that mostly works for sighted techs.
One that kind-of-sort-of works for blind techs, if they’re allowed to use it.

Instead, everyone uses the same tool, with the same workflows and training. That simplifies support, licensing, and policy.

Real Inclusion, Not Just Policy Statements

If you employ blind or low vision IT professionals, or want to, remote support is often a hidden barrier to advancement.

Giving them a tool they can use fully and independently means:

They can participate in on-call rotations and frontline support.
Their skills are visible in the same metrics and dashboards as their peers.
You can promote and retain them based on performance, not based on who can use the tools.

For organizations serious about DEI, that’s not a “nice to have.” It’s necessary.

Where RIM Delivers the Most Value

From what I’ve seen, RIM tends to have the biggest impact in a few specific contexts:

1. Internal Service Desks and IT Ddepartments

If you run a service desk that supports blind employees, or employs blind technicians, RIM lets you:

Standardize on one remote support platform that works for everyone.
Reduce friction when supporting screen reader users (no more “hold your phone to the speaker” workarounds).
Build accessibility into your incident management process instead of bolting it on per ticket.

2. Universities And Training Centers

For disability services, assistive technology, and IT teams in education:

Trainers can remotely demonstrate AT, then flip control so students can practice while being observed.
Campus IT can support blind students’ personal devices and lab machines using the same tool they use for everyone else.
Blind students in IT programs can do real remote support work as part of their training.

3. Vendors And Accessibility-Focused Service Providers

If you provide AT consulting, training, or tech support to external customers:

RIM gives you a professional, accessible way to connect to client machines.
You can handle both attended troubleshooting and longer-term, unattended maintenance for contracted environments.
You’re not asking clients to lower their security standards just to let you help.

How to Evaluate RIM in Your Environment

If you’re an IT leader, service desk manager, or accessibility program owner, here’s how I’d recommend approaching a RIM evaluation.

Step 1: Identify The “Pain Points”

Talk to:

Blind and low vision employees in IT and beyond.
Service desk staff who support blind users.
Accessibility or disability services staff.

Ask them:

What’s hardest about remote support today?
Where do current tools fail or require awkward workarounds?
Who is excluded from using the tools you have?

Use those answers as your baseline.

Step 2: Run A Focused Pilot

Pick a small but representative group of technicians and users, ideally including at least one blind technician and some blind end users, and:

Deploy RIM alongside your existing tool.
Have them use RIM for real tickets over a defined period (e.g., 2-4 weeks).
Track metrics: resolution time, call duration, user satisfaction, first-call resolution, technician feedback.

The goal is not a lab test; it’s to see how RIM behaves under the same messy conditions as your current tool.

Step 3: Involve security and compliance early

Bring in your security and compliance stakeholders at the beginning:

Share documentation on RIM’s encryption, consent model, and deployment options.
Map RIM’s capabilities to your existing policies (remote access, privileged access management, logging).
If on-prem or private deployment is important, discuss what that would look like in your environment.

The earlier they’re part of the discussion, the smoother your rollout will be.

Step 4: Decide on a path forward

Based on the pilot, your data should answer:

Does RIM improve the experience for blind and low vision staff?
Does it maintain or improve support quality for everyone else?
Can your security and compliance teams support it?

If the answers are yes, the rest becomes a planning exercise: rollout sequencing, training, and decommissioning or re-scoping older tools.

Closing Thoughts: Accessibility as Infrastructure, Not Charity

From my perspective as an engineer and access technology specialist, the most important shift we can make is this:

Stop treating accessibility as an exception path and start treating it as infrastructure.

Remote support is infrastructure. When it excludes whole groups of employees or customers, the cost is higher than a few awkward calls. It affects hiring, retention, productivity, and risk.

Remote Incident Manager is one example of how we can do better: a tool that meets real IT requirements and is inherently usable by blind, low vision, and sighted staff alike.

If you’re responsible for remote support in your organization, I’d encourage you to ask a simple question:

Can every member of my team, and every employee we support, use our current remote tool with equal confidence?

If the answer is anything less than an unqualified “yes,” it’s time to look at alternatives.

RIM is ready when you are.

” The greatest barrier to acessibility is indifference. “

Aaron Di Blasi, PMP
Engineer, Educator, Advocate, Publisher and Journalist, President & Sr. PMP, Mind Vault Solutions, Ltd., PR Director: AT-Newswire, Publisher: AI-Weekly, Top Tech Tidbits, Access Information News, Title II Today

Mind Vault Solutions, Ltd.
President, Sr. Project Management Professional (2006 — Present)
Innovative ideas. Solutions that perform.