SLA Breach Scoring

[Brian Sorensen]

Ok, so here is an odd one that we are looking to create a custom scoring metric for.

Here is the basic idea.

When an incident is flipped to closed, we want to interject a score we have predetermined based on the SLA percentage of Business time

So the idea is 

if the percentage passed is under 25% - 5 points

26-50% - 4 points

51-75% - 3 points

76-100% - 2 points

Breached - 1 point

My initial thought was to use a flow to do this, but open to ideas on what you think

[Dr Atul G- LNG]

Hi @Brian Sorensen 

(function executeRule(current, previous /*null when async*/) {

var color = '';

// Only run for Incident SLAs

var taskGR = current.task.getRefRecord();

if (taskGR.getTableName() != 'incident') {

return;

}

// Find all Resolution SLAs for this Incident

var slaGR = new GlideRecord('task_sla');

slaGR.addQuery('task', current.task);

slaGR.addQuery('target','resolution');

slaGR.query();

while (slaGR.next()) {

if (slaGR.has_breached == true) {

color = 'Breached';

break; // No need to check further if breached

} else if (slaGR.business_percentage >= 75 && slaGR.business_percentage < 100) {

color = 'Warning';

} else if (slaGR.business_percentage < 75) {

color = 'Within SLA';

}

}

// Update parent Incident

if (taskGR.isValidRecord()) {

taskGR.u_sla_code = color;

taskGR.update();

}

})(current, previous);

Might be helpful. Make changes as per need.

[Mark Manders]

Create a custom field and use a variant of the script @Dr Atul G- LNG shared to fill the field. 

Although I do agree that SLAs shouldn't be breached, I don't really think gamifying this will help. It will result in less well documented solutions, because speed matters more than outcome, so I hope you can prevent that somehow. 

It will, in the end, also lead to a higher level of pressure on the team(s). People picking up harder tickets (yes, cherry picking will be a result of this) will end up with lesser points, even though they did the hard work.

And, especially now all kinds of AI solutions are changing the work-field, it will end up in getting new SLAs, because everyone is working hard to get many points. Corporate sees that SLAs of 3 days are always made within 2 and change it to 2 days, asking clients for a premium because of shorter resolution times, bringing in more money for the company and overworking the servicedesk. The requirement comes from management and management works for the company, not for the workers. Be aware of that.

[Uncle Rob]

Whatever method you're going for, remember:  Task does not have a one-to-one relationship with SLA records.
There are a few very good reasons why there might be many justified task_sla records per task... including:
- Multiple types of promises (response vs resolution)
- Internal vs external expectations (remember that OLA's are just SLAs of a different type)