--- title: "How remote access work differs by job" description: "Remote access looks like a single product category until you watch four people use it." canonical_url: https://rmm247connect.app/roles section: "Roles" product: 247connect product_website: https://www.247connect.cloud/ site: "247connect Knowledge Hub" author: "247connect Marketing Team" date_published: 2026-02-02 date_modified: 2026-08-27 language: en-GB license: Quotation and citation permitted with attribution to 247connect. --- # How remote access work differs by job ## Key figures - **Role guides:** 4 - **Helpdesk default:** Attended - **Sysadmin default:** Unattended - **MSP requirement:** Multi-tenant ## The same tool, four different jobs Remote access looks like a single product category until you watch four people use it. A helpdesk technician spends the day in short attended sessions with someone watching the screen, so the thing that matters is how fast a session starts and how little the end user has to do to allow it. A systems administrator spends the day in unattended sessions against servers and fixed workstations, so the thing that matters is governed reach: who is allowed onto which machine, and what record exists afterwards. A managed service provider technician does both, but across dozens of unrelated client networks in one shift, so tenant separation and per-client credentials matter more than either. A school network manager does all three with a safeguarding obligation layered over every decision, which changes what is acceptable to install on a device a child uses. Choosing tooling on features alone tends to produce a product that suits one of these jobs and frustrates the other three. Choosing on the shape of the work produces something everyone can live with. - Helpdesk: session start time, consent prompts, no-install joining, in-session chat and file transfer - Systems administration: unattended agents, role-based access, reboot with reconnect, scripting, inventory - MSP: strict tenant boundaries, per-client operator scoping, per-client audit export, predictable licence cost - Education: safeguarding-aware consent, visible session indicators, retention limits on recordings ## What every one of these roles needs from the same platform Underneath the differences there is a common floor. Every role needs named operator accounts rather than shared logins, because a shared login destroys the audit trail that makes remote access defensible. Every role needs two-factor authentication on the operator side, since an operator account is effectively a key to every device it can reach. Every role needs an audit log that records who connected to what, when, and for how long, and that survives long enough to answer a question raised months later. Every role also needs the licence model to match how people actually work. Per-technician licensing punishes teams that share coverage; per-endpoint licensing punishes teams that support a large estate lightly. Concurrency-based licensing on a fixed price tends to survive both patterns without a renegotiation every time the team changes shape. ## Reading these guides in order If you are choosing tooling for a team rather than for yourself, read the role closest to the majority of your work first, then read the role that will complain loudest if you get it wrong. That second read is usually where the requirement you had not written down appears. ## Matching tooling to a role in four steps 1. **Describe a typical week, not a feature wishlist** — Count how many sessions are attended versus unattended, how many are on devices you own, and how many cross an organisational boundary. That ratio drives almost every other decision. 2. **Write down the access rule before you shop** — Decide who may reach which class of device, and whether anyone outside the team ever needs an account. A tool that cannot express your rule will be worked around within a month. 3. **Test the worst case, not the demo case** — Try a slow home broadband connection, a locked-down laptop, and a machine that needs a reboot mid-session. Those three cover most of what goes wrong in production. 4. **Check the audit output before you commit** — Export a log and read it as if you were answering an incident question. If it does not tell you who connected to what and when, it will not help when it matters. ## Frequently asked questions ### Do helpdesk and systems administration need separate remote access tools? Usually not. They need different defaults in the same tool: attended, consent-first sessions for the helpdesk and governed unattended access for administrators. A platform that supports both access models with role-based permissions covers both jobs without a second contract or a second agent on every device. ### How should remote access permissions be structured across a team? Group devices by sensitivity rather than by department, then grant operators access to the groups their job requires. Named accounts with two-factor authentication, no shared logins, and a periodic review of who still needs which group is enough structure for most teams under a few hundred devices. ### What is different about remote access at a managed service provider? Tenant separation. An MSP technician moves between unrelated client estates in a single shift, so the platform has to keep credentials, device lists and audit records strictly per client, and let you hand a single client its own evidence without exposing anyone else's. ### Which skills make the biggest difference in a remote support role? Structured fault isolation, clear written communication with a user who cannot point at the screen, and comfort with a command line for the cases where the desktop is the thing that is broken. Tooling knowledge follows those three rather than replacing them. ## Where 247connect fits 247connect suits teams that span these roles because unlimited operators on fixed pricing removes the per-technician maths, while named accounts, two-factor authentication and audit logs keep unattended access accountable. --- Source page: https://rmm247connect.app/roles Product website: https://www.247connect.cloud/