Skip to content

Proposal to implement a user controlled form of contact management for Zendesk Global

Problem Statement

Our current system of contact management is a very manual process requiring an end-user (ie customer) to reach out to the Support Operations team via a ticket to get changes to their organization's current contact list. This is time consuming, not user friendly, and is not scalable at a certain point.

Because of this, we've had to impose limits and processes and rules galore. Some notable examples:

  • Max 30 contacts
  • Requiring unassociated users to prove entitlement
  • Regular audits to find organizations over the contact limit
  • Creating a contact limit exception policy
  • Using SFDC contacts as a source for support contacts

Proposal

We move to a setup where the end-users have the ability to manage their contacts. With this, an organization could have up to 50 contacts based on API limits with Zendesk. The core concept is a AM project has a contacts.yaml file. When that file is updated, a webhook triggers a pipeline to sync the changes over to Zendesk. In this way, we can move to users who are not associated being directed to speak with their organization who controls who can and cannot submit support tickets under their organization.

By doing this, we can:

  • Increase the max contacts to 50
  • Put the power to manage those contacts in the control of the customer
  • Stop using SFDC contacts as a source of support contacts (when they are meant as sales contacts)
  • Significantly reduce the "Needs Org" work
  • Potentially remove the "prove your entitlement" process as a whole

Chart of what this would look like

graph TD;
  A --> B
  B -- No --> C
  C --> D
  B -- Yes --> D
  D --> E
  E --> F
  F --> G
  G --> H
  H --> I
  I --> G
  A(Ops checks for existence of a Account Management project for the org)
  B{Does one exist?}
  C(Ops creates and sets up a new Account Management project for the org)
  D(Ops sets up Account Management project for contact management)
  E(Ops adds the sold-to to the org as a Maintainer for the project)
  F(sold-to adds other Maintainers to the project at their discretion)
  G(A Maintainer modifies the contact.yaml file)
  H(A webhook triggers a sync pipeline at ops.gitlab.net)
  I(The pipeline syncs the changes to the org)
Edited by Jason Colyer