Non real-time Vendor SLA

[Gareth Davies1]

We have a vendor that doesn't update tickets in real time, we get a daily summary of which ones they fixed and when. I'm trying to set up an SLA for them but struggling to work out how to deal with the non real-time nature.

I can easily set up an SLA to start with retroactive start on the Vendor Opened field when Vendor is populated, that's not a problem.

Where it gets tricky is when we populate the Vendor Resolved field with the supplied fix time (up to a day after it was actually fixed) I want the SLA to recalculate and go into a retroactive pause (or stop, that would be fine) from that time.

What's my best way of accomplishing this? Is this even possible? I searched and found two threads from 2016 and 2022 but neither had a solution.

[Mark Manders]

This is not possible, OOB. The SLA engine starts on the start condition and ends on the end condition (which is a trigger on the form, not the content of a field).

What you could try (my PDI is sleeping, so didn't try it myself), is that you update your task_sla record on 'ticket.vendor_vendor_resolved' time !='' via a flow or business rule, also calculating the other values (repair sla won't work, because you don't have the trigger).

But the main question is: why do you allow your vendor to work like this? They are saying they did all of this, but you have no way of seeing this. In fact: if a ticket is logged with a resolution SLA of a day (which you communicate to your callers), that caller isn't informed on that until after the vendor tells you they fixed it yesterday. That means that the Service Level (agreed with your caller) has not been met, because your caller doesn't know about it and can't verify it. 

I think this is your vendors issue, not yours. They should let you know the moment something is resolved. You are now doing manual work so you can report that they are doing what they say they are doing, instead of you having any proof that this is the case. That's the world upside down.

[Kieran Anson · Accepted solution]

Agree with Mark here, it's not ideal that the vendor is sending you a belated list of SLAs which then don't allow you to fully ratify whether they're genuine or not. However, I empathise as I have had similar vendor difficulties where technical limitations prevent them from providing a more real-time value. A good example of this in the UK is postal-delivery confirmations (thinking DPD!); as a consumer you receive the parcel at your door, but receive an email confirming the delivery potentially upto an hour later....this could make or break an SLA.

Now ServiceNow does seem to have the capability (technically) to support a retroactive stop as the script include 'TaskSLA' (a wrapper for SLA glide records) has a function of setUpdateTime. 

Additionally, SLAs support SLA condition types which are script includes we (as users) can define whether a trigger point should be evaluated and passed in a more advanced way than the condition builder allows.

For this I created a script include called SLARetroactiveVendor. This checks for a field on the table of 'u_retro_end' and whether it has a value. If it does, then it calls the setUpdateTime to change the timestamp on the task_sla record. 

var SLARetroactiveVendor = Class.create();
SLARetroactiveVendor.prototype = Object.extendsObject(global.SLAConditionBase,{

	complete: function(taskSLA) {
		var conditionResult = false;

		//If the SLA definition has a stop condition, we also want to check it
		if(!gs.nil(this.sla.stop_condition))
			conditionResult = this._conditionMatches(this.sla.stop_condition);

		if(!gs.nil(this.task.u_retro_end)){ //u_retro_end is a date time field
			taskSLA.setUpdateTime(this.task.u_retro_end);
		}
		return conditionResult;
	},

    type: 'SLARetroactiveVendor'
});

HOWEVER - In order for this to work I had to make a very small modification to TaskSLAController to pass in the taskSLA variable (which is the instance of TaskSLA script include) to make it accessible. Although seamingly minor, modifying such a critical script include doesn't make me comfy.

The result, you can see from the below (1) the update time of the record is after the time I specified in my retroactive end, and similarly (2) the update time on my task_sla record is after my stop time.

DISCLAIMER: This would need to be extensively tested to check whether the calculated business time is even working as expected, and that there are no knock on issues

[Gareth Davies1]

You are a legend, thank you. I think on balance I agree with you that modifying a critical script like that is undesirable and I'm more likely to lean towards using PA instead of the SLA engine (driven by the values in the Vendor Opened and Vendor Resolved fields) for my particular use case.
But knowing that if we DID want to go down the SLA route that's how to do it is helpful.

[Mark Manders]

You could even create a metric for it, so you wouldn't have to create collector jobs and you could just report on it from there, including a related list, showing that metric on the record itself. No SLA, but still the calculations.