8 Things to Check Before a Remote Support Session

A technician picks up a new incident, opens a remote session and asks the employee what kind of laptop they are using. The configuration item, the employee's earlier incidents and the record of a previous session are already attached to that incident. The employee spends the opening of the call repeating what the service desk already holds, and the actual troubleshooting starts later than it needed to.

TL;DR: Eight Things to Check Before a Remote Session Starts

Seven of these eight items already live in ServiceNow, and the eighth depends on the access mode the session will use.

Employee Identity and Contact Channel
Reported Symptom and Incident Priority
Affected Device and CMDB Record
Past Incidents From the Same Employee
Steps Already Tried on the Incident
Linked Outages, Problems and Changes
Known Fixes for the Reported Symptom
Access Mode and Employee Consent

Two things stay hidden until the device connects: its live state and the documented fix that matches the state. Those two answers are where AI and modern support tooling matter most, and the second half of this guide covers both.

Why the Context a Technician Needs Already Sits Inside ServiceNow

ServiceNow's own documentation describes the initial diagnosis of incidents as largely a human process. The agent reads the incident details and can query the CMDB, which holds information about hardware, software and the relationships between them.

The context exists, but it is spread across several places: the fields on the incident form, the configuration item in the CMDB, the related lists on the incident and any ScreenMeet session records attached to it. A checklist turns those scattered sources into a fixed order of reading before the session opens.

The cost of starting a session without that picture is covered in ScreenMeet's analysis of the information gap at session start. This guide deals with where each piece of the picture can be found.

8 Things a Technician Should Know Before a Remote Session Starts

1. Employee Identity and Contact Channel

Three fields on the incident form tell the technician who is on the other end and how the incident arrived.

Caller: the user who contacted the service desk, so the technician can confirm the person before asking a single question.
Channel: how the incident was created, with options that include chat, email, phone, monitoring, self-service, virtual agent and walk-in.
Origin: filled in automatically with the source, for example Alert for an incident created from an alert.

An incident created from an alert may not have been reported by the employee at all, so the call should open by explaining why the desk is in touch. An incident raised through self-service or virtual agent is a prompt to ask what the employee already tried in that channel.

2. Reported Symptom and Incident Priority

The Short description and Description fields hold the employee's own account of the symptom, written before anyone joined a call. Category and Subcategory record the type of issue, which narrows the troubleshooting path before the technician connects.

ServiceNow bases Priority on Impact and Urgency, and Priority identifies how quickly the service desk should address the task. On a high-priority incident, the technician should confirm the business impact with the employee at the start of the session.

3. Affected Device and CMDB Record

The Configuration item field records the affected CI, which tells the technician which device record to open before connecting. In instances that use the Service Graph Connector for Tanium, hardware, software and software usage data from Tanium is imported into ServiceNow and mapped into CMDB classes such as Computer, Disk, File System, IP Address and Software.

ServiceNow also shows a Primary device health link in the Related Links section of the Incident form, which needs three conditions to be met:

The selected CI is of type Device.
The DEX plugin is installed on the instance.
The DEX agent is installed on that CI.

DEX itself requires a separate entitlement, so the link will not appear on every instance.

Device data on its own has limits, which are set out in why endpoint data alone does not close an incident.

4. Past Incidents From the Same Employee

ServiceNow offers three ways to see whether the employee has raised the same issue before.

Related incidents icon: appears beside the Caller field once the field is populated and lists other incidents for the same caller.
Incidents by Same Caller related list: a second route, although an administrator may need to configure the form to display it.
User's Task related list: where the form shows it, lists the other tasks created for the requester, such as incidents, problems, change requests and requests.

A recurring symptom is a signal to read the earlier resolution before connecting, rather than starting the diagnosis again from the beginning.

5. Steps Already Tried on the Incident

ServiceNow defines Work notes as information about how to resolve the incident or the steps taken to resolve it. Reading them first stops the technician from repeating a step that has already failed.

ScreenMeet session records can be related to the parent record and opened from its related records list, and each record has four parts:

Details: general session information such as the session PIN, the agent, status and termination reason.
Session Logs: events such as the agent joining, remote control being granted, shortcuts being executed and chat transcript activity.
Device Information: the device the agent connected to during the session.
Attachments: recordings and file transfers, where these are configured to attach.

Work done from the Tanium console can reach the incident as well, because a Tanium audit log can be sent to the ServiceNow incident work notes with one click. This item is only as useful as the documentation the previous session left behind, a point the final sections of this guide return to.

6. Linked Outages, Problems and Changes

Before treating the incident as a single-device fault, the technician should check three places in ServiceNow.

Dependency view: next to the Configuration item field, shows what is impacted and whether other CIs or services are experiencing issues, and lets the technician view tasks attached to the CI.
Outages and Child incidents: where the form shows them, list related outages and child incidents, and ServiceNow resolves child incidents when the parent is resolved.
Problem, Change Request and Caused by Change: related-record fields on the form, where Caused by Change holds the change request that resulted in the incident.

A linked outage, problem or recent change is a reason to check with the owning team before opening a one-to-one session.

7. Known Fixes for the Reported Symptom

Before connecting, the technician should check whether a documented resolution already exists in the knowledge base or in earlier incidents with the same symptom. That search has a limit, because it can only match the words the employee typed into the incident.

The device's actual state stays out of view until the session opens, and the next section covers what changes at that point.

8. Access Mode and Employee Consent

ScreenMeet for Tanium supports two access modes, and the mode decides what the employee sees.

Attended mode: the endpoint user must accept the connection.
Unattended mode: authorized IT and security personnel can access endpoints without user permission.

On Mac, only attended mode is currently supported in ScreenMeet for Tanium, and the endpoint user must grant the appropriate permissions. ScreenMeet Remote Support also includes consent tracking with customizable terms and full audit trails, so the technician should know which consent step the employee will see.

The differences between access models are covered in types of remote access, and devices with nobody present are covered in secure unattended access.

Two Things a Technician Can Only Learn Once the Remote Session Opens

The eight items above can all be checked without touching the device. The next two answers cannot, so the session itself has to supply them as early as possible.

Live Device State

CMDB data from a connector arrives through scheduled import jobs, as ServiceNow describes for the Service Graph Connector for Tanium. The ScreenMeet System Info panel shows the device inside the live remote support session instead, including:

Windows edition, release ID and build number
Manufacturer, model and device name
Organization and domain details
CPU type, total and available memory
Network type and adapter information
Monitor count, resolution and device serial number

ScreenMeet's Discover agent inventories the end-user device in seconds, covering errors, processes, configurations and environment state. The Discover, Analyze and Document phases are set out in the MTTR Reduction Field Guide.

Matched Fixes

A fix worth trusting is one matched to what the device is actually doing, not only to how the employee described the problem. ScreenMeet's Analyze agent correlates symptoms to root causes and surfaces recommended fixes before the technician starts troubleshooting.

The technician still owns the outcome, reviewing the AI-generated analysis, making the judgment call and applying the solution.

ScreenMeet AI Assist adds context-aware remote support during the session, with guidance specific to the operating system and environment being supported. AI Assist also improves its recommendations based on previous resolutions across the organization, which ties the live session back to item seven.

Why Pre-Session Context Breaks When the Remote Tool Sits Outside ServiceNow

The checklist only pays off when the session starts from the same record the technician has just read. ScreenMeet describes legacy remote support systems as operating separately from the ITSM platform, creating disconnected workflows that lack critical incident context.

A separate tool makes the technician rebuild the picture in another console, and it keeps the session's findings out of the incident the next technician will read. Derek Chase, Executive Director at TTEC, put the alternative in a single line: "They stay all within ServiceNow the entire time."

The full architecture comparison is in native vs. standalone remote support, and the cost of moving between tools is covered in how to reduce context switching.

How a Session Launched From the Incident Keeps Both Pictures in One Record

The working model follows the checklist in order: the technician reads the eight items in the incident, launches the session from the same incident and sees the live device state once it connects.

ScreenMeet supports one-click launch from ServiceNow, Salesforce or Tanium interfaces, with automatic documentation of all session activities directly in incidents or tickets. ScreenMeet AI Summarization adds summaries to ServiceNow incidents and supports custom fields for resolution methods, root causes and next steps.

That summary becomes item five for the next technician who opens a similar incident, and Now Assist can draw on the same record downstream. This is AI and modern support working as one loop, with AI handling discovery and documentation inside the incident while the technician keeps the judgment call.

Liran Daniel of ServiceNow's Employee Experience Innovation team described the goal as an experience "like a plane cockpit with all the buttons in front of us."

TTEC standardized remote support by embedding ScreenMeet directly into ServiceNow, and its average handle time dropped from over 45 minutes to under 28 minutes. ScreenMeet states that its remote support software serves over 25,000 agents and more than 500 million end-users.

FAQs About Preparing for a Remote Support Session

1. What should a technician check before starting a remote support session?

A technician should check eight things: employee identity and contact channel, reported symptom and priority, the affected device, past incidents from the same employee, steps already tried, linked outages, problems and changes, known fixes and the access mode. Seven of these items live in ServiceNow, and the eighth depends on how the session will connect.

2. Where does a technician find device information before a session in ServiceNow?

The Configuration item field on the incident points to the affected CI in the CMDB. In instances that use the Service Graph Connector for Tanium, that CMDB data includes hardware, software and software usage imported from Tanium.

3. What is context-aware remote support?

Context-aware remote support gives the technician guidance specific to the operating system and environment being supported during the live session. ScreenMeet AI Assist provides this guidance inside ServiceNow, while the Discover and Analyze agents add a device inventory and recommended fixes.

4. Does the employee have to approve a remote session?

In ScreenMeet for Tanium, attended mode requires the endpoint user to accept the connection, while unattended mode allows authorized IT and security personnel to access endpoints without user permission. On Mac, only attended mode is currently supported, and the endpoint user must grant the appropriate permissions.

5. Where can a technician see what happened in an earlier remote session?

Earlier ScreenMeet sessions can be related to the parent record and opened from its related records list in ServiceNow. Each session record shows Details, Session Logs, Device Information and Attachments for that session.

Run the Eight-Item Check From Inside the Incident

Seven of the eight items a technician needs already sit in ServiceNow, while live device state and the matching fix arrive only once the device connects. A session launched from the incident puts both pictures in one record, and its documented outcome becomes the starting checklist for the next technician.

See how ScreenMeet launches remote sessions from the ServiceNow incident.