Request for Report Enhancements – Incident Age Breakdown

[CV1]

Hi All,

We have a requirement to create a report that provides a detailed breakdown of incident age statistics.

The goal is to clearly distinguish time spent actively working by staff versus time spent waiting on customers.

The request includes two components:

1. A report grouped by overall incident age

2. A further breakdown showing how that age is distributed between:

   • Time spent by staff

   • Time waiting on the customer

We are looking for guidance on whether this type of reporting is possible. If so, we would appreciate direction on how best to implement it.
TIA

[Vikram Reddy]

Hey @CV1,

Yes, both pieces are doable natively, and honestly they come from two different corners of the platform rather than one single feature, so it's worth treating them separately.

For the overall age breakdown, don't build a custom age field. ServiceNow already has Report Ranges (the sys_report_range table, under Reports > Administration > Report Ranges) which exist specifically to bucket a date field into intervals like 0-7 days, 7-30 days, 30+ days for charting. There's an out of box global range set up against sys_created_on that most orgs use as the starting point for exactly this kind of "how old are our incidents" bar chart. Build your report on Incident, group by that range against opened_at (or sys_created_on), and you get the age distribution without any scripting. If the default buckets don't match what your stakeholders want to see, clone the range and tweak the day boundaries, it's a config change, not code.

The harder part is the staff-time versus customer-wait split, and the answer depends on what you've already got configured. If you're running SLA definitions on Incident with a pause condition (most orgs pause on state = On Hold with hold_reason = Awaiting Caller, which is actually the out of box configuration), you already have the data you need sitting on task_sla. The duration field there is the net elapsed time with pauses excluded, which is effectively your "time spent by staff" number, and pause_duration (or business_pause_duration if you want it schedule-aware) is your "time waiting on customer" number. Report on task_sla filtered to your Incident SLA definitions, group by the incident, and you can chart duration against pause_duration side by side. That gets you the second component without touching a single line of script, assuming the pause condition is already wired to the caller-waiting hold reason.

If you're not using SLA pause conditions, or your on-hold reasons aren't cleanly mapped to "waiting on customer," the other native route is a Metric Definition of type Field value duration on the incident's state or hold_reason field. Set it to start tracking when hold_reason enters Awaiting Caller and stop when it leaves, and the platform writes rows to metric_instance with the actual duration, no custom business rule needed to timestamp state changes. You can then report on metric_instance the same way, and subtract that from the total age to get the "worked by staff" side. This is the more flexible option if your hold reasons don't map cleanly to whatever your SLA pause condition already tracks.

Realistically I'd start with the SLA route if your pause condition already reflects "waiting on customer," since it's less setup and the data's already flowing. Reach for the Metric Definition approach only if the SLA pause isn't a clean proxy for what you actually want to measure. Either way, once you've got the two numbers on the incident (or joined via task_sla / metric_instance), a straightforward matrix or stacked bar report against your age ranges gives you the combined view leadership is asking for, no Performance Analytics license required for any of this.

Thank you,
Vikram Karety
Octigo Solutions INC