New product support options out of hours support

[chriscorcoran]

Hi,

we are about to launch a new product to our customer and with it we want to capture all issues during the training\bedding in period, during normal hours this is fine but out of hours, our servicedesk is closed.  I'm thinking if we setup a separate email address and hornbill mailbox would it be possible to automate call logging so that the ticket is raised automatically out of hours? as anything hitting this mailbox would be assigned to the same categories and team each time, I need to make sure that out of hours calls are assigned to a 3rd line team so they would get notified by email. I do have a plan B which is just create a shared mailbox with a distribution group to third line and then service desk staff can log calls in the morning, but just wondered if anyone does anything clever with Hornbill.

 

 

Any thoughts?

Thanks

Chris

[Guest]

@chriscorcoran Yes it is possible to set up automatic call logging out of hours using the routing rules https://wiki.hornbill.com/index.php/Email_Routing_Rules

Another useful read would be https://wiki.hornbill.com/index.php/Routing_Rule_Templates

kindly have a look at the image below with regards to the call assignment. You can specify who the call gets assigned to in the Routing Rule Template

If you set up the routing rules with the appropriate rules,  you will get calls being logged even when the Servicedesk is closed.  Please be aware that there a few circumstances under which the Routing Rules will not work:

• The email sender does not exist in the system, either as a co-worker/internal user or a contact/external user, and the app setting to allow a request to be logged or updated from unknown sources is turned OFF and the app setting to send back a rejection email is turned OFF
• The email sender does not exist in the system, either as a co-worker/internal user or a contact/external user, and the app setting to allow a request to be logged or updated from unknown sources is turned OFF and the app setting to send back a rejection email is turned ON but either the app setting for rejection mailbox and/or email template is incorrect or not set
• The email sender exists in the system but the from address is matching more than one user/contact in the system
  
  Regards,
  Pamela

[Steven Boardman]

@chriscorcoran 

You can use the routing rules to auto-create tickets in hornbill.  You can also invoke routing rules templates so you can not only log everything to a single team but based on routing rules conditions - to / from address or domain, or content of the email you can invoke different routing rules templates.  The routing rules templates can then cater for logging against different services, to different teams and invoke different linked business processes to your service and or catalog items:

 https://wiki.hornbill.com/index.php/Routing_Rule_Templates

just an additional consideration if you used a Get Request Info in your business process logic could you use the Time Logged to then branch and decide who the ticket is routed too?

So on logging, you could do a Get Request Info followed by a decision node and branch say on the Time Logged variable so if greater than support hour say 5 and less than say 9 then branch and email your 3rd party, otherwise follow the usual path during usual operational hours?  The returned value is an epoch value, so you will need to set your test conditions to evaluate against the epoch value for when your normal work hours start and the epoch value for when your normal working day ends and see if the returned value is less than or greater than either value and if so it can be deemed to be out of working hours 

If you wanted to cater for weekends as well you could you the Hornbill iBridge and the free utility option to get the current day First, and again then branch a decision in your business process to say if Saturday or Sunday route to 3rd party else follow the usual path?

The Output values are in the format Monday, Tuesday, Wednesday etc so you would need to check if value is Saturday or if Value is Sunday 

If you are doing day of week and hours then you would need to do the day check first, and then the time of logging otherwise you would find requests logged between say 9-5 routed to your usual team on Sat and Sun as this would be in between the usual epoch working values, but if you evaluate the day first, you can check to see if it is a Sat / Sun first and auto route to the 3rd party email, but if it is Mon-Fri then do the time check to decide if this should go to 3rd party email or not

Just some thoughts as the business process will get invoked regardless of channel (email, portal, phone)

Steve

[chriscorcoran]

@Steven Boardman @Pamela Both many thanks for the information above, I will have a play and see how this goes but looks very promising and makes good use of the hornbill system.

Thanks again!

[chriscorcoran]

@Steven Boardman @Pamela Just an update for you both. I'm testing a basic routing rule which does seem to work as it creates the call and assigns to the correct service and priority but I can't get it to assign to the second line team. Does it follow the services BPM process once logged? As it only seems to go to the first line desk. I would like it to go straight to the team so that they get notification a call has been raised as well.

 

 

[Victor]

34 minutes ago, chriscorcoran said:

Does it follow the services BPM process once logged?

Yes.

36 minutes ago, chriscorcoran said:

I would like it to go straight to the team

This?

[chriscorcoran]

@Victor thanks, yes its set to the the correct team. I have to go to the call to manually assign. I suspect the BPM needs to be changed?

 

 

routing.pdf

[Victor]

2 minutes ago, chriscorcoran said:

I suspect the BPM needs to be changed?

@chriscorcoran not sure... does the BP (re)assigns the request? If yes, then it would need to be changed...

[chriscorcoran]

@Victor yes all of our BPM's follow the same rule of first being assigned to servicedesk for data checking then they assign to the team.

[Victor]

@chriscorcoran then perhaps change the BP to check first if the team on request is "Luminate" and if so don't assign to servicedesk team?

[chriscorcoran]

@Victor thanks, I seem to be getting somewhere now. One last qauestion I was basing this on a routing rule of subject = 'test' now I want to base the rule on coming from and email address, does that follow the same format so for example if the email was coming from would it be fromAddress = 'exanple@domain.com'

 

Thanks

[Victor]

Just now, chriscorcoran said:

if the email was coming from would it be fromAddress = 'exanple@domain.com'

Yes  

[chriscorcoran]

@Victor hi my routing template is using raise NewRequest which is why new calls raised are being logged as SR numbers do I need to choose log or update incident in order for emails to be automatically raised as new IN? 

 

Thanks

[Victor]

@chriscorcoran unlike other "raise new" operations, the "raiseNewRequest" operation is using "Routing Rule Templates" (https://wiki.hornbill.com/index.php/Routing_Rule_Templates). If the request is raised as a Service Request then this is because of how the routing rule template is configured... to have requests raised as Incidents for that particular routing rule you would need to either:

• switch to logOrUpdateIncident operation (as you suggested)
• amend the current routing rule template and change request type to Incident
• create a brand new routing rule template for Incident and use this for that particular routing rule

[chriscorcoran]

@VictorHi Victor, the new rules are working well, the only issue I find is that the team are getting two automated emails when an new call comes in and it follows the email routing rules. Is it because the first part of my BP was originally sending to service-desk, now I have changed that to the team in question? . Is there away to stop the first email from going?

 

 

 

 

[Victor]

@chriscorcoran if you are using Routing Rules Templates, then the request is already assigned to the team when is logged... perhaps in the BP, before assigning it to the team, check if the request is already assigned to the team. If it is then simply continue the process, if not then continue the process via a team assignment node...

[chriscorcoran]

Hi @Victor, I'm struggling to work out why the team get notified twice, can you see where I'm going wrong? BPM attached.

 

 

incidentdeltaluminateslack.bpm.txt

[Victor]

@chriscorcoran I’ll have a look at the BP ... might need to raise a support request on your behalf as it could require a more thorough investigation...

[Victor]

@chriscorcoran I am not entirely sure why in "incidentdelta_LuminateSlack" process the first node assigns the request to "Service desk" team? The way the process is currently designed I don't see the reason why ... because the process will progress automatically up to "Wait for Service Desk Analyst" node... meaning it will initially assigned to "Service desk" team then midway through reassings it to "Luminate" team... but there is no manual action in between so, not sure why these team assignments?

The only scenario I can think of is perhaps the process is not used exclusively by requests raised by routing rules and perhaps there are scenarios when this process is used on requests raised manually? But then again, the first assignment is still irrelevant...

[chriscorcoran]

@Victor thanks Victor. this process is different from my others in that when a call comes in from the routing rules it gets automatically assigned to the Luminate team, bypassing the servicedesk team. It just seems that it assigns or notifies the team twice. I can't workout which node it is that sends the notification again.

 

[Victor]

2 hours ago, chriscorcoran said:

when a call comes in from the routing rules it gets automatically assigned to the Luminate team, bypassing the servicedesk team

@chriscorcoran ermm... not according to current BP config...

So, in below screenshot I have highlighted (part of) the current path from "incidentdelta_LuminateSlack" process. When the process starts it will assign the request to "Service desk Team" (this would be node 1 in the screenshot). It progresses further up up node 2 in the screenshot where it assigns the request to "Laminate" team. So, assignment to "Service Desk" is not actually bypassed...

2 hours ago, chriscorcoran said:

I can't workout which node it is that sends the notification again.

I'll try and explain: when the routing rule process the email, because they use a routing rule template, it will assign the request to "Laminate" team before the process even starts. Then in the process, the request is also assigned to "Laminate" team (node 2). So team notifications occur:

• first when the routing rule process the email and assigns it to "Laminate" team
• second when the process assigns it (again) to "Laminate" team (node 2)

My question is, do you use the  "incidentdelta_LuminateSlack" process on any other request other than requests raised from emails? Is the process solely intended for "laminate" requests and the only way these requests are raised is via the routing rule? If yes, then the process might contain some redundant nodes there...

 

[chriscorcoran]

@Victor thanks. We do create calls manually as well so they go to the servicedesk team first.

 

[Victor]

@chriscorcoran

33 minutes ago, chriscorcoran said:

We do create calls manually as well so they go to the servicedesk team first.

Ah, ok, I understand... but you use the same process ("incidentdelta_LuminateSlack") for manual calls as well? 

[chriscorcoran]

@Victor yes

[Victor]

@chriscorcoran ok... in this case, the request will always end up being assigned to "Laminate" team even if it was raised manually... because the process progresses automatically all the way up to "Wait For Service Analyst" node which is after node 2 in the screenshot... so the first assignment node "Assigned to Service Desk" is redundant... 

So, how exactly is your business operation when it comes to this process for requests raised manually and requests raised automatically from email? I need to understand this before advising on any adjustments