Jump to content

Search the Community

Showing results for tags 'timers'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Hornbill Platform and Applications
    • OpenForWork
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • IT Operations Management
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
  • About the Forum
    • Announcements
    • Suggestions and Feedback
    • Problems and Questions
  • Gamers Club's Games
  • Gamers Club's LFT

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Organisation


Location


Interests


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype

Found 5 results

  1. We have an intermittent issue where all our escalation actions are trigger at once when a request has been on hold for significant period of time. This appear to be being triggered by the Escalation Actions conditions being evaluated before the requests response and resolution target dates are updated to take into account the on hold period. In our case we have escalation actions set at percentage of remaining resolution time as below, which we calculate and add into the appropriate service level as the appropriate durations. 80% 60% 40% 20% 10% 5% 1% Therefore when a request come of hold and the timers is restarted, you should only trigger the appropriate next action as the timer runs. However what we get is all the escalation actions triggering at ounce as the Resolution Target value being used in the evaluation is the value when it was put on hold, not the new recalculated value when the request comes off-hold. In the example above the request was taken from on-hold to open by a email applied from the shared mailbox, which then resulted in multiple escalation actions being triggered. Cheers Martyn
  2. @Steve G With reference to the "Request Import Utility", I can see there is a mapping for Priorities, but how do we map Service Levels and also populate/set timers? Cheers Martyn
  3. When configuring SLA response and resolution targets and expiry times on certain BP nodes you might find the target being set differently than possibly expected. This is because a common oversight as these timers needs to be expressed in SLC (Service Level Calendar) times or working hours or business hours (which are usually X hours/day) rather than calendar time (which is 24 hrs/day). When configuring a target time of N days, the value needed to be set would be N working days rather than N calendar days. The value that needs to be set will be obtained by multiplying N with the number of working or business hours/day. We advise to always configure hours (rather than days) as it is easier to figure out the values required to be configured for SLA targets or expiry times on business process nodes. However, in certain areas (e.g. SLA timers), depending on the target, it might not be always possible to use hours exclusively. Below is a quick example of how to find out which values needs to be configured depending on the intended target: Let's say we need to configure a resolution time (or an expiry time) of 5 days. We need the target to be set in 5 days from now. Let's also say the working hours are 7.5 hours/day although this really depends on your SLC. Step 1 is to find out the number of working hours equal to the 5 days we need to set: 5 days * 7.5 hrs/day = 37.5 hours. You need to configure round values therefore if you don't have a round number of hours you also need minutes (seconds, etc.). The 37.5 hours equates to 37 hrs and 30 min. In conclusion, for a 5 day target, the configuration needs to be 37 hrs and 30 min. As mentioned above, for simplicity always use hours if possible. If you need to configure this value as days/hours/min then the 37.5 hours need to be divided by 24 (which is the number of calendar hours in a day) resulting in 37.5 / 24 = 1.56 days. The 1.56 days equates to 1 day and 13.50 hours. This further equates to 1 day 13 hours and 30 min. In conclusion: 5 day target in the context of 7.5 working hours/day is set as: 37 hours and 30 minutes or 1 day 13 hours and 30 min If you don't want to be bothered with the mathematical calculation, you can use this Excel sheet to find out what values you need to configure. Type in the desired target time and the number of working hours per day. The values you need to configure are in red: Hornbill_Timer_Targets.xlsx IMPORTANT: the above does not apply when configuring expiry times on human tasks. Human tasks do not account for Working Time Calendar and as such the above setup does not apply in this scenario.
  4. Hi Everybody, We have a global Service Desk Team, working in different time zones. At the current stage we have not yet deployed any service with an SLA, but soon we will. I understood that the SLA might be linked to a specific Working Time Calendars as described in another post (https://forums.hornbill.com/topic/9868-work-time-calendars/?tab=comments#comment-46216). We are also using the 2 stage closure which i understood is in some way using a Calendar; let me also say that potentially our teams and customers will work under this calendar: so my questions are: 1. in which way the Service Manager uses the Working Time Calendars and which relationships we have between Teams' Site/Customer's Site 2. when the Service Manager uses the "ServiceDeskDefaultCalendar" and the "FeedbackCalendar" 3. assuming that we well create additional working time calendar for each time zone we have in our enviroment (see the picture above), how this will be used by the Service Manager from a general point of view and how the 2 stages closure will use those calendars and in which relationship with the Teams' Site or /Customers' Site (if any relationship exist) Thank you!
  5. Hi all, I have just logged a test ticket and noticed that the timers are incorrect. I am using Corporate Service Level Agreements. The SLAs are set as a Response time of 1 hour, Resolution time of 5 days but as soon as I logged the ticket and assigned it the Response timer showed as failed. The resolution is set to be completed by 03/03/17 which is obviously a good deal longer than 5 days (I would have expected it to be 22/02/17) Please see attached images for setup. Any ideas? Thanks Dan
×
×
  • Create New...