Jump to content

Handling supplier broadcast alerts (Opening and updating a single Request when inbound emails don't quote the Reference number)


Berto2002
 Share

Recommended Posts

I have a supplier who issues us with Major Incident alerts. We could, of course, log them as Incidents and deal with them. the first one of a chain comes-in with a subject containing "NEW%", for example.

But through the lifecycle of at MI they will send updates (subject starts with "UPDATE&"); but because they are not specific to us as a customer (they are broadcast alerts from a teleco), they are not in a position to receive our Ref number from our logging notification and quote it in the Summary for inbound rules to pick-up and append to the ticket.

So how can I (and does anyone else) receive and process broadcast service alerts from suppliers?

It is not acceptable to log a fresh Request for each update since there can be ten of them in a day.

The 'nirvana' is:

  • Inbound rule picks up when the Subject LIKE "New%" and logs a new request
  • Another inbound rule picks-up when the Subject LIKE "UPDATE%" and updates the ticket raised in the first rule; but I cannot work out how to tell one rule about the other...

The solution I was trying was to have a 'perpetual' ticket which sits in a resolve status and is updated by an inbound rule. I thought I could 'hardcode' that Request Reference number in to the inbound rule "Reference" field but that doesn't work because the Reference field is looking for Regex to match the subject (which doesn't contain the reference) rather than accepting my hardcoded value as the Request to update.

A bit stuck here; but surely there's a way to receive and process broadcast alerts into tickets?

Any help or ideas appreciated.

Thanks

Link to comment
Share on other sites

  • Berto2002 changed the title to Handling supplier broadcast alerts (Opening and updating a single Request when inbound emails don't quote the Reference number)

Hi @Berto2002

Thanks for your post.   I can see that the unique Request ID is required in order to make the match between email and request.  As you have found, the RegEx is just looking for a match and not actually applying the values to the the subject.  One option for you might be to use Exchange rules to prepend the subject line of an email as it is received.  I've seen this before where companies will prepend the subject line with [External] -  so that these emails can be quickly identified as emails coming from outside the company.  You may be able to do something similar where you create a rule in Exchange to identify these emails and then prepend the subject with the request ID of this perpetual ticket.

I agree with your 'nirvana', which may be able to work, but it would require some form of integration and/or cooperation from the supplier.  

Link to comment
Share on other sites

@Berto2002 for the new ones as they come in with 'New' in the title you can use the routing rules to log these and then in the BPM you can change the title of the request to remove the 'New' bit via regex and the source email node.

Then if these are logged against a Service you can set the Service Email Template to be something that is formatted in a way to get the details, for example we 'force' a ending to the subject e.g. - update then again look for - update in the title when the reply email is received. Alongside this we then add the request number to email template at the bottom in white text so it's 'invisible' so at least you could manually add the email to the request when they respond.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...