SLA Terms Business Hours from Location and WO

SLA Terms Business Hours from Location and WO

Today, we can configure SLA Terms based on Business Hours from Account /Product /Contract/custom. We need capability to configure based on Business Hours on Location and Work Order. We do not calculate Business Hours neither on Account nor on Service Contract but we have Time Zone available on WO and Location. So, We can calculate Business Hours based on Time Zone on WO and Location then configure SLA Term accordingly.

We have working on SLA Term setup in our Org for various use case. We can setup Global SLA term for Next 2hrs, 4hrs or 8hrs Response/Restoration SLAs. We setup a 24hrs Business Hours and we could use this Global SLA term for any country and any time zone or Business Hour without issues. “Restoration Customer By” and “Onsite Response Customer By” fields on WO are populated as expected.

We have run into an issue while configuring Next Business/Calendar Day Global SLA Terms. As per the SVMX design of SLA Terms/Clock functionality, we should have Business hours populated either on Account or Service Contract, which identifies the Business Hour of Account or Contract and sets “Restoration Customer By” and “Onsite Response Customer By” on WO with only one Global SLA term all Time zone. But, we are not updating Business hours either on Account or Service Contract to configure SLA terms based on Business Hours. Please find our use case below to configure SLA term for Next Business/Calendar Day to calculate Restoration Customer By on WO and start SLA clock accordingly.

Today, we should create a new SLA term for each Business hour to achieve this requirement. US would have 4 different Business hours for each time zone and we have more than 50 Business Hours setup in our system for different countries and regions. We should create 50+ SLA terms for Next Business Day and another 50+ for Next Calendar Day. Instead of creating one Global SLA Term per each SLA. This creates more problem/confusion while Contract setup to select appropriate SLA terms for their region/country.

We populate Customer Time Zone on WO from Location while creation. We can derive Business Hours Based on Time zone and populate on Location or WO. But, SLA Term configuration does not give option to choose Business Hours from Location or WO.

Line Chef xrguy1
Line Chef

An additional challenge that exists is for specific SLA which are not linear hours. Next Day or Next Business Day as examples. If we promise our customer that we will have someone onsite the Next Day, we are not late until we pass midnight, local time the following day. If I have a work order that is opened at 9AM and another that is opened at 7PM and both have Next Day SLA, the number of hours from WO creation until SLA Deadline is different. They both terminate at Midnight the following day. ServiceMax allows for fixed number of hours from creation to deadline and has the ability to pause if outside business hours, but in this example, it would be 39 hours for the WO opened at 9AM and 29 hours for the one opened at 7PM. In both cases, we need to be able to identify when midnight local is in GMT

Product Team
Product Team

Hi Mike!

A little belated, but I wanted to let you know that we are introducing 'Next Business Day' functionality into SLA terms configuration in the coming 19.2 release. We will be adding a unit of measure of 'day' for each Term tab, as well as an expected "cut off" time during the day that will tell the SLA Term to extend the SLA calculation to the next day and when that clock should stop. For those who wish to retain 'minutes' as their unit of measure, that option will remain the default.


Lacy Cotton-Hodgson

Product Team
Product Team

@deirdre_yee  - looks like this Idea was mistakenly migrated to the Community Archive. Can you please move it to the Ideas Forum so I can track updates on it? Thank you!

Product Team
Product Team
Status changed to: On The Roadmap
Staff Chef richard_lewis
Staff Chef

@lacy_cotton , please keep #PitneyBowes in the loop on development of this idea.

Regards, Richard