90

Ignore non-working days for time-based rules

It would be really useful if you could choose to define days as "non-working" that would not count as elapsed time for SLAs, automations, etc.

e.g. You set Saturday and Sunday as your non-working days, and you have an SLA saying issues should be solved within 72 hours.

An issue reported Friday morning would then not be flagged as threatening this SLA until Wednesday, rather than Monday.

94 comments

  • 0

    Hi Tim, yes general support for "working hours" or "office hours" is a feature we're lacking. We have it in our projected pipeline but unfortunately it hasn't been designed or given a firm time frame yet.

  • 0

    Good to know, thanks Mikkel.

  • 0

    This is fairly fundermental to the validity of the figures produced and general feedback info like age of tickets. A request posted late on Friday night shows up as two days old on Monday morning.

    Any news on the projected pipeline and priority for this?

  • 0

    Hey Graham.

    We reckon that most Zendesk customers are 24/7 always-on internet junkies and that office hours is therefore an obsolete term :-)

    No seriously, we know we have to deal with it, and we are going to, but I cannot say anything about an ETA as for now. Sorry.

  • 0

    +1 for Grahams reply, I really think this is fundamental for the sla reporting. Any news yet?

  • 0

    I agree that being able to specify "Business Hours" for the helpdesk would really help.  We do not currently have a 24/7 helpdesk (at least for the time being) and let our customers know that we will respond within x business hours.  Being able to check on our success for reaching that target is very useful. 

    It looks like Zendesk (at least in 2007) ran an 8-hour/day Helpdesk too.  We'd all benefit from this!

    Welcome Zendesk user

    Submitted Oct 26, 2007 by Mikkel A Svane
    This is Zendesk support, a help desk portal for all Zendesk users. We encourage you to contact us for any type of support, question or feature request. Your feedback is valuable to us. We strive to answer all e-mail support requests within eight business hours (CET, Central European Time)

  • 0

    +1 for business hours support

    we operate helpdesk for clients using instances in three main locations (Australia, US, UK). Need to be able to specify which helpdesk the client uses (as primary contact) and set response time-based SLA's according to hours elapsed during office hours. support for designated public holidays would be icing on the cake too.

     

    until business hours are implemented, SLA reporting is of no use, as we need to extend the thresholds to avoid constantly being in breach. once the SLA can be reported effectively we can publish on our website, which will raise awareness of Zendesk and perhaps drive greater adoption of your excellent product

  • 0

    I agree with all these comments, SLAs are a bit of a toy for us at the moment. Not completely useless though, but I use them as indicative only. (8 business hours approximates to 24 hours during weekdays). Close enough is not good enough though for SLAs. We pay service credits if we exceed our agreed service levels!

    Public Holiday support would be absolutely essential! (Not just icing on the cake)

    Business hours need to be defined for a Group. We are establishing multiple groups around the world, all with different business hours. Some customers only get UK business hours, others get US hours only.

    It would also be nice if we could create an end user widget showing if the help desk is currently within their business hours (open or closed) or how many hours are remaining until close of business.

  • 0

    Our service desk has been asked to provide a weekly report on time to respond and fix, and we were hoping there was a way we could configure this. Ours is relatively straightfoward - set hours of operation on set days of the week, in only a single time zone.

    The last Zendesk update on this was 9 months ago - has there been any news or progress made towards implementing this feature?

  • 0

    It  would be good to get an update on when this feature may become available. It will soon become an industry requirement for us to be able to track exactly how long a case has taken to resolve. If we cannot define working and non working days and hours,  we won't be able to use Zen Desk moving forward.

  • 0

    Let me add my voice to the chorus of requesters.  We are trying to implement a tickler system, and the 2 days of the weekend are necessitating a minimum window of 3 days. This can mean a 6 day roundtrip if the ticket gets handed off.  Not optimal for customer retention.

  • 0

    I'd like to add my voice to this as well.  We absolutely cannot have Enterprise Service Level Agreements without time to fix and respond being measured according to a working hours calendar. We have just had a public holiday in the UK and this means that the issue closure stats from last week are completely skewed.  Anything submitted on Friday afternoon that wasn't solved on Friday shows as not being handled for at least 72 hours, even though our helpdesk is not open and our SLAs were in actual fact met. I am advocating Zendesk throughout the organisation, but without a means to handle this, it is unlikely to gain widespread adoption due to our requirement to put in accurately measurable SLAs across all business lines by Q1 next year for service desks.

  • 0

    Yup - this would be really helpful - the SLA clock needs to tick only during working hours (which we would want to set) - and potentially would be suspended if the ticket was with the end user and not the agent.

    Cheers,

  • 0

    +1 foe Gavins response is there any update on this as the comment from Zendesk saying it is being worked on was over a year ago.  SLA's is a useless feature without this in place

  • 0

    This feature should not be simply business hours/off hours.

    We distinguish between business hours, extended hours, and off hours. Different clients have different support packages that have different SLA requirements depending on the group into which the request fell. For example, for some customers, we don't distinguish between off hours and extended hours, whereas other customers get extended hours included in their SLA as if they were business hours.

  • 0

    +1 from me as well.

    I designed a custom ticket processing system a while back that dealt with this issue.  The requirement was to keep track of the number of hours/days a ticket was in a particular queue (new, assigned, active, pending, on hold, closed, etc) and filter out non-working days. That was handy.

  • 0

    Another +1 for this feature. We can work around it at this time but it would be very very helpful.

  • 0

    +1

  • 0

    What else can I say? This feature will soon make its 2nd aniversary. The SLA features as it is, serves us nothing.

  • 0

    Hey guys,

    Apologize for the delay, and thanks for the responses and +1sssssss -- appreciate it when you guys voice out your concerns, and sorry on our part for not getting back to you sooner.  Yes, we'll definitely bring this up with the team and give you an update as soon as we can

    thanks and sorry for any inconvenience :(

    -amy

    Zendesk Support

  • 0

    fwiw, +1 . 

  • 0

    +1 ASAP please

  • 0

    +1 for me too...

  • 0

    We're not ignoring this thread, but we're not much closer to a positive solution just yet. It's a bit of a biggy/monster when we consider internationalization, agent availability, rules, etc etc.

    But, we'll get there.

    _Jake Holman
    _Zendesk

  • 0

    +1

    Other systems allow you to define a set of hours, possible more than one set, which is then referenced by the rules/triggers for determining the relevant business hours.

  • 0

    +1

  • 0

    +1

  • 0

    +1

  • 0

    This is essential for us as well.  I also agree that being able to define public holidays, but not just a pre-defined list... the ability to select which holidays are honored by the company and specifically what hours, if any that the helpdesk is online.

  • 0

    .....and this is essential for too.  +1

Please sign in to leave a comment.