Skip to content
  • There are no suggestions because the search field is empty.

Freshdesk Ticket Key Issue, Type and Resolution Fields

Follow the Freshdesk Ticket Key Issue, Type and Resolution Fields process

As part of managing your tickets, you need to classify them by Issue Type and Resolution. Doing this allows us to analyse what type of tickets we are getting, what areas they relate to and how we are resolving them. 

This information is used to identify areas where we are seeing high levels of support requests. It is therefore important that the fields are completed correctly.

When completing the fields the aim is to identify the underlying cause / reason for the ticket, not the issue being presented. Here are some examples:

If the retailer is complaining about listings not being updated and it's due to dead variants then the Issue Types would be Listings / Listings / Variations and the Type would be Bad Customer Data.

If the retailer is complaining about their shipping charges not being applied correctly and it's due to their groups not being set up correctly then the Issue Types would be Account Enquiry / Retailer Account / Product Groups. The Type could be Bad Customer Data / Product Confusion or Question depending on what the cause of the groups being incorrect was.

If the retailer is complaining about orders showing the wrong product and it's due to incorrect / duplicated UPC data then the Issue Types would be Listings / Listings / Product Identifiers. The Type could be Bad Customer Data if they've entered an incorrect UPC or duplicated it, or it could be Marketplace Bug / Issue if it's the marketplace database that's incorrect.

If the retailer is complaining about nothing listing to eBay and it's due to their Business Policy Names not being correct then  the Issue types would be Account Enquiry / Business Policy / Incorrect policy Name.

Below are some general rules for completing these fields:


Customer Key Issue


The first level of ticket analysis determines the main category the ticket issue falls under.

While this selection doesn’t control the options displayed in the Key Issue and Sub Key Issue fields, it’s important to ensure it aligns logically with those selections. For example, avoid choosing "Connection or Syncing" if the next fields will be Listings and Dead Variants.


Key Issue


The second level of ticket issue identification. Ensure your selection aligns with the Customer Key Issue.

Note that your selection here will determine the options displayed in the following Sub Key Issue field. 


Sub Key Issue


The options shown here depend on the Key Issue you've chosen. 

If you don't see the option you need, it's probably not linked to your selected Key Issue. Try changing your Key Issue selection to find the correct option.


Type


This field is used to track the types of tickets we receive. Note the following rules:


  • Bad Customer Data - Use this when the retailer's incoming data is the cause of the issue e.g. invalid UPC codes, variant structure changes.The aim of this Type is to track how many times we are dealing with issues caused by the retailer's data not being in the correct format, missing required information etc.
  • Bug Introduced by Dev - Use this where a previous fix causes a new issue.
  • eCom Platform Bug / Issue - Use this when the issue is caused by something in the eCom platform that we have no control over, or was set incorrectly by the retailer.
  • Feature Request - Use this for all new feature requests - note if this is used then the Issue fields should all be Feature Request and Resolution should be Closed Not Solved.
  • Marketplace Bug / Issue - Use this when the issue is caused by something on the marketplace side that we have no control over e.g. there's a marketplace outage.
  • New Integration / Bad Setup - Use this for new retailer / marketplace setup issues due to incorrect configuration.
  • New Integration / Confused - Use this for new retailer / marketplace setup confusion or difficulty.
  • New Integration / Enquiry - Use this for all other tickets where the retailer / marketplace is in setup mode.
  • Omnivore Bug / Issue - Use this for all tickets that go to Dev Fairy and are determined to be a bug.
  • Product Confusion - Use this where the retailer is confused over Omnivore functionality e.g. not understanding the difference between Shopify SKUs and MPNs and which value to use to create a Product Group.
  • Question - The most common ticket type. Use for all questions from retailers that are not in setup mode which don't fall into any of the other Types.
  • Request - Use this where a retailer / marketplace is asking to do something that can only be actioned by us e.g. set up a manual login, delete an account, switch them to Shopify multi-locations etc.Do not use this for check-related questions e.g. my shipping isn't working, can you please help? This is not a Request Type, it should be a Question.

Resolution


This field is used to track how we resolved the ticket. Note the following rules:


  • Closed Not Solved - Only use this where we are unable to understand what the issue was. Examples are when we ask a retailer for more information, but they never come back with it, when a retailer comes back telling us they've fixed it themselves etc.Do not use this for cases where we've provided an answer / fix, but the retailer has not followed up with confirmation it's worked. For those tickets use Solved by Answering Question or Solved by Troubleshooting.
  • Completed Request - Only use this if the Type field is Request. The Resolution can't be Completed Request if the Type isn't Request.
  • Escalated to Marketplace - Use this where you have handed the entire issue over to the marketplace to resolve. Generally the Type will also need to be Marketplace Bug / Issue and Resolution may often be Closed Not Solved as you won't know the final outcome.Do not use where you have only looped the marketplace in to assist with checking / verifying data or providing general assistance, but we have resolved the issue.The aim of this Resolution type is to identify how many tickets we are getting that are marketplace issues and the retailers are incorrectly contacting us for assistance.
  • Required Dev to Solve - Use this for all tickets that went to Dev Fairy and required a fix by the development team.
  • Sent Canned Response - Use this for all tickets tickets resolved solely by sending a canned response.
    If the retailer comes back with subsequent questions use Solved by Answering Question or Solved by Troubleshooting.
  • Sent FAQ - Use this for all tickets resolved solely by sending a FAQ.
    If the retailer comes back with subsequent questions use Solved by Answering Question or Solved by Troubleshooting.
  • Solved by Answering Question - The most common ticket resolution. Use this for all tickets where you assist the retailer, but you are not looking at data logs etc to identify the issue.
  • Solved by Troubleshooting - Use this for all tickets where you have to look at admin restricted type information such as data logs, jobs etc that the retailer can't see to identify / resolve the issue.Do not use for scenarios such as working out why shipping charges are being applied correctly and having to trace the setup via groups etc. If the information to resolve the issue is visible to the retailer then use Solve by Answering Question.

Use of "Other" for any field


If you believe your ticket's Issue or Sub Key Issue isn't addressed by the available options, consult your Team Leader before marking it as "Other." 

Please reserve the use of "Other" as a ticket type for situations when it's genuinely unavoidable.