How to setup JSM for email-only ticket creation

[Andy]

Hi everyone,

I'm setting up JSM and am constrained by some criteria at this stage:

• Tickets can only be created by customers sending an email (no portal access)
• Only 1 email address will be used for all tickets created
• Two teams will action tickets: Sales Support (Requests) or Issue Support (Incidents)
• Requests may contain Changes and Requests needing approval
• Requests and Incidents must use the same workflow

From what I can tell, I have to choose a default Request Type, e.g. Incidents, which is linked to an ITSM template and will drive which Issue Types, fields and workflow will be used.  For Change, Requests, and Requests with Approvals to function within the Incidents request type, I think I have to find and add the missing fields for those request types into the Incidents request type, and then alter the workflow in the same way so that it functions for all scenarios. This will then enable an agent to take a ticket that has an issue type of "Email Request" and convert it into a Change issue type or a Request with Approval issue type, etc.

I'm not sure if the above is the best approach to this scenario.  Personally it doesn't feel right and I do wonder if it is going to cause issues further down the line when inevitably we do launch a customer portal and do want to have different workflows for requests, change, and incidents, etc.

I'd really appreciate your advice... what do you recommend?

Thanks in advance 👍

[Jack Brickey · Accepted solution]

Hi Andy, welcome to the community.

You pretty much have it right given your restrictions/requirements. First off if you can only have a single email then all tickets will come in under the same request type. This because you can't have multiple request types for a given email address obviously. So ultimately what you're looking at is to have all tickets come in to what I refer to as a triage queue. That queue must be monitored such that all new issues are assessed and they can be dropped into the appropriate request type incidents or requests. I would choose the default request type to be the one that represents what do you expect the majority of the requests to be. In that way you're only moving a handful of issues to the other request type. Then you can define your queues based on the actual request types and have the appropriate agents manage those queues.

While you could consider using automation to help with some of this the challenge is going to be the reliability of the summary or description of each issue since there are humans involved this is not always going to be the case.

once you put the portal in place you will have a lot more options here and it'll be a lot cleaner. Note that the notifications going to the customer based on your email requests are going to have links that will resolve to your help center. So you need to decide how you want to deal with that. You can hide all request types from the portal but you can't hide the portal from the customer completely.

[Andy]

Hi Jack,

Thank you for the welcome and quick reply especially as it's a Saturday!

I appreciate your point of view on this and feedback about the portal - this is something that I wasn't aware of.  I'm beginning to think it would be simpler to just go with the portal up-front and steer away from email... will have to have a think on that.

Thanks again.

Andy

[Jack Brickey]

Certainly if you can start with a portal out of the gate you'll be much better off. Especially, with the introduction of Forms that is now available for JSM projects. While I haven't used them and integrated them yet they look extremely promising and powerful.

[Trevan Householder_Isos-Tech-Consulting_]

I agree with @Jack Brickey 's answer. 

Additionally, if you're using SLAs and want to encourage people to use the portal instead of email, you can set a longer SLA time on requests that come in via email and a shorter (faster response) for requests that come in via the portal.  This will help encourage the behavior you want, without having to enforce it.  

[Andy]

Thanks for the suggestion :)