Consent, Every Time: Asking Before You Connect

Friday, 09:05, at Harbourview Clinic. Leo on the desk has ticket 3306 from Priya at reception: the appointments screen freezes every time she opens a patient's record. He phones her. "Hi Priya, it's Leo from IT about the appointments freeze. Can I connect to your screen and have a look? About five minutes." There is a pause, and a voice in the background. "Not right now, I've got someone at the desk. Give me two minutes." Leo waits. At 09:08 she rings back, says the patient has gone and the screen is clear, and says go ahead. He connects, she watches, and the freeze turns out to be a stuck print job holding the screen hostage. Four minutes.

A year earlier Leo would have connected at 09:05 without phoning, because the ticket said "urgent" and the fix would be quick. A patient standing at reception would have watched a cursor they did not control open a record that was not theirs. Nothing bad would have been taken. Something bad would have been seen, by someone with every right to complain. Consent is the user's specific yes to this specific remote session, given at the time. The user knows what it is for and roughly how long it will take. They also know that they can end it whenever they like. Consent is not the policy that says the desk may use remote control; that is permission, granted once by the organisation. Consent is granted every time by the person whose screen it is. This article is part of our Remote Support Tooling series. This article is about the ask: how to make it, what the user must see, and when they may say no. It also covers what to do with the handful of situations that feel like exceptions and are not.

It covers why permission is not consent and the ask itself, in three parts. Then come the visible session and the user's right to end it. Next are what to say and what to show them during the session, and consent when the computer is not the user's own. After that come the exceptions that are not exceptions, in a table, and recording the yes in the ticket. Last come a short war story and the consent script to copy.

Permission Is Not Consent

Every desk that uses remote control has permission to do so, written somewhere, usually in a policy like the one in Remote Control Done Securely. Permission is the organisation's decision that remote control is an acceptable way to deliver support. It says nothing about Priya, or Friday, or the patient at the desk. It is a standing arrangement between the desk and the organisation, and the user was not in the room when it was made.

Consent is the arrangement between the technician and the user. It has to be made fresh each time because the circumstances are fresh each time. The user may have a patient at the desk, a payslip open, a message from their doctor on screen, or a child doing homework on the same computer at home. The technician cannot know any of that, which is exactly why the ask exists. It is not a formality that a trusting user can waive for life. It is the moment when the only person who knows what is on the screen gets to say whether now is a good time.

The ask also does something for the desk that nothing else can. It teaches every user what a legitimate connection looks like: a known name, a ticket number, a question, and a prompt on the screen that they click. A user who has been asked every time for two years notices immediately when a stranger on the phone does not ask but instructs. The desk that asks every time has, without meaning to, trained its whole organisation to recognise an impostor. The desk that connects silently has trained them to accept one.

The Ask, in Three Parts

The ask has three parts, and it takes about fifteen seconds to say. First, who you are and which ticket: "It's Leo from the IT desk, about ticket 3306, the appointments freeze." The ticket number is the user's proof that this is real, because they can see it in the e-mail they received when they raised it. Second, what you want to do and for how long: "I'd like to connect to your screen and look at the print queue; it should be five minutes or so." Third, the question, which is a genuine question with a genuine no available: "Is now a good time, and is there anything on your screen you'd like to close first?"

The third part is the one desks drop, and it is the one that matters. "Can I connect?" invites a reflex yes. "Is now a good time, and is there anything you'd like to close?" invites the user to look at their own screen, which is what you need them to do. Most of the time they will say "no, go ahead". Some of the time they will say "hang on", close a window, and then say go ahead. Occasionally they will say "not now", and that is the system working, not failing. Consent is a two-minute delay that has never once made a ticket worse.

The ask can be by voice or in writing. The written form matters for the desk that works from the queue rather than the phone. A reply on the ticket that says "I can connect to your screen to fix this; reply yes with a time that suits you and I'll call you first" is a complete ask. The user's "yes, 2pm" is a complete consent, recorded already in the ticket. What the written ask may not do is treat silence as a yes. "I'll connect at 2pm unless I hear otherwise" is not an ask. It is a notice, and the user who did not read it will meet a cursor at two o'clock.

The Visible Session

A visible session is one where the user can see, at every moment, that a technician is connected and what the technician is doing. Three things make it visible. The prompt at the start, which the user clicks to allow the connection, is the first. Most remote support tools show one. Where the tool allows the prompt to be skipped, the desk does not skip it on a workstation with a person present. The indicator during the session is the second: a border, a banner, a small window, something on the user's screen that says "a session is active" the whole time. The cursor itself is the third, moving where the user did not move it, which is the one thing nobody misses.

Some tools can blank the user's monitor while the technician works, so that the user sees a dark screen and the technician sees the desktop. That feature exists for working on a server in a locked room or a kiosk with nobody at it. It is never used on a workstation with a person present, because it turns a visible session into an invisible one. The user's only evidence that anything is happening is a black rectangle. Do not blank their screen. Not to "reduce distraction". Not with a person at it, ever.

Visibility is also why the technician narrates. "I'm opening the print queue now. There are eleven jobs stuck; I'm going to clear them. Now I'm going to open the appointments screen to test it." The narration costs nothing and does two things. It keeps the user informed, so that nothing on their screen surprises them. And it keeps the technician honest, because it is hard to wander into a folder you were not asked about while describing aloud what you are doing. Every remote tool has a setting that lets the technician skip the prompt, and every vendor describes it as "streamlined". The narration is the opposite of streamlined, and it is the part users remember kindly.

The User's Right to End It

The user can end the session at any moment, without giving a reason. The technician's response is to say "no problem" and mean it. Every remote support tool gives the user a way to disconnect, usually a button on the indicator. The ask includes telling them where it is: "If you need me to stop at any point, click the red button in the corner and I'm gone." Saying it does two things. It gives the user a sense of control that makes the yes easier, and it means that when they do use it, there is no awkwardness about how.

Users end sessions for reasons that are theirs. A manager walked in. A message arrived. A patient came to the desk. They remembered what was in the other tab. Whatever the reason, the technician does not ask what it was and does not reconnect without asking again. The technician writes one neutral line in the ticket: "Session ended by user at 09:14; will re-arrange." Then the technician phones or replies, says "no problem, let me know when suits", and waits. A session the user ended is not a failure. A technician who reconnects to find out why would be.

The right to end it includes the right to never start it, and the technician needs an answer for that too. Some users will not want remote control at all, for reasons they may or may not explain. The desk's job is to fix the problem some other way: walk over, talk them through it by phone, or arrange a time when the device can be brought in. The policy may say the desk prefers remote control; it may not say the user must accept it. A desk that cannot fix a printer without connecting has a different problem from the printer.

What to Say, and What to Show Them

During the session, the technician stays inside the task and says so when they need to step outside it. Fixing a printer does not require the mail client. If a step genuinely does, the technician asks first: "I need to open your e-mail to check the account settings; is that all right, or would you rather do that part?" Asking mid-session feels fussy and is not. The user consented to a printer fix. A new window is a new question, and most users, asked, will say yes and be glad they were asked.

When something appears on screen that the technician should not see, which happens, the technician says so and looks away. "There's a document open on the left; I'm not going to touch it. Do you want to close it, or shall I carry on?" Pretending not to have noticed is worse than noticing, because the user knows the technician can see the screen. A silence about the obvious thing makes them wonder what else was silently noticed. Name it, neutrally, once, and move on. Do not comment on it, then or later. (The window is always, somehow, payroll.)

At the end, the technician shows the user the result, asks them to confirm it, and ends the session while the user is watching. "The appointments screen is loading now; can you open a record and check it behaves? Good. I'm disconnecting now; you'll see the banner go." The last sentence matters more than it looks. A session that ends with the user watching the indicator disappear is a session they know is over. A session that quietly drops when the technician moves to the next ticket leaves the user looking at a screen and wondering whether anyone is still there. Remote sessions do not end on their own. They wait, patiently, for the technician to remember them, and the technician is already on ticket 3307.

When the Computer Is Not the User's Own

Consent comes from the person at the computer, which is simple when the person and the computer belong together and less simple otherwise. A shared reception machine has whoever is sitting at it now; they consent. If they are not the person who raised the ticket, the technician says who they are, what the ticket is, and asks anyway. A kiosk or a meeting-room screen with nobody at it is not a workstation with a person present. Connecting to it is unattended access, with its own approvals and its own register. That is the subject of Unattended Access: When, Where and Who. The fact that nobody is there to object does not make the chair's silence a yes.

A manager asking the desk to connect to a member of their team's computer is the hard case. The answer is that the manager can authorise the work and cannot consent to the session. "Can you remote onto Sam's machine and fix his mapped drives while he's out?" is a request for unattended access to a workstation, which the policy does not allow. The technician's reply is "I'll do it with Sam when he's back, or I can walk over now and do it at his desk." Where the manager's request is about seeing what Sam has been doing, it is not a support request at all. In that case, it goes to whoever in the organisation handles that kind of question, by a route that is not the remote support tool. The desk does not investigate people. It fixes computers, with the people at them.

A computer that is the user's own property, at home, raises a different question, which is whether the desk should connect at all. The boundary around personal devices belongs to BYOD and Personal Devices. If the policy allows it, consent on a personal device is consent from the owner. The owner may be the user or may be the person whose laptop the user borrowed. When the policy allows a connection, the technician asks which before asking the rest.

The Exceptions That Are Not Exceptions

Every desk accumulates a set of reasons for connecting without asking, and each sounds reasonable on the day. The table lists the ones I have heard most often, with the answer to each. None of them is an exception to consent. Two of them are consent, said badly, and the fix is to say it properly. Tickets marked urgent believe they are permission slips. They are not.

The one genuine exception in remote support is the server in the rack. There is no person to ask, and the organisation's approval stands in for consent. The exception is genuine precisely because it is written down, approved by name, and alerts someone each time it is used. That is a different thing from a workstation with an empty chair. The register in the unattended access article is where the line is drawn. If a situation is not in that register, the answer is to ask a person.

Recording the Yes

The consent goes in the ticket, in one line, written at the time. "Asked Priya by phone at 09:05; not a good time; re-asked 09:08, agreed; connected 09:08." That line is the first part of the session note, whose full form is in Logging and Session Records. That consent line answers the question nobody asks until they do: "Did anyone agree to this?" The tool's own log will show that a connection happened at 09:08. It will not show that someone said yes, because yes is a thing people say, not a thing tools record. The ticket is where it is recorded. If you run QuerySolv the line sits in the ticket's event history with everything else that happened on that ticket. That is where a stranger would look first.

Written consent on the ticket records itself, which is one of its quiet advantages. The user's reply "yes, 2pm is fine" is already in the ticket under their own name. The technician's note needs only to say "connected 14:02 as agreed". Voice consent needs the technician to write the line. The discipline is to write it before connecting, not after the fix. That is because after the fix there is a next ticket and the line gets written at five o'clock from memory, or not at all. Ask, write the line, connect. Three steps, in that order, and the first two take less time than the tool takes to open.

If the user ends the session or declines it, that goes in the same line, neutrally. "Session ended by user at 09:14; re-arranged for 11:00." "User prefers not to use remote control; resolved by phone." Neither is a complaint about the user, and neither should read like one when the user reads it, which they may. The note is a record of what happened. What happened is that the system worked.

A Short War Story: The Lunch-Hour Fix at Tollgate Foods

At Tollgate Foods, a technician called Hamid picked up a ticket from Grace in human resources about a label printer that would not print from her machine. He saw that she was at lunch and connected without asking because the fix was two minutes and he wanted to clear it before she got back. Grace returned to her desk to find the cursor moving on a screen that still had a disciplinary letter open behind the printer dialog. She watched the cursor for a full minute before she understood what it was. Nothing in the letter was read or copied, and the log and Hamid's note both said so. But Grace raised a formal complaint. The human resources director withdrew remote support consent for the whole department for six months while a policy was written. For six months, every printer, mapped drive and spreadsheet problem in human resources meant a walk across the site. Hamid's colleague Rosa counted forty-one visits, each about half an hour with the walk, against a saving of two minutes on the day. The policy that came out of it has one line in bold at the top. It was Grace who suggested it: the two-minute ask is cheaper than the six-month walk.

The Consent Script

The script below gives the words for the four moments where consent is asked, shown, ended and recorded. Those are the ask by phone, the ask in writing, the lines to say during the session, and the close. The script is written in a plain voice that each technician can make their own. The tone rules in Writing Like a Person, Not a Policy apply. The words "policy" and "protocol" do not appear in the script because the user did not ask about either. Pin it beside the screen for the first month. After that, most technicians stop needing it and keep saying it anyway, which is the point.

THE CONSENT SCRIPT — FOUR MOMENTS
Ticket: ________   User: ______________   Technician: ______________

1. THE ASK, BY PHONE
   "Hi ______, it's ______ from the IT desk, about ticket ______,
    the ______________.
    I'd like to connect to your screen and ______________;
    it should take about ______ minutes.
    Is now a good time, and is there anything on your screen
    you'd like to close first?
    You'll see a prompt to allow me in. If you want me to stop
    at any point, click ______________ and I'm gone straight away."

2. THE ASK, IN WRITING (on the ticket)
   "I can fix this by connecting to your screen, which takes about
    ______ minutes. Reply with a time that suits you and I'll phone
    first so you can see it happen. If you'd rather I didn't connect,
    say so and we'll do it another way."
   (Silence is not a yes. Wait for the reply.)

3. DURING THE SESSION (narrate each step before taking it)
   "I'm connected now; you'll see ______________ on your screen."
   "I'm opening ______________ to ______________."
   "I need to open ______________ for the next step; is that all right,
    or would you rather do that part yourself?"
   "There's a window open on the ______ that I don't need; I'm not
    going to touch it. Do you want to close it?"
   "Can you try ______________ and tell me what happens?"

4. THE CLOSE
   "That's working now. Can you check ______________ for me? Good.
    I'm disconnecting now; you'll see the banner disappear.
    I'll put a note on the ticket saying what I did."

5. THE LINE IN THE TICKET (written before connecting)
   Asked ______ by [phone / ticket] at ______; answer: ______.
   Connected ______.   Ended ______ by [me / user].   Re-arranged: ______.

Leo's ticket 3306 has the first and fifth blocks in it, more or less word for word: asked at 09:05, not a good time, re-asked 09:08, connected 09:08, ended 09:12 with Priya watching, print queue cleared. Priya later told the practice manager that she liked being asked, because the patient at the desk had been nervous enough already. The practice manager told the desk, and the desk put the sentence on the wall. It is the only compliment about remote control they have ever received, and they have decided to treat it as the standard.

Frequently Asked Questions