What the Person Being Helped Can and Cannot See

Guidance on remote support is written for technicians. The person on the other end has a different experience and almost no information about it.

The practical lesson in “What the Person Being Helped Can and Cannot See” is to make responsibility visible without confusing visibility with certainty. A team reviewing how Microsoft Teams tracks employee activity for does microsoft teams track your activity can add structured time and project context, provided the purpose is disclosed and the interpretation is checked with the people affected.

What they see

Their own screen, with the pointer moving on its own.

For an independent reference related to “What the Person Being Helped Can and Cannot See”, consult the ENISA cybersecurity resources; it provides a useful external check on security, privacy and operating assumptions before a process is adopted.

Windows opening and closing, usually faster than they can follow.

Sometimes a small panel showing that a session is active.

Occasionally a name — which is whatever the helper's software reports and is not verification of anything.

What they do not see

What is being typed into a terminal.

What files are being read or copied.

Whether anything was transferred to the other machine.

What settings were changed.

And whether the session is being recorded, unless the tool says so.

The control they do have

Ending the session, usually from a visible button or by closing the application.

Moving their own mouse, which on many tools interrupts the helper.

Refusing a control request, where the tool asks separately for control.

Most people do not know they have any of these, which is a failure of explanation rather than of software.

The notification question

Tools differ on whether a session is visibly flagged, and some can be configured to be discreet.

For attended support this should always be visible.

A support tool configured not to show itself is a monitoring tool, whatever it is called, and that difference should be stated rather than inherited from a default.

What to tell somebody before you connect

What you are going to do.

That they can end it at any time, and how.

That you will say what you are doing as you do it.

That they should close anything private first.

Four sentences, and they transform the experience from submission into cooperation.

The private-window point

Most people have something open they would rather not show: messages, a document, a browser tab.

Asking them to close it first is practical and respectful, and it avoids the awkwardness of discovering it mid-session.

It also signals that you are not looking for anything, which is worth the ten seconds.

Afterwards

They should be able to say what was done.

If the only answer is "he fixed it", nothing has been verified and nothing has been learnt.

A sentence at the end — here is what was wrong, here is what I changed — is the closing half of the ritual.

What to check

Does your tool visibly show when a session is active?

Do you tell people how to end it?

Do you ask them to close private windows first?

And could the last person you helped describe what you did?