ServiceNow Now Assist for ITSM: Roles, Responsibilities and RACI

Understanding Now Assist for ITSM Roles and Structure

Now Assist for ITSM gives agents generative help: it summarises incidents and chats, drafts resolution notes and knowledge articles and answers questions conversationally, while classification and routing predictions come from Predictive Intelligence. Success depends on clear roles and responsibilities—who owns Now Assist configuration, who validates AI recommendations, who handles exceptions when AI doesn’t understand a request, who escalates complex issues. In organizations with strict audit requirements, documenting roles and decision authority is critical for compliance and change control.

A typical role structure includes platform administrators (configure Now Assist, enable skills and their data sources), service desk supervisors (validate AI recommendations, handle exceptions), IT operations (provide training data and feedback), audit and compliance teams (verify AI decision quality and bias), and service desk agents (use AI-assisted tools to resolve tickets faster).

Platform Administration and AI Configuration

Platform administrators configure Now Assist—selecting which AI features to enable (auto-categorization, intent detection, response suggestions), setting up knowledge articles for AI to reference, choosing the knowledge sources and record fields the skills draw on, and monitoring output quality. These decisions affect all downstream work, so administrator role scope should be defined clearly with appropriate approval for major configuration changes.

Questions to clarify: Who decides which AI features are enabled? Does enabling a new AI feature require security review? Who trains the AI model? Who monitors AI accuracy and retrains when performance degrades? In organizations with strict change control, plan approval gates for significant Now Assist configuration changes.

Service Desk Supervisor Authority and Escalation

Service desk supervisors review AI recommendations and decisions, especially for critical or unusual tickets. When Now Assist suggests categorization or routing that doesn’t seem right, supervisors can override. When tickets are too complex for AI, supervisors escalate to senior engineers or specialized teams. Supervisor authority should be defined—what recommendations require supervisor approval? When can supervisors override AI decisions?

A clear model: agents use AI suggestions for straightforward tickets (network connectivity, password resets). Supervisors review AI decisions for tickets that AI rates as uncertain or for first-time categories. Complex tickets bypass AI and go to senior engineers. Escalation paths should be documented so agents know when and how to escalate.

IT Operations and Training Data Ownership

Now Assist learns from historical ticket data—past tickets, resolutions and outcomes. Quality of training data directly affects AI accuracy. IT operations teams own this data—they know what tickets should look like, what categorizations are correct, what resolutions are appropriate. When AI makes mistakes, often the training data needs improvement (historical tickets were mislabeled, certain scenarios weren’t represented in training data).

Ownership questions: Who validates that historical ticket data is accurate and properly categorized? When AI makes systematic errors, who investigates and retrains? How often should training data be refreshed? Does every agent correction to AI suggestions flow back into training data? Clear ownership ensures AI performance improves over time rather than degrading.

Audit and Compliance Oversight

Organizations with strict audit requirements need oversight of AI decisions. Common questions: Is Now Assist applying policies consistently (does it categorize similar tickets the same way)? Are there biases in AI decisions (does it route tickets differently based on requestor, language or other factors)? Are audit trails complete (can we see why AI made a decision)? Does escalation to human review happen when needed?

Audit team role: review AI decision patterns quarterly, test for consistency and bias, verify audit trails are complete, validate that appropriate escalation happens for complex cases. Document findings and remediation. In heavily regulated environments, audit of AI decisions may be a formal control with evidence requirements.

Service Desk Agent Guidance and Feedback Loop

Agents use AI recommendations daily. They need clear guidance: when to trust AI suggestions, when to question them, how to provide feedback on suggestions. A practical model: agents use AI suggestions as a starting point, validate against ticket details, accept or override as needed. Overrides feed back into system for retraining.

Questions to clarify: How do agents know when AI is confident versus uncertain? Should uncertain suggestions be marked differently? How do agents report AI mistakes or provide feedback? Does every override flow back into training? Clear feedback loops help AI improve—otherwise, if agents just ignore bad suggestions, AI never learns.

Change Control and Escalation Paths

Changes to Now Assist configuration can affect service desk quality. Significant changes should go through change control: what change, who authorizes it, how is it tested before production? Emergency fixes (disable a broken feature) should have expedited approval. Regular enhancements (retrain AI on new knowledge articles) may have simpler approval.

Escalation paths should be documented: who escalates AI-related issues? Who makes final decisions on AI configuration? Who resolves conflicts between supervisors and AI recommendations? In audit-focused organizations, document these decisions and maintain records of approvals and outcomes.

Assign one accountable owner to every assist decision

Most ownership problems with an assistant in the service desk are not caused by a lack of people. They are caused by two people believing they own the same decision, or by nobody believing they own it. A RACI grid is the simplest tool for preventing both, provided it is written for the specific decisions an assistant creates rather than for general ITSM roles. The grid below is a starting point. Each row is a decision that a team will face within the first year of running suggestions, and each column is the role that answers for it. The Now Assist for ITSM overview describes the feature itself, so the grid can be checked against the features you actually plan to enable.

The table makes one distinction that many teams miss. The person who does the work and the person who answers for the result are often different, and the second person should not be one who can quietly change the setting that produced the result. A platform administrator can switch a feature on, but the decision to accept that risk belongs to the service owner, and that choice should be written down where an auditor can find it. Before a new suggestion type gets its row signed, the acceptance checklist for Now Assist is the place to look for the testing and acceptance steps the owner should review.

Working through the contested decisions

Three situations generate most of the arguments once a team is live. Each one has a clear sequence that avoids a meeting in the middle of an incident.

1. An agent believes a suggestion is wrong and a supervisor believes it is right. The agent records the override reason in the record, the supervisor’s decision governs that record, and the reason is tagged for the weekly review. Nobody edits the suggestion source during the shift.
2. A knowledge manager wants to retire a set of articles that the assist relies on heavily. Because the change alters suggestions across several queues, the service owner signs the change, and the platform administrator confirms the effect in a test copy before the change goes live.
3. A major incident is in progress and the assist is producing misleading summaries. The incident manager on duty has authority to disable the feature for that incident only. The platform administrator then makes the change, and the service owner reviews it the next working day.

When a grid is more structure than the team needs

A RACI is a tool for teams where the people who configure, use and audit the assist are different people. In a small service desk where one person administers the platform, runs the queue and reviews the output, a short grid is paperwork. The same principle still applies, though: that person should write down, in one place, which decisions they will make alone and which they will escalate. The grid becomes necessary when the first disagreement happens, and it is much easier to write before the disagreement than during it. Governance of changes to the platform more broadly follows the same logic, and the note on ServiceNow business rules governance covers the parallel case of server-side logic that already runs.

Questions that come up once the grid is agreed

Can a service desk lead switch off suggestions for their own queue?

Yes, and the grid should say so explicitly, because a lead who waits for approval to stop a misleading feature is more likely to let the problem run. The condition is that the lead records the change, tells the agents on the queue the same day and informs the platform administrator, so the setting is not left in an unknown state.

Who signs off a change to the knowledge the assist reads?

The service owner, on the advice of the knowledge manager. Knowledge changes feel low risk because they look like content edits. In practice they change which answers agents are shown, so they deserve the same visibility as a configuration change.

Do agents need a training record for the assist?

It is useful to record who has been trained on reviewing suggestions and who has not, because the people who review outputs are the control. A training record also protects the organization when an agent who was never shown the override process is blamed for an error that the process should have caught.

What happens to the grid when the platform owner leaves?

The grid should name roles rather than people, and the role should have a named deputy. When the person changes, the deputy takes the row and the service owner signs the handover. A grid that names individuals can quickly turn into a list of orphaned decisions.

Confirming the ownership model

The useful starting material is your current team chart, the list of queues the assist would touch and the people who would be asked to override suggestions in a live incident.