Service
Help that arrives before the drive would.
Screen sharing and remote control over ordinary HTTPS, reachable from a browser when installing anything on the far end is not practical — and every organisation kept separate from every other.
The problem
Most problems never needed somebody in the room.
A setting changed by accident, a stuck print queue, software that needs reinstalling — none of these need a van and half a morning. They need somebody able to look at the screen within a few minutes.
The obstacle is almost always access. Either there is no remote tool at all, or there is one nobody can log into, or it needs software installed on the very machine that has stopped working.
Which is the argument for setting it up while everything is fine. The access has to exist before the emergency does, or it is not access.
What’s included
What the work actually covers.
Works from a browser
A session can be opened from a browser when installing software on the far end is not realistic — a locked-down machine, a device that is not yours, or somebody who simply cannot install anything.
Travels as ordinary web traffic
The connection uses the standard web port and encryption, so it keeps working on guest networks and restricted connections that block purpose-built remote-support tools outright.
Your own device list
Each organisation gets its own directory with a consistent naming scheme, so a machine is identifiable at a glance instead of by a string of digits nobody recognises.
Separate by default
One organisation cannot see or reach another organisation machines. That separation is how it is built rather than a setting somebody has to remember to switch on.
Runs on our own infrastructure
The service is self-hosted rather than a third-party account, so the route into your machines is not a subscription somebody else can cancel or change the terms of.
Comes back by itself
It is layered so it restarts if it stops and returns after a reboot — because a remote-access tool that is down at the moment you need it is worse than not having one at all.
How it runs
From setup to first session.
Install it during setup
The client goes on as part of normal machine onboarding, so it is already present and already named correctly long before anybody needs to use it.
Agree the rules first
Who may connect, whether somebody at the machine has to approve it, and what happens out of hours. Settled in advance rather than argued about during a problem.
Use it
A session opens in minutes. A good share of issues get resolved while the person who reported it is still on the phone.
Keep the list true
New machines are added as they are onboarded and departed machines are removed. A device list only stays useful for as long as it stays accurate.
Questions
Asked before every job.
Can you watch my screen without me knowing?
Not the way we recommend setting it up, which requires somebody at the machine to approve each session. Unattended access exists for servers and machines nobody sits at, and that is chosen deliberately per machine rather than switched on everywhere.
What if the machine is on restrictive Wi-Fi?
That is the normal case rather than the exception, and it is exactly why the connection uses the standard web port and encryption instead of a purpose-built protocol that locked-down networks drop.
Does this replace coming on site?
Not for hardware. It replaces the visits that were never really about hardware, which is most of them.
Who else can reach my machines?
Nobody. Each organisation has its own directory and there is no path from one to another — the same default-deny principle the networks are built on.
Tell us how support happens now.
Describe what somebody does today when something breaks — who they call, and how long they wait. The first conversation is free.