Improvement opportunities examples
Summarize
Summary of Improvement opportunities examples
This content provides practical examples of improvement opportunities within ServiceNow Zurich release, focusing on identifying workflow inefficiencies and SLA breaches through specific finding rules. These use cases help analysts monitor key process behaviors to optimize incident and task management.
Show less
Use Case 1: Record Bouncing Between Groups
- Scenario 1a: Detect records reassigned from an initial assignment group (e.g., Service Desk) to other groups and then back to the original group before resolution. This helps identify circular workflows that may delay resolution.
- Scenario 1b: Identify all records bouncing between groups with the same initial assignment group, tracking multiple reassignments to understand group handoff patterns.
- Both scenarios use start and end condition configurations based on the Assignment Group field, with duration tracking to measure time spent during these transitions.
Use Case 2: SLA Breach Detection
This scenario identifies all records in the 'New' state during an SLA breach period. The finding rule monitors state transitions and contextual SLA conditions:
- Start condition: Incident state is 'New' and SLA is breached (Made SLA is false).
- End condition: Incident state moves to 'Work in Progress' and SLA is made (Made SLA is true).
- Tracking duration helps analyze how long records remain in the 'New' state during SLA breaches, enabling targeted process improvements to reduce delays.
Use Case 3: Delay Between Parent State and Task Creation
This use case identifies records where more than six hours pass between the parent record entering 'Work in Progress' and the creation of associated tasks. This highlights delays impacting overall resolution time.
- Start condition: Parent incident transitions to 'Work in Progress' state (first occurrence).
- End condition: Task creation event occurs with a minimum delay of six hours.
- Duration tracking enables measurement of lag time, supporting initiatives to accelerate task initiation and improve service delivery.
Practical Application for ServiceNow Customers
By configuring these finding rules and conditions, ServiceNow customers can proactively detect inefficiencies such as repetitive reassignments, SLA breaches during key states, and delays in task initiation. This insight empowers analysts and managers to implement focused improvements, optimize workflows, and enhance overall incident resolution times.
The finding definitions use cases are described below.
Use case 1a: Record bouncing between groups. Analysts often want to identify records that go from a particular group (for example service desk), then reassign to another group, and eventually resolved by the initial group again.
- Start condition table config: incident
- Start condition
- Name: group name, for example, Service Desk
- Condition type: Field/value condition
- Field = Assignment Group
- Predicate = Is
- Field value = Service Desk
- Occurrence(s) to match: first only
- End condition table config: incident
- End condition
- Name: group name, for example Service Desk
- Condition type: Field/value condition
- Field=Assignment group
- Predicate= Is
- Field value = Service Desk
- Occurrence(s) to match: last only
- Track duration: true
Use case 1b: In case all bouncing records between groups with similar initial group must be identified, use the Message and category finding rule.
- Start condition table config: incident
- Start condition
- Name: Assignment group is anything
- Condition type: Field/value condition
- Field = Assignment group
- Predicate = Is anything
- Occurrence(s) to match: first only
- End condition table config: incident
- End condition
- Name: Assignment group is anything
- Condition type: Field/value condition
- Field=Assignment group
- Predicate=Is anything
- Occurrence(s) to match: all
- Track duration: true
- Relation constraint: Has the same assignment group
Use case 2: SLA breach. Show all records that were in the state New, while the SLA breach happened.
- Start condition table config: incident
- Start condition
- Name=state
- Condition type: Field/value condition
- Field=State
- Predicate=Is
- Field value=New
- Occurrence(s) to match=first only
- Contextual condition:
- Name=SLA breach
- Finding Def= Add the finding def message
- Condition type= Contextual field/value condition
- Field=Made SLA (make sure you have Made SLA defined as activity definition in your project)
- Predicate=is not
- Field value=true
- Relation: directly followed by
- End condition table config: incident
- End condition
- Name: State
- Condition type: Field/value condition
- Field=State
- Predicate=is
- Field value=Work in progress
- Occurrence(s) to match=first only
- Contextual condition:
- Name=SLA breach
- Condition type= Contextual field/value condition
- Field=Made SLA (make sure you have Made SLA defined as activity definition in your project)
- Predicate=is
- Field value=true
- Track duration: true
Use case 3: Longer than six hours between parent state Work in Progress and task creation. The resolution time or records often depends on the completion of one or more tasks. To improve the solution time of the main record, it’s therefore important to start the tasks as quickly as possible after the main records reached the Work in Progress state. In this example, the user wants to find all records where it took longer than six hours to create the underlying tasks after the main record went into Work in Progress. After giving the Finding definition a message and category, specify the finding rule as follows.
- Start condition table config: Parent, for example incident
- Start condition
- Name: First occurrence of Work in Progress
- Condition type: Field/value condition
- Field=State
- Predicate=Is
- Field value=Work in progress
- Occurrence(s) to match: first, only
- Relation: eventually followed by
- End condition table config: incident task
- End condition
- Name=incident task start
- Condition type=Process start
- Constraint: Minimum duration is 6 hours
- Track duration: true