Remote IT Support Across Borders: What I Learned Supporting 30+ Branches

There's a particular kind of problem-solving that happens when you're responsible for IT across 30+ branches spread across two countries, and you can't physically visit most of them. No walking over to someone's desk. No plugging in a cable yourself. No "let me just take a quick look at the server." You learn to solve problems through other people's hands, over unreliable internet connections, across time zones, and with wildly different levels of technical literacy on the other end.

That was my reality at Hand in Hand Eastern Africa, where I managed IT infrastructure and support across branches in Kenya and Tanzania. It taught me more about resilience, systems thinking, and human-centered IT than any certification ever could.

The Challenges Nobody Warns You About

When people think "remote IT support," they picture a help desk agent remoting into a laptop from a comfortable office. Supporting distributed branches across East Africa is a different universe.

• Unreliable internet — Some branches had stable fiber. Others relied on mobile hotspots that dropped every 20 minutes. A few had satellite connections with latency so high that remote desktop sessions were practically unusable. You can't assume always-on connectivity when designing your support model.
• Varied technical literacy — Branch staff ranged from people comfortable with Excel formulas to people who needed step-by-step guidance on how to attach a file to an email. One-size-fits-all training doesn't work when the skill gap is this wide.
• Limited on-site presence — With 30+ branches and one IT team at headquarters, physical visits were quarterly at best. Most problems had to be solved remotely, and the person at the branch was your hands and eyes.
• Power instability — Unexpected power outages could take down equipment mid-update. UPS units and surge protectors weren't luxuries — they were survival gear. I learned to schedule critical updates during off-peak hours and always have a rollback plan.
• Cross-border complexity — Kenya and Tanzania have different telecom providers, different regulatory requirements, and different network infrastructure. What works in Nairobi doesn't necessarily work in Dar es Salaam.

The biggest lesson from distributed IT support: you're not managing technology — you're managing the gap between technology and the people who use it, across distances you can't physically close.

Microsoft 365 as the Backbone

The single best infrastructure decision we made was standardizing on Microsoft 365 with Active Directory. Before this, branches operated like isolated islands — different email setups, local file storage, no centralized user management. It was a support nightmare.

M365 unified everything:

• Active Directory gave us centralized identity management. One place to provision accounts, enforce password policies, manage group permissions, and disable access when staff moved on. Before AD, deprovisioning a departing employee meant contacting every branch to check what systems they had access to.
• Exchange Online replaced a patchwork of local mail servers and free email accounts with a single, reliable email system. No more "the branch email is down" calls because someone accidentally unplugged the mail server.
• SharePoint and OneDrive solved the file-sharing problem. Instead of emailing documents back and forth (and losing version control in the process), branches could collaborate on shared documents with automatic sync when connectivity allowed.
• Teams became the primary communication channel, replacing a mix of WhatsApp groups, phone calls, and emails that made it impossible to track conversations.

The migration wasn't smooth — rolling out M365 to 200+ users across two countries took careful planning, phased deployment, and more patience than I expected. But once it was in place, the reduction in support tickets was dramatic. We went from constant email server issues and access management problems to a stable, centrally managed platform.

Remote Support Tools That Actually Work

When you can't be physically present, your remote support toolkit is everything. I tested dozens of tools and settled on a stack based on one criterion: what works reliably on low-bandwidth connections?

• TeamViewer — The primary remote access tool. It handled unstable connections better than most alternatives, automatically adjusting quality to match available bandwidth. For branches with decent internet, it was as good as being there.
• AnyDesk — The backup when TeamViewer struggled. AnyDesk's lightweight protocol sometimes pushed through on connections where TeamViewer timed out. Having two remote access tools isn't redundancy — it's necessity.
• Remote PowerShell — For Windows administration tasks that didn't need a graphical interface. Resetting passwords, checking service status, deploying scripts — all possible over minimal bandwidth. I built a library of PowerShell scripts for the 20 most common admin tasks.
• Screen sharing via Teams — For guided troubleshooting where the branch user needed to perform the steps. I could see their screen, talk them through the process, and annotate what to click. This was essential for problems that required local admin access I didn't have remotely.

The best remote support tool is the one that works on the worst connection in your network. Design for your weakest link, not your strongest.

Training at Scale: The IT Champions Model

You cannot train 200+ users on new systems by visiting every branch. You also can't do it through a single webinar and a PDF manual. The approach that actually worked was building a network of IT champions — one designated person per branch who became the local point of contact for technology.

Here's how the IT champions model worked:

1. Selection — I identified the most tech-comfortable person at each branch. Not necessarily the manager — often it was an operations clerk or loan officer who naturally helped colleagues with computer issues.
2. Intensive training — Champions received deeper training than regular users. They learned not just how to use the systems, but basic troubleshooting: restarting services, checking network connections, clearing browser caches, verifying printer setups.
3. Level 0 support — Champions handled the simplest issues locally before escalating to HQ. "My email isn't loading" often meant "the WiFi is disconnected" — something a local champion could resolve in 30 seconds versus a 20-minute remote session with HQ.
4. Train the trainer — When we rolled out new features or systems, I trained the champions first, then they trained their branch colleagues. This scaled our reach by 30x without scaling the IT team.

The result: support ticket volume from branches dropped by roughly 40% within three months of establishing the champions network. The tickets that did come through were more complex and better-described, because the champion had already done initial triage.

Documentation for Low-Bandwidth Environments

Standard documentation doesn't work when half your users can't reliably load a SharePoint page. I learned to create documentation in formats that matched the actual connectivity reality of each branch.

• Offline-capable guides — Critical documentation was distributed as lightweight PDFs that lived locally on each branch's shared drive. No internet required. These covered the 15 most common procedures: password resets, printer troubleshooting, VPN reconnection, basic email fixes.
• WhatsApp-friendly quick tips — For urgent issues, I created single-image guides — a screenshot with numbered annotations showing exactly what to click. WhatsApp compresses images but they remained readable, and every branch staff member had WhatsApp. A branch could receive a troubleshooting guide in under 30 seconds on a 2G connection.
• Video walkthroughs — For complex procedures like M365 first-time setup, I recorded short screen capture videos and distributed them on USB drives during branch visits. Staff could watch and follow along at their own pace without consuming bandwidth.
• Tiered documentation — Each guide existed in three versions: a one-page quick reference for experienced users, a step-by-step guide for regular users, and a detailed walkthrough with screenshots for users who needed extra support. The IT champion at each branch decided which version to distribute.

Documentation isn't useful if it can't reach the person who needs it. Format your guides for the worst-case connectivity scenario, not the best-case one.

Infrastructure Decisions That Kept Everything Running

Behind the user-facing support was a layer of infrastructure decisions that made remote management possible in the first place.

VPN configuration was critical for secure access to centralized systems. I configured site-to-site VPNs for branches with stable connections and client-based VPN for branches where connectivity was intermittent. The key was making VPN reconnection automatic — if a branch lost internet and came back, the VPN re-established without anyone needing to do anything.

Network monitoring gave us visibility into problems before branches reported them. I set up alerts for when a branch went offline, when bandwidth dropped below usable thresholds, or when a critical service stopped responding. This meant we could often reach out to a branch proactively — "We noticed your connection dropped, here's what to check" — instead of waiting for a frustrated call.

Backup strategies had to account for distributed data. Critical branch data synced to the cloud when connectivity allowed, with local backups as a safety net. I scheduled backups during off-peak hours to avoid competing with operational bandwidth, and the IT champion at each branch verified backup completion weekly.

This role taught me that IT support at its core isn't about technology — it's about resilience. Building systems that survive unreliable power, intermittent connectivity, and the inevitable human errors that happen when people are learning new tools under pressure. It's about patience — walking someone through a process for the fifth time without frustration, because getting it right matters more than getting it fast. And it's about the humbling realization that the hardest problems to solve are often the ones you can't physically touch.

Building Distributed IT Support? Start Here

If you're managing IT across multiple locations — especially in environments with infrastructure constraints — the playbook is the same: centralize your identity and access management, build a local champions network, design documentation for your worst-case connectivity, and invest in monitoring that gives you visibility before problems become crises. Need help architecting distributed IT support or planning a multi-branch M365 migration? Let's talk.