When a Change Request’s risk score comes back Medium or High, CAB reviewers get a bare number with no reasoning behind it. Teams then burn time manually digging through risk calculation inputs just to understand why, which slows down approvals and drags out CAB meetings.
The team built the Change Risk Explainer to close that gap. It automatically evaluates a Change Request’s risk using real historical change performance, then writes the reasoning straight into the record instead of leaving reviewers to reconstruct it themselves.
How it works
Five chained AI Agent Studio tools take a Change Request from raw data to a written risk verdict with no manual research required: fetch the change request details, fetch the risk factor configs, pull the assignment group’s historical change data, calculate the risk using a Now Assist skill, then update the change request with the result.
The scoring itself comes from a Risk Factor Config table rather than hardcoded logic, tracking categories like exceeding planned end dates and unsuccessful change rate, each with its own evaluation logic, thresholds, and weight. One config, for example, counts how many of an assignment group’s changes finished later than planned over the last 12 months, with a weight of 2 and a high-risk threshold of 4. Business users can tune that logic by editing a config record, not by touching code. ServiceNow’s out-of-the-box risk calculator only outputs a number from hardcoded scripts. Pairing that config-driven scoring with a Now Assist skill that reasons over real change history is what turns a black-box score into something explainable.
Why it matters
A risk score with no context forces every reviewer to either trust it blindly or go dig up the history themselves. Neither is a good use of a CAB meeting. Writing the plain-English reasoning straight into the Change Request’s Risk Evaluation field means every reviewer gets the same instant context instead of researching an assignment group’s change history from scratch each time.
Grounding the score in actual unsuccessful-change and missed-deadline data also does something quieter but just as valuable: it reduces subjective, inconsistent scoring, since two similar changes from the same assignment group now get evaluated against the same real numbers instead of a reviewer’s gut feel. Because new risk factors are added through a config record instead of new code, the same logic scales across every assignment group and business unit without a developer in the loop. There’s a CMDB angle too. Running this kind of evaluation during change planning gives teams a natural opportunity to validate configuration relationships they might otherwise not look at until something breaks.
What the pilot showed
The pilot’s Risk Factor Config table shipped with two categories live: Exceeded End Dates and Unsuccessful Change Rate, each independently configurable with its own threshold for moderate versus high risk. Tested against a live Change Request, the tool correctly walked through its five-step chain, from an emergency change with no risk evaluation yet populated to a scored, explained record ready for CAB review, without anyone needing to open a report or dig through related lists by hand.
Change Risk Explainer is one way to bring reasoning back to a change risk score. If yours could use the same solution, reach out to KeenStack.
Built by:
Adam Chapman
Michael Sumner
Kishore Ramachandran