ServiceNow Now Assist for ITSM for Insurance

How Insurance Organisations Use Now Assist for ITSM

Insurance IT support teams handle both insurance-specific systems and general IT issues: policy administration systems, claims systems, email and collaboration platforms. When support agents work on incidents, they need quick access to knowledge: how to reset a policyholder portal password, how to onboard a new user in the claims system, how to troubleshoot application performance. Now Assist surfaces relevant knowledge and procedures in real time while agents work on incidents. Instead of searching a knowledge base manually, agents see suggested articles and procedures. This accelerates resolution and reduces handle time.

The decisions that make generated suggestions safe on an insurance service desk come before the first suggestion appears: which incident categories the assistant may touch first, what the knowledge base must contain for those categories, and how customer data is kept out of prompts and drafts. The sections below cover knowledge preparation, handling time and consistency, escalation of complex issues and continuous learning, then the rollout itself: measuring whether suggestions help or mislead, a procedure for the first category, and when to hold back.

Knowledge Base and Documentation for Insurance

Insurance IT operations have unique knowledge domains: policy administration systems, claims processing workflows, regulatory reporting systems. Now Assist must be trained on insurance-specific knowledge. Common issues include user access to policyholder portals, claims entry errors, regulatory report generation failures and premium calculation issues. The knowledge base should include how-to articles for each, troubleshooting procedures and escalation criteria for complex issues.

Insurance organisations often have regulatory requirements for how support is provided. Customer data must be protected. Interactions should be logged for compliance. Now Assist can help ensure these requirements are met by guiding agents through procedures. For example, when a customer calls about a claim, Now Assist can ensure the agent verifies the customer’s identity before discussing claim details.

Agent Productivity and Handling Time Reduction

Now Assist reduces handling time by presenting solutions quickly. An agent opening an incident about a user unable to access the policy portal sees suggested articles about portal access, common lockout reasons and reset procedures. Instead of searching the knowledge base or guessing the solution, the agent has a roadmap to resolution. Measure handling time before and after the change, and check separately that resolutions still match procedures.

Handling time reduction allows teams to handle more incidents with the same staff. Or it allows reduced staffing while maintaining service levels. The cost of implementing Now Assist is often recovered through productivity gains within months.

Quality and Consistency in Operations

Insurance operations must be consistent and compliant. All premium calculations must follow the same rules. All claims must be processed according to policy. All policy documents must contain required disclosures. Now Assist helps ensure consistency by guiding agents through standard procedures. Deviations are reduced. Quality metrics improve: fewer errors, fewer repeat issues, higher first-contact resolution.

Regulatory compliance is supported. If there is a procedure for handling data subject access requests or privacy complaints, Now Assist reminds agents of the requirement and guides them through it. Compliance is not accidentally forgotten because the procedure is front and centre when needed.

Escalation and Complex Issue Handling

Now Assist is not just for simple issues. For complex problems, it can guide escalation. If an agent is working on a claims system issue and the issue exceeds their expertise, Now Assist recommends escalation to the claims system specialist team. The escalation includes context gathered by Now Assist so the specialist does not have to re-investigate. Escalations are more productive because preparation is done by the first agent.

For issues that require management decisions, Now Assist identifies decision criteria and escalation authority. If a customer dispute requires adjustment outside policy, Now Assist surfaces the escalation procedure and decision authority so the request reaches the right person.

Continuous Learning and Improvement

Now Assist learns from interactions. Articles that are frequently accessed are popular and working well. Articles rarely accessed might not be helpful or discoverable. Feedback from agents about suggestion quality helps tune recommendations. Over time, Now Assist becomes more effective as it learns your environment and the issues agents encounter most frequently.

We help your knowledge team maintain and improve the knowledge base. As new issues emerge, they are documented. As processes change, documentation is updated. As Now Assist is used, gaps are identified and filled. The knowledge base becomes a living asset that grows as the organisation learns.

Deciding which incident categories Now Assist should touch first

Start with the question of which incidents an agent will see suggestions for, not with whether the feature is switched on. An insurance IT desk often works one queue that carries portal password resets, access requests for the claims platform and slow reports requested by the actuarial team. Each category has a different knowledge owner, a different level of sensitivity and a different cost when a suggestion is wrong. A suggested service restart is a minor issue on a laptop and a serious one on a policy administration server. Sorting categories by those three properties gives a rollout order a service owner can defend in front of finance and compliance.

Category	What the knowledge must do	Cost of a wrong suggestion	Suggested starting position

Portal password and lockout	Give a repeatable reset path with identity checks	Low to moderate	Good first candidate

Claims platform access changes	Match the role rules in the access procedure exactly	Moderate	Advisory only, reviewed by a senior agent

Outages on core policy systems	Point to the right runbook for the failing component	High	Keep suggestions read-only until runbooks are validated

Regulatory report data requests	Name the data owner and the sign-off step	Moderate to high	Defer until data owners confirm the steps

Preparing the knowledge base before the first suggestion appears

Now Assist can only recommend what the knowledge base holds, which is why the knowledge management setup for ITSM should be reviewed before the feature is switched on. Some insurance teams find that their articles were written by a specialist for other specialists, with shorthand that assumes system access the reader does not have and with the regulated step buried halfway down. Before the feature goes live for a category, ask a knowledge author to take three real incidents from the previous quarter and check whether the top-ranked article would have resolved each one without a phone call. Any article that fails that test needs rewriting or retirement before it reaches the top of a suggestion list.

Watch for articles that describe a procedure which has since changed. A suggestion that quotes a retired claims workflow can do more damage than no suggestion, because the agent is inclined to trust a recommendation that appears inside the incident form at the moment of need. Assign each article a named owner and a review date, and make the review date visible in the list the feature uses. The article lifecycle guidance covers the retirement step in more detail.

Keeping customer data out of the wrong places

Incident text in insurance often contains policy numbers, claimant names, health details written into claim notes and bank references pasted by mistake. Decide before rollout which incident fields the feature may read when it builds a suggestion or a summary, and which fields are excluded. Confirm with the privacy team how generated summaries are stored, who can open them later and how long they remain. The exclusions are a platform design decision owned by the service owner and the privacy lead. An agent who is told to be careful is not a control.

Measuring whether suggestions help or mislead

Handle time is often the figure sponsors ask for, yet it is also one of the easiest figures to distort. A faster incident closed with the wrong fix produces a repeat ticket later, and the repeat can be booked against a different team. Read handle time next to reopen rate for the same category, the share of suggestions an agent accepts without editing, and the override reasons an agent records when they reject one. The override reasons can be the most useful signal the feature produces, because they name the gaps the knowledge base does not cover.

Signal	What it shows	Action when it moves the wrong way

Reopen rate for the category	Whether the accepted fix held	Review the article that supplied the fix

Acceptance without edit	Whether agents trust the suggestion as written	Check that the steps still match the current process

Override reasons	Where the knowledge base has no answer	Route to the article owner for a new or revised article

Escalation after a suggestion	Whether the agent was steered into the wrong queue	Tighten the escalation criteria in the article

A rollout procedure for the first category

1. Choose one category that has a named knowledge owner, using the governance model for Now Assist, which covers human oversight of AI assistance, to agree who approves the choice and a success measure the service owner accepts in advance.

1. Pull the previous quarter’s incidents for that category and mark which article would have solved each one.

1. Rewrite or retire the articles that failed the test, then have a second author check each rewritten procedure against the live process.

1. Confirm which incident fields the feature may read, and record the exclusions in the design notes.

1. Run the feature for a trial period the service owner sets, with a senior agent reviewing every suggestion made to a junior agent.

1. Compare reopen rate and override reasons with the period before the feature was on.

1. Widen to the next category only when the first shows a stable reopen rate and the owner accepts the findings in writing.

When to hold back

Hold back when the knowledge for a category is thin and no owner has time to repair it, when the procedures are changing because a system migration is under way, or when the steps that touch regulated customer handling have not been approved by compliance. In those conditions a well-filtered search serves the agent better than a suggestion that sounds confident and has nothing behind it. A useful rule is that the feature should never be more certain than the article it quotes. Insurance teams that want a sector view of the same question can start from the insurance knowledge management page.

Questions raised after the rollout plan is agreed

Should suggestions also appear to customers in the portal?

Not in the first phase. Customer-facing text carries different disclosure and accuracy obligations from agent-facing text. Keep the first rollout inside the agent workspace, and decide later whether an article can be published to the portal, after a review focused on the wording a customer would read.

What if agents ignore the suggestions altogether?

Low use can point to placement rather than to the quality of the recommendation. Check whether suggestions appear before the agent has already started typing a resolution, and whether article titles match the words an agent would use in the incident description. Agents tend to ignore suggestions that look like the results of a generic search.

Who owns a bad suggestion once an agent has seen it?

The knowledge owner owns the article and the service owner owns the category. Log each bad suggestion with the article identifier and the override reason, so the fix is routed to the owner rather than sitting in a general backlog that nobody reads.

How does this differ from a search box on the knowledge base?

A search waits for the agent to describe the problem well. A suggestion reads the incident’s own text and fields, so it can surface an article the agent would never have thought to search for.