Zendesk Ticket Exporter

Goal

This project exists to create a database of resolved tickets that Sourcegraph indexes. This allows Support Engineers to leverage the power of Sourcegraph search to rapidly find solutions to past customer tickets which can assist them in solving current tickets.

Value

  • Enable Sourcegraph search functionality to rapidly find closed Zendesk tickets.
  • Increase ticket closing velocity by increasing access to proven solutions.
  • Give context to potential root cause earlier in the ticket solving process.
  • Increase Support Engineer onboarding speed by enabling focused searching for tickets by service, root cause, version, etc.. to find common issues in each problem space.
  • Formal template encourages good record-keeping practices, including recording all troubleshooting steps.
  • Increases the time span for information retention, as GitHub will retain these records long after Slack has archived them.

Video Demo

A Quick Video Tutorial on how to write and add case summaries.

Growth Areas

  • If this product proves useful, we can improve the data transfer process from Zendesk to GitHub with more automation. For example, a way of automatically exporting summaries to Github.

How to Write a Well Formatted Ticket Summary

  • GitHub Markdown Cheat Sheet
  • Ticket summaries should not take more than 10 minutes to create.
  • Ensure that search terms you might use to find this ticket are present (e.g. batch changes, code-intel, scaling, permissions, error messages, etc…).
  • Remove personally identifiable data from any logs
  • Write out your troubleshooting process in a step-by-step format, including critical information needed to solve the ticket gained by asking the customer.
  • If you found any docs pages useful, link them for future Support Engineer reference

Ticket Summary Workflow

  • The summary exporting process begins when a ticket is ready to be closed.
  • Begin by opening the Zendesk Macro menu.
  • Select the appropriate Macro for your ticket:
    • Defect Report Summary
    • How-To Summary
  • Data is automatically populated from various sources. If any fields in the automated header are not filled automatically, check our usual data sources and fill manually.
  • Fill the fields marked “for manual CSE entry”:
    • For links, use the GitHub Markdown link format [Display Text](Link URL).
    • The summary should be a concise 2–3 sentence explanation of the issue.
    • Troubleshooting steps should be a bulleted list of steps taken.
    • Resolution should be the root cause of the problem, and the action taken to rectify the issue.
    • Error logs should be trimmed to only include necessary lines, and all personally identifiable information should be redacted.
  • Once the summary is complete, upload it to the GitHub repository linked in the template.
  • Use the ticket name automatically generated by the ticket summary template.
  • Preview your summary in GitHub to ensure the formatting is correct.
  • Submit the file to the repository

Ticket Search Workflow

Information Security Guidelines for posting Logs

Since we are encouraging Support Engineer’s to upload relevant sections of logs to the private Sourcegraph GitHub repository, we have additional security responsibilities to prevent uploading sensitive customer data. These are WIP guidelines for uploading logs. These guidelines will be linked to or embedded in the macro for Support Engineer visibility.

Information that CANNOT be present in github:

  • Tokens / Keys of any kind.
  • Information that could identify any customer employees (names, email addresses, etc…).
  • If any information in the logs you intend to post contains insecure information, remove it and replace it with REDACTED.
  • Post smaller chunks of logs to avoid missing keys and identifying information.