Community discussion: What custom fields have you created?

8 Comments

  • Spike

    We recently decided to move all our client data from our Podio intranet into Zendesk.  

    We created fields for organization (since our clients are all multiple users at organizations) for things like launch date, what features they are using, what genre of art group are they, which sales rep closed the deal, who the primary and financial reps at the org are, etc, etc.  

    Now when a new client comes on board our admin staff creates the organization, fills in all the fields we know, and then hands it off to the CS rep to contact them and proceed with their setup and training.  

    For all on-boarding pieces, we open tickets and use macros to populate the ticket for each individual piece of their setup process to track it from initial communication through to completion. 

     

    On the person side, we've added custom fields as well to track if the user is a beta tester, what level of technological comfort do they seem to be, if we generally assist them with setup pieces ongoing, or are they more self sufficient, etc. 

     

    By having all of these fields in ZD, our cs reps can reference them easily. 

     

    Two things we've had to do as workarounds, or are hoping for in the future:

    1) We've had to make all our cs reps admins, so that they can update the organization fields since we want them to be able to easily note if a client is using a specific type of printer, or a specific module of our system, etc. 

    2) We are hoping that in the future we'll be able to segregate lists by custom organization field so we can pull out users to mail through the mail chimp app connection based on criteria about the organization, since for us as "client" is an "organization".  The end users are grouped by the organization they work for.  

    0
  • George Carvill

    We are just getting into Zendesk. I have created a number of custom fields in both JIRA and Zendesk to give the users of each application the information from the other. We are using the current Zendesk/JIRA connector, not V3, because we have an on-premises JIRA deployment.

    As to the Zendesk fields:

    1. Working Description -- This is a workaround for the way Zendesk treats the initial description of a problem as a comment. When the Zendesk issue goes to JIRA, the Zendesk 'Description' value is mapped to a read-only JIRA field named 'Original Description.' Then JIRA, using the Creation transition, copies the contents of 'Original Description' to 'Description.' That field is set up with a bidirectional link back to Zendesk to 'Working Description,' and the text flows into that field. From that point forward, the two fields are sync'd.
    2. Product - This is a bidirectional sync field recording in which of our products the issue was reported.
    3. Change info - Field is a one-way-from-JIRA sync reporting the developer's comments on the software change.
    4. Release Date - Field is a one-way-from-JIRA sync reporting the date the software change went live.
    5. Project Assignment - Field is a one-way-from-JIRA sync reporting to what JIRA project the issue was assigned. The JIRA issue will remain in the Support project.
    6. Project - Field is a one-way-from-JIRA sync reporting the name of the JIRA project where the issue resides. (We don't normally move these issues to their own JIRA project, preferring to keep them in one project for tracking, but this field lets Zendesk know if the issue was moved.)
    7. JIRA Priority - Field is a one-way from JIRA sync reporting the JIRA priority field value.
    8. Initial QA Tester - Field is a one-way-from-JIRA sync reporting the name of the person who performed the first testing of the change.
    9. Final QA Tester - Field is a one-way-from-JIRA sync reporting the name of the person who performed the last testing of a change. Often Support wants to discuss a change with QA if the custom reports a problem with the change.
    0
  • Colin Piper

    We are a basic support help desk servicing external customers. I have many custom fields.

     

    Organization custom fields

    • Account ID. The ID of the customer. Used to link to our Salesforce
    • Account Manager. Currently unused but will be used to auto cc the account manager on new tickets from key customers
    • Support Level. Used to set the SLA targets for a customer.

    Ticket custom fields

    • Contact Name. Allows the customer to provide an alternative name from the one we have on file
    • Contact number. Essential so we know what number to call back on
    • Type of Issue. We find that customers are terrible at describing their issue so we give then a nested drop list of symptoms to chose from. We then use this as the the Subject of the ticket. We do not get them to enter the Subject as this would just cause duplication
    • Severity. This replaces priority (which we only use behind the scenes). We work issues based upon the SLA of the customer and the severity of the issue.
    • Source. This field is a shorter list of ticket channels but also separates out web form ticket raised by customers from those created by our agents when they answer phone calls from customers.
    • Waiting state. When we put a ticket in to pending or on hold, we manually or automatically set this field to indicate why. When a ticket is Pending the state reads Waiting but when the customer responds and the ticket switches to Open, we update this field to say Response. Agents can then see their open queue and which have had responses. For on hold they agent sets a reason allowing us to better follow up on these.
    • Due Date. This is not the system due date. For our SLA we use response and resolve targets. My agents work top down through one list of tickets and the due date is set via a webservice to provide an order list of tickets taking in to account that we may need to resolve one ticket before we respond to another.
    • Brand. We support multiple brands and this field is set automatically by the email address the ticket was sent to. We use the brand field to change the signatures etc on emails.
    • Department. Groups are fine but we have many groups for creating different views. For a reporting perspective though we need to narrow this down to just 4 departments. It was easier to do this as a custom field than constant updating reports. 
    • Category, Cause and Reason. These three fields allow us to segment the tickets for reporting reason. What was the actual type of issue (rather than what the customer perceived the issue to be), what caused the issue and what was the reason it needed to be escalated to us. We use this data to build business cases to get products change or recruit additional staff to write documentation etc.

    We have several others but mainly associated with Cloudset which we use for SLA management or for other apps such as time tracking.

    0
  • Larry Browne

    We capture the SIP address, calling phone  number and destination phone number from incoming calls for our agnts and store them in fields with our Chrome plug-in. We also have fields that can do lookups to our API for the username and UID, the number of users in the account, if there's a customer retention issue, and if one of our resellers was involved.

    We also have fields for escalated tickets that capture the WAN Ip address of the customer's network for log reference, ISP for tracking patterns, and router make/model, OS, Browser for use case lookups.

    0
  • Ben Desmarais

    Here's our list of some ticket fields we added. We support external users on a SaaS solution.

    • Browser Type/Version - Since our product is a SaaS solution, sometimes it's important to know which browser and version the issue was found in.

    • Build Number - This is the build number where the issue was found in.

    • TFS Number - If a resolution requires development to review/fix or it's a feature request, we add the TFS number to the ticket.

    • Resolution - Describes what was done to resolve the ticket. Helpful in views. (required before solving)

    @Colin - I like your suggestion of using a "Source" field. I'm going to implement that. I need to know if the ticket came from an email, form on our product, help center form, call in, etc.

    Once the new ticket date field is implemented (https://support.zendesk.com/entries/72529-request-the-ability-to-add-a-date-custom-field-or-for-users-to-modify-due-date-field), I'm also going to be adding a date field so the agents know when to follow up when a customer who has put a ticket on hold.

    0
  • Andrea Saez

    It all depends on what info your company is trying to gather. Coincidentally, I wrote a post about it recently: https://support.zendesk.com/entries/38652168-Why-having-the-correct-ticket-form-is-important

    0
  • Kristof Van Kriekingen

    I'll hop in.
    We got a lot of custom fields but we don't really use them yet.
    We plan too I promise! ;P

    • Type of issue
    • URL
    • Browser
    • Affected Version
    • Due Date
    • Fix Version
    • Component/s

    Most of these fields will be synced into our Jira.

    Type of issue:
    Import/Bug/Improvement/Feature Request/Question/Other

    URL:
    The url of where the issue is occurs. If customers actually filled this in, the testing process would go so much faster.

    Browser:
    IE8/IE9/IE10/Firefox/Chrome/Safari. Its mostly not filled in but our customers use 90% of the time IE.

    Affected Version:
    The version of the software. When the bug is reported and in what version it occurs.

    Due Date:
    Not for me, no clue why our team fills it in ;P

    Fix Version:
    To see with what release or bugfix/hotfix the bug will come.

    Component:
    To see the subject of the software so it's easier to filter in Jira.

    We only show URL / Browser to our customers, they have nothing to do with what lies behind the scene's.
    The rest is just more info for our Test/Dev team.

     


    I saw a lot of nice stuff here which I might use myself in the future ;P
    @George

    1. Initial QA Tester - Field is a one-way-from-JIRA sync reporting the name of the person who performed the first testing of the change.
    2. Final QA Tester - Field is a one-way-from-JIRA sync reporting the name of the person who performed the last testing of a change. Often Support wants to discuss a change with QA if the custom reports a problem with the change.

    This looks interesting to use ^_^
    Maybe not just for test but also Dev.

    Well I shared our fields now! I hope to see more upcoming so I can compare and maybe improve our flow.

    Kind regards
    Kristof

    0
  • Jennifer Rowe

    Thank you all for the clear, well laid out replies. Great information here!

    And I love that you are borrowing good ideas from each other--that is the point of this after all! :)

    0

Please sign in to leave a comment.

Powered by Zendesk