Could be possible to do not consider a new ticket (created by email) as an incident automatically ?
If yes, could be possible to make categorization ("incident" or "request") mandatory before set the ticket as resolved ?
Many thanks in advance for your kind help!
The reason behind why an email coming through to the service desk is always marked as an Incident is because service requests can be raised from the Customer Portal on Freshservice as they are always pre-defined to get specific information, often exhaustive.
As a workaround, we can configure workflows, but we would recommend encouraging users to use the Service Catalog instead to raise a Service Request. Using a workflow, you can create a Service Request from the Incident ticket that was created and then proceed to delete the Incident ticket.
Additionally, studying patterns on the most frequently asked service requests that come in via an email will help your create new service items, thereby reducing the hassle of converting the Incidents to Service Requests.
The idea here is to continually create service request forms (service items) which are customised to get maximum information from the requester, which might otherwise be missed over emails.
Whilst we understand that it can be a hassle to have complex workflows read subject lines and assign tickets to the groups accordingly, encouraging your requesters to use the self-service portal has the following benefits:
I trust this helps you out to you. Happy supporting!
I know this is old but it caught my eye. The real reason for this is rooted in ITIL, where everything is considered an incident unless it’s picked from a menu, in which case it’s an item request.
It’s a silly, antiquated framework but despite the association, Freshservice is a great platform that allows you basically ignore it if you want.
We made a Workflow Automator that turns all requester-created tickets into service requests (SR) and we only use incidents (INC) if it’s actually an incident - asking for help is not an incident. It’s really semantics but it makes more sense to the admins and agents.