Simplify form for end users, make it easy to raise through the Requester Portal especially for end users who prefer sending emails.

To drive users to use the end user portal, you want to make the experience of putting in a ticket and keeping an eye on it as easy for them as you can without asking them to fill in too many fields. You should also be using Business Rules to reduce the amount of visible fields and options within those fields if there is an opportunity to do so. Also, for the sake of ease of use, consider if you want to make these fields required on submission.

You can utilize strategically placed additional Custom Fields to your advantage.

Apart from the basics like the subject, description and attachments, you could also ask them information about how badly this issue is affecting them, and how many users are affected. We don’t usually suggest that you map this field directly to the priority and hence affect your SLA, but it definitely helps your agents assess how a particular ticket needs to be prioritized. 

This can be a simple dependent field like this with straightforward questions instead of a low-medium-high scale.

​

You can also look at asking the users what kind of issue they are reporting. This does not have to be your Category field, because it really should be assigned by Agents to then be used in your Analytics and you want that to be as accurate as can be. Also it is something that you are going to expand as you scale and you want a smaller set of values for your users to select. This field can be a simple dropdown or dependent field that has 10 to 15 choices for the users to look through and select. You could have a second level in some cases if that helps you route the tickets slightly better. 

Here is an example of what that field could look like:

You can then use this field to route the Incident to the right team and maybe even set a higher priority for certain types like InfoSec. 

Apart from this, you could also use fields to get simple information like the location of the issue or the contact number of the user that might help you locate the issue or contact the user more easily.

Consider using the Service Catalog for more unique use-cases

For more unique forms, explore the Service Catalog. You should be making a distinction between Incidents as a “break/fix” form and Service Requests as requests for something new but there are a few exceptions you can make for cases like password resets. Using a Service Request in such cases allows you to get the right information that you need like which application or username it is that you need to fix this for and you could even use the Orchestration Center to automate cases like these.

______
 

If you would like to engage with us for any assistance around setting up Freshservice or get consultation on best practices, please reach out to your Account Manager or learn more about Freshworks Professional Services here