Email notifications for customer updates – via the portal

[nasimg]

There are basically 4 types of analyst/group notification (email and hornbill type):

-          analyst assignment;

-          member added;

-          automatic email update/automatic call logging;

-          customer updates – via portal.

 

The first 3 are currently working for both email and hornbill notifications. The last one, customer updates, currently the only option is hornbill notification.

 

I want to know when we can expect to see this available as an email notification - can this be treated with priority as its something critical to our organisation.

[nasimg]

I'd be interested to know how others get notified when their customers update a ticket - if you have a lot of tickets (or don't view Service Manager regular) we think its useful to get an email telling you a ticket has been updated (like Supportworks does).

[Guest Chaz]

Hi Nasim,

this is something that we do want to get working, there are just some challenges around Mailboxes and the rights required to use them. I've set something up to discuss with development next week so that we can look at making some progress with it.

[nasimg]

Hi Charanjit

Thanks for the feedback, definitely interested to hear where you get to with this. We have moved from Supportworks so the analysts are used to receiving email alerts.

Nasim

[nasimg]

Hi Charanjit

Any news about the email updates....to make matters even worse, none of the email notifications are working for us...I can't stress how important this is to us.

Nasim

[Victor]

Your colleague Carl Tiedt logged a call with our support team yesterday in regards to an XMLMC error after a call was logged. During our investigation into this issue we did notice quite many error log entries referring to an 'undefined' mailbox:

 

Operation[mailadmin:sharedMailboxGetInfo] The specified mailbox 'undefined' doesn't exist on the system

 

We found this being cause by a miss-configuration in your instance (as per attached screenshot). As per our email sent to Carl yesterday, we noticed that in Service Manager application settings all notifications were turned on (app.request.notification.*) but the notification mailbox is not currently configured. To have the notifications working correctly and to eliminate the error log entries you would need to either specify the mailbox (which is 'helpdesk') or turn off email notifications (switch notifications from 'both' to 'hornbill-only' or 'none'). Once the correct mailbox is configured you should have the notifications functionality restored (minus the portal update which is currently being fixed).

[Guest Paul Davis]

Nasim, there are two elements here: the subject of the original post and the later issue that you point out in respect to email notifications in general.

On the latter point, as Victor just mentioned this was down to a mis-configuration in your system and should now be resolved. As you have the Premier Success Plan, if functionality is (or appears to be) broken, please raise a request via our website ( https://www.hornbill.com/request/ ). This way your any urgent issues will be logged with the appropriate priority and handled with the SLA defined in your Success Plan.

In respect to the original discussion, a change to address this matter is being working on now by Development and as Chaz mentioned should therefore be available in an update to Service Manager coming very shortly.

[nasimg]

Paul - thanks for this. This has resolved our email notification for calls being assigned and customer updates via email. I understand you are working on the notifications via the portal (which is how I started this topic).

[nasimg]

After getting the email updates working for assignments and updates from the customer (via email), we have run into a problem with a certain scenario where:

1) You are setup on Hornbill Service Manager as an analyst
2) A ticket was assigned to your team
3) An email update was added to the ticket before it was assigned to anyone (eg. out of office reply or the customer replied to the inital call has been logged email)

This creates a chain of multiple emails from the hornbill team, updating the call with their out of office messages - we do have large team (25+) so chances are some staff may be on leave. These messages don't help the customer (as they come from Autoresponder) and definitely doesn't help the analysts in the team as they get lots of messages saying the ticket was updated (see attachment).

I would hope there would be a button enable or disable autoresponder updates from the team, which would stop this happening.

[nasimg]

I hoping someone has an idea of what we can do - problem mainly seems to be around team notifications, I really need to be able to disable them. Also noticed that is the sub-group teams (eg. KSO is a part of Business Systems) get the notifications too.

I want to keep the feature of out of office notifications updating the ticket as it tells the analyst (or customers) that someone is away. What I don't want is team (sub team) to update the ticket with their out of office.

[Victor]

Until or developers and/or product specialists can advise if and when such a functionality will be implemented, perhaps an alternative would be to use routing rules. What I have in mind is something like a rule with the following criteria:

subject LIKE '%Out Of Office%' AND fromAddress LIKE '%maildomain%'

or

subject LIKE '%Out Of Office%' AND fromDomain = 'maildomain'

This rule will precede your current update rules and as configuration it will route the email to a mailbox folder. This rule will ensure that any internal OOO will be routed to a folder and not update a call and any external (customer) OOO will be added as update on the call by the other routing rules. You would need to amend the OOO message if is different and use your email domain for 'maildomain'.

This being said I can see this not being an alternative if contacts/customers are from within the same organisation which makes the maildomain option unusable for this purpose.

[nasimg]

Thanks for the the update Victor, unfortunately the customers are form the same organization. I still don't understand the logic of updating the whole team to call updates, in Supportworks you could direct escalations to the workgroup manager (so everyone didn't get the same message). Also seems sub-teams are also notified which I don't believe should happen. Can you see if there is anything in the pipes to address this issue?

[James Ainsworth]

Hi Nasim,

I just wanted to cover back over your post as I can see that there are a number of different things going on and I wanted to make sure that the different questions were being covered.

The original post was asking for email notifications to be provided to the support staff when a customer updates one of their requests on the portals.  I understand that some other questions may have stemmed from this, but I wanted to start by confirming if the email notifications for customer updates now available for you.

There are a few areas you have mentioned that either come from introducing this feature or it has highlighted some areas that could be improved when using the customer update email notifications.

1.) Out of office replies.  I believe an option to check the subject of an email has been suggested where you look for subjects containing "out of office".  This should prevent the routing rules for automatically raising the request.  However, it may be that you have a combination of wanting to include customer's out of office replies, but exclude any from members of the support team.  So, a customer updates a request in the portal where that request does not have an owner, so the entire team is sent a notification email and some of those respond with an out of office which then also get added to the request via the routing rules for updates.  Whether it be the Hornbill Routing Rules or the rules on your Exchange Mailbox, it will need something to differentiate between customer and support staff.  At the moment I can only suggest using the names of the sender, and checking against all the support staff that have access to that mailbox.  If there is no immediate way of determining this using the Routing Rules within Hornbill, can I suggest as an interim measure that you look at rules on the Exchange mailbox to remove out of office messages from members of your support teams.

2.) Another issue that you have mentioned with the Out of office is the starting a chain of events happening when a customer receives a request confirmation email when first raised, and the customer's email responds with an out of office, which in turn send an email confirming the receipt of the update, which again, sends another out of office...  Can you confirm that this is what you are experiencing?

3.) The logic behind updating the whole team of an update, should only be the case where there is no owner for that request.  Without an owner, we felt it was important that someone received the notification of the customer's update.  So, as long at there isn't an owner, the notification goes to the team assigned to the request otherwise no one is aware of the update.  You mentioned escalations in Supportworks could send an email to a manager.  Escalations in Service Manager do the same, but in both cases escalations are different from customer updates.

Do let me know if there is anything that I missed.  If you don't mind me suggesting something, you might find it helps if, where possible, you post each issue separately on the customer forum.  I understand that these are closely related to each other and come as a result of implementing the new email updates, however with a post that is focused on a particular topic you may find you get more focused responses from not just Hornbill but from other customers as well.  Keeping a post contained to a single topic will also help other's looking for solutions and we can also direct each post to the different Hornbill teams that manages that particular area of the product to hopefully provide faster solutions. Your continued feedback is of huge value to both us and all Hornbill customers.

Regards,

James

[Steve Giller]

On 2.
An OoO should only send on the first receipt of an email from an address - so the only way to get a chain going is if the responses are coming from different addresses each time, or the OoO settings on the customer's end are poorly configured.