Question

What is the idea of FreshService we do not understand

  • 20 April 2024
  • 2 replies
  • 38 views

 

Problems with FreshService

 

We are currently evaluating FreshService and have a trial version installed. FreshService is being compared to HaloITMS used elsewhere in our organizatoin. Most of our evaluation time has been spent on FreshService, and we have a desire to choose it, which has previously been communicated to FreshWorks and FreshWorks' Norwegian partne, i.e 99% probably that we would chose FreshService. However, we have encountered some "logical flaws" in FreshService that we need to figure out. These may be due us not fully understanding what Freshworks has intended as best practices in use of FreshService or not knowing the product well enough.

 

Main Issues:

 

  1. We want users (requestors) to be able to report an issue (ticket) as either an incident or a service request.
     
    1. When registering an incident (typically a fault situation), a simple form should be filled out. It should be possible to paste images into a rich text field.
      We can solve this “out of the box” with the report incident card in the portal.
       
    2. When registering a service request, we envision two possibilities:
      1. The user uses the service catalog, finds the correct service, and reports it this way, and
      2. We have created a general service named "Support and Service" in the service catalog, and the user selects this and a generic service request ticket is raised.
         

The problem with point 1b is that FreshService does not support rich text fields as input fields in the Service Catalog. FreshService supports users adding attachments, but rich text fields (HTML and images) are not supported.
This makes it difficult to introduce point 1b to users, especially 1b ii. We require pasting pictures (from the clip board) directly in the service request.
 

  1. One can change the ticket system by turning off "Incident type," and all tickets come in as Service Requests. This could be a solution, but then we do not understand how Incidents should be reported.

Ticket type seems to be "locked" to a logic FreshService should manage, and we do not understand this logic.

 

  1. We have tried to create a workflow that categorizes tickets as Incidents or Service Requests based on criteria in the case. Perhaps this is what FreshService thinks is best practice. However, the email to the user goes out with "SR-XXX" or "IN-XXX" before the workflow runs, and the user gets a "wrong ticket identifier."

2 replies

Userlevel 7
Badge +7

Hi @NewUserOfFresh - thanks for your query! I’m tagging some of our community sme’s who can guide and assist you @suvashini.balashanmugam   @kengon  @alexandertran 

 

Userlevel 7
Badge +11

Hi.

Not sure if this is a little bit late, but here is what we have made at least for your last part:

We disabled default Requester notification for ticket creation.

We created a Workflow for ticket creation notification, and based on certain conditions and our business case, we sent the appropriate ticket creation notification, for Incidents, Service Requests, and we even manage Inquiries and Project ticket-types and they all get the appropriate notification. This approach may suite your use case as well. This workflow is pasted after all initial logics are evaluated and performed, hence the appropriate INC-XXXXX or SR-XXXXX is sent to the Requester.

That’s the beauty: You can greatly customize it to your needs.

 

With this approach, I guess, you won’t need to disable Incidents, and may have both. Actually we made the opposite as yours: In the Incident form, we also offer the option to specify a Service Request, and then such ticket is converted to SR before the ticket creation notification is sent, so, the user receives the proper ticket ID.

 

And, on the Service Catalog items, we added a Content field with this:

If you have an incident or problem, click here and we redirect them to the Incident form.

 

 

Regards,

Reply