Using Automation to Screen New Customer

[#1]

If the use of email issue creation is part of your Jira Service Management (JSM) project then you might find this article of interest.

With JSM Cloud you have two options for managing new customers: locked down or open. 

If you want to control who can open issues in your project then you have your agents responsible for adding/removing customers. This can obviously be a tedious task and can be frustrating to your customers. More importantly you could miss important requests unless you make it a habit of combing thru your email logs for failures on a daily basis. So you opt for an open project. However, leaving the project open can result in unwanted customers being added to your project, leaving your team with a constant tidying exercise and inevitably spending time on requests that maybe they shouldn't.

If there were only a clean way to quarantine new customer requests until it can be determined that the customer should be added to the project and your agents should work the issue.

Automation to the rescue!

With a bit of Automation work and optionally some workflow changes, you can better control your customer onboarding process for open projects.

The solution at 50k feet

The idea is to inspect each new incoming email request to see if the Reporter has previously created any requests. If they have then the customer is assumed to be approved for the project. If not then the request is placed 'in quarantine' until the appropriate Agent has assessed the request to see if the customer should be added.

Time to pop the chute and get into the details

Here is the list of tasks to put this process into play:

1. Add a "Quarantine" status (optional)
2. Create the Automation rule
3. Set up a Queue to monitor the new customer quarantine issues.

Automation rule

The automation rule will look something like the below image. But be creative and build it out to meet your needs. Make it your own! A special shout out to @Dirk Ronsmans for his support in working thru this rule syntax!

Explaining the rule

1. Using the Lookup issues action and the reporter for the current issue you can search for all issues this reporter has created in the project.
2. Optional but I really like to use the Action to add a value to the log for test purposes. The action will show you how many issues the Lookup found.
3. Check to see if the reporter has previously created issues. The working assumption here is that if they have then they are already an approved customer. Feel free to add more qualifying conditions here if you like.
4. Flag it! This is where you can flag the issue so that your team can easily locate issues that need to be assesed as New Customer requests. This is where the optional "Quarantine" status can really come in handy.

Stick the landing

After fully testing your rule and making the necessary changes it is time to put the process to work.

1. Add a new queue "New Customer" using the flagging method you landed on. For example, if you created the new status then the queue would be defined by status = "quarantine" or whatever status name you chose.
2. Train the team. Make sure the team knows to monitor the queue and process as required. If the request is to be rejected be sure to enter a comment to that effect and close the request. Also, go into User management > Jira Service Management and revoke access for the customer. Any future requests from that email address will be rejected as the customer is inactive. NOTE: if the customer is valid for some JSM projects and simply not this project then don't revoke access, rather just remove them from the project.

I hope you find this article useful and I would love to read your comments about how this could be made even better!

Cheers!

[Jack Brickey]

Thanks to Bridget for adding the images!

[Darryl Lee]

This is interesting. I was reminded of recent post about being able to require Time Tracking for certain users which would require a separate Issue Type for different user groups.

Maybe this approach could be adapted to that - have a "catchall" Request Type, and then use Automation to route it accordingly, post-creation.

Although as I think about it, it doesn't solve the age-old question of How to hide an issue type from a user group, alternately Restricting issue creation of certain types based on user project role / group

Hiding the other issue types being the key. Hum.

[Dirk Ronsmans]

Great stuff @Jack Brickey ! and definitely a creative approach to a not so uncommon problem!

For me would pay special attention to the JQL you use to retrieve the issues. Right now you mention that if the customer has at least 1 previous issue, they are a return customer. But what about the scenario that this previous issue was actually a rejected one?

You could of course delete the issue when it was not valid (e.g. the customer is not allowed to make a ticket) but then you'd also lose sight of the workload that the agent has put in to triage these issue.

So maybe a small extension could be to have an Agent flag the issue as valid/invalid after the assessment and consider returning customers those  who have at least 1 valid ticket (instead of just 1 or more previous tickets). Otherwise you might get a false positive after the first "rejected" issue that the system might consider that customer a valid returning customer.

And thanks for the shoutout :)

[Jack Brickey]

Thanks Dirk and indeed that is a very good point and one that crossed my mind. Basically, is it reliable to simply consider a reporter to be an accepted customer based on an existing ticket. It would be great if we could have real profiles in Jira/JSM and it included customers. I would love to have a user profiles such that I could pull data (address, contact, valid support contract, etc.) on the user. Maybe one day? I contemplating having a custom field exactly as you suggested, where you could capture approved/rejected in the issues directly and then inspect in the above automation but this gets a bit messy possibly if some early issues were rejected and later approved. Ultimately I settled on simply flagging the issue so that Agents could more readily put eyes on it and make a decision. But I love the ideas of taking this concept and coming up w/ something better/cleaner and glad to see the ope discussion here!!

Ultimately I feel this solution is working around a product deficiency. JSM should have the ability to flag new customer requests vs. the current silent (or whisper) failure that exists today where the Failure can be seen in the email logs. I hope that one day a solution is provided.

[Dirk Ronsmans]

Absolutely! and while there are CRM apps for JIRA they really don't integrate that well. Also if you have customers that can register themselves it will be hard to define what their meta data will be (at least automagically on their first ticket) so the triage will always be needed at some point.

For me I would maybe Reject the ticket if the customer isn't a valid one and use a custom Resolution to be sure that I mark that this customer is not valid.

If you then include that Resolution code in your JQL (to search only for tickets with that reporter where the JQL is not "Out of scope"/"No contract"/.. you'd at least avoid having a single "rejected" ticket, "auto approve" all the following ones for that customer.