Agents juggled knowledge, device consoles, and approvers; ServiceNow copilot surfaced runbooks, Intune/Jamf history inline

Overview

An airline’s helpdesk agents spent valuable minutes hunting through knowledge articles, device tools, and approval checklists while customers and crew waited on the line. Procedures lived in multiple places, permissions varied by role and location, and required approvals were not obvious inside the ticket. Intelligex implemented a permissions?aware support copilot embedded in the ITSM that surfaced active runbooks, device history, and approval steps directly in the incident workspace. Agents handled calls with fewer context switches, escalations dropped, and resolutions followed the same steps every time—while ServiceNow, identity, device management, and knowledge systems stayed in place.

Client Profile

• Industry: Commercial aviation
• Company size (range): Global airline operations with airport, crew, and corporate support
• Stage: ServiceNow for IT Service Management and knowledge; device management via Microsoft Intune and Jamf; SSO with Azure AD/Okta; runbooks split between ServiceNow Knowledge and Confluence; approvals managed through ServiceNow workflows
• Department owner: IT & Infrastructure (Service Management and End?User Computing)
• Other stakeholders: Airport Operations, Flight Operations, Crew Services, Network/Telecom, Security and Privacy, Compliance, Vendor Support, Internal Audit

The Challenge

Agents lost time jumping between tabs to find the right procedure, device context, and approver. A password reset for a gate device, a crew tablet enrollment, or a flight planning tool issue each required different sources: wiki pages for steps, device history in a management console, and a separate page for who could approve an access change. During peak operations, these lookups stretched call times and led to handoffs when agents could not confirm the exact next step or required authorization.

Knowledge and approvals were not consistently applied. Runbooks existed but were buried under multiple versions, and the ticket interface offered little guidance about which steps matched the caller’s role, location, or device type. Approvals lived in separate workflow routes and were easy to miss, which caused rework when a change required additional sign?off. New agents learned by shadowing, so consistency varied, and audit reviews found gaps between the documented process and what happened on calls.

Why It Was Happening

Information was fragmented and not surfaced in context. The ITSM carried tickets and some knowledge, device tools carried history, and identity systems knew roles and locations—but none of these signals were combined for the agent at the moment of support. As a result, agents searched across systems and made judgment calls about which runbook applied, which approvals were required, and whether a device had known issues.

Ownership and timing were split. Platform teams maintained the knowledge base, Endpoint Engineering managed device consoles, and Service Management owned workflows. Without a unified, permissions?aware experience inside the ticket, the best information stayed hidden behind links and sign?ins, and calls took longer than necessary.

The Solution

Intelligex delivered a support copilot inside the ITSM incident workspace that assembled the right procedure, device context, and approvals for the agent’s current ticket. The copilot used requester, location, and device signals to select the active runbook, pulled device and ticket history into a compact view, and showed approver steps with one?click routing. Answers included citations to knowledge sources, and content was masked based on the agent’s permissions. Drafted guidance relied on retrieval?augmented generation patterns with links to the underlying sources for transparency (see Retrieval?Augmented Generation). The experience lived in ServiceNow’s agent workspace and reused existing approvals and knowledge tooling (ServiceNow Docs), with device context from Microsoft Intune and Jamf (Microsoft Intune, Jamf Pro).

• Integrations: ServiceNow incident and knowledge modules; CMDB device and service records; device management (Intune/Jamf) for device health and history; identity (Azure AD/Okta) for roles and locations; approval workflows in ServiceNow; Confluence for supplemental runbooks; SIEM for copilot audit logs.
• Context panels: Ticket?aware runbook view with steps filtered by role and location; device summary with recent incidents and policy compliance; approval panel with required approvers and one?click routing.
• Knowledge retrieval and citations: Answers assembled from approved articles and runbooks with inline citations to source pages; suggestions to update or merge duplicates when content drifted.
• Permissions and privacy: Responses limited by agent’s entitlements; masking for sensitive fields; redaction in logs; channel?specific rules for airport and crew data.
• Workflow actions: Embedded actions to trigger approvals, open device tasks, and attach evidence; resolution notes pre?filled from the executed steps and citations.
• Governance and freshness: Article expirations surfaced during retrieval; stale or conflicting content flagged to owners; maker?checker gates for high?risk topics.
• Dashboards: Time in ticket, escalation trends, runbook usage, stale content, and approval bottlenecks; drill?downs to calls and articles used.

Implementation

• Discovery: Mapped high?volume call types and target runbooks; inventoried knowledge sources and approval paths; reviewed device data available from Intune and Jamf; sampled recent escalations and audit findings; gathered privacy constraints for airport and crew data.
• Design: Defined context signals (role, location, device, service); authored retrieval rules and article templates; mapped approval rules to runbook steps; designed permissions and masking; planned workspace panels, quick actions, and dashboards.
• Build: Integrated ServiceNow incident, knowledge, and approvals; connected CMDB and device management for device context; implemented retrieval with citations and masking; added quick actions for approvals and device work; enabled logging and evidence capture in the SIEM; configured dashboards.
• Testing/QA: Ran in shadow mode, showing suggested steps without changing workflows; validated permissions and masking; piloted with airport and crew support queues; tuned retrieval rules and approval mappings based on agent feedback.
• Rollout: Enabled the copilot for selected call types first; expanded coverage by queue and shift; retained manual search and approval paths as a controlled fallback; tightened content rules after stable cycles.
• Training/hand?off: Delivered short clinics for helpdesk and field techs on using panels, triggering approvals, and citing articles; published writer guidelines for runbooks; updated SOPs for resolution notes and article updates; transferred ownership of retrieval rules and dashboards to Service Management under change control.
• Human?in?the?loop review: Established a content council to review usage patterns, stale or conflicting articles, and approval friction; decisions recorded with rationale and effective dates; updates flowed back into runbooks and retrieval rules.

Results

Agents spent less time searching and more time resolving. The copilot surfaced the correct procedure based on the caller’s role, location, and device, pulled recent device history into view, and showed exactly which approvals were required. Escalations declined because first?line agents followed the same, current steps, and approvals moved faster when they were triggered from inside the ticket with the right context attached.

Consistency improved. Resolution notes cited the articles used, making handoffs and post?incident reviews faster. Stale or conflicting runbooks were flagged automatically, so content owners kept high?traffic procedures fresh. The airline kept ServiceNow, identity, device management, and knowledge tools; the change was a permissions?aware copilot that assembled the right answers and actions inside the ticket.

What Changed for the Team

• Before: Agents searched across knowledge, device tools, and approval wikis. After: The ticket workspace surfaced runbooks, device history, and approvers in one place.
• Before: Steps varied by agent. After: Runbooks applied consistently, filtered by role, location, and device context.
• Before: Approvals were easy to miss. After: Required approvals appeared inline with one?click routing and evidence.
• Before: Resolution notes were free?form. After: Notes referenced executed steps with citations to articles.
• Before: Content drifted quietly. After: Stale or conflicting procedures were flagged and routed to owners.
• Before: New agents relied on shadowing. After: The copilot guided them with the same steps experienced agents used.

Key Takeaways

• Put guidance where work happens; assemble runbooks, device context, and approvals inside the ticket.
• Use context to filter steps; role, location, and device signals narrow procedures to what matters.
• Cite sources; link answers to approved articles to build trust and simplify reviews.
• Make approvals part of the flow; trigger and track sign?offs without leaving the incident.
• Protect privacy; enforce permissions and redaction as part of retrieval and logging.
• Integrate, don’t replace; keep ITSM, identity, device management, and knowledge—add a copilot layer on top.

FAQ

What tools did this integrate with? The copilot lived in the ServiceNow agent workspace and leveraged incident, knowledge, and approvals (ServiceNow Docs). Device context came from Microsoft Intune and Jamf Pro. Identity and permissions used the existing provider (Azure AD or Okta). Retrieval patterns followed RAG concepts, with citations back to ServiceNow Knowledge or Confluence.

How did you handle quality control and governance? Only approved knowledge sources were indexed. Answers included citations to the exact articles used, and sensitive fields were masked. Maker?checker approvals applied to high?risk procedures. Runbooks carried owners, expirations, and last?reviewed dates. All copilot interactions, approvals, and content updates were logged and available for audit.

How did you roll this out without disruption? The copilot first ran in shadow mode, suggesting steps without changing workflows. Pilots with selected queues tuned retrieval rules, permissions, and approval mappings. After stable cycles, the copilot was enabled for those call types, and the manual paths remained available as a fallback during early adoption.

How did permissions and privacy work? The copilot respected the agent’s entitlements from the identity provider. Responses were scoped to what the agent could normally view in knowledge and device systems. Redaction rules masked sensitive data in answers and logs, and channel?specific policies covered airport and crew contexts.

Did this replace the knowledge base? No. The copilot surfaced and cited existing content; it did not become a new repository. Content owners continued to manage articles in ServiceNow Knowledge and Confluence. The copilot helped agents find and apply the right steps and flagged stale or conflicting content for review.

How were approvals surfaced and tracked? Required approvals appeared inline with the runbook steps, and agents triggered them from the incident. The workflow attached approver context and evidence to the ticket, updated status automatically on approval or rejection, and recorded the full trail for audit.