From Steven Maguire, VP of Tech @ Earth Class Mail
One of the key value propositions of Earth Class Mail is the ability to access important business information, the kind contained in your mail and physical documents, from anywhere in the world.
This same principle drives the development of internal tools that we use to ensure our customers have a positive experience with our services.
Two of the third-party tools that we use a lot everyday are the Chargify recurring billing platform and the Zendesk customer service platform. They are “mission critical” and we couldn’t deliver the level of service our customers expect without them.
Each of those tools contains important information about each customer, their accounts, history, pending support requests, and the like.
We noticed that our own team members were switching between Chargify and Zendesk dozens, if not hundreds, of times everyday.
We also observed that the primary reason for switching to Chargify’s web UI was to view read-only data within Chargify’s platform. That is, they were just looking at customer information, not taking any billing related actions.
That observation led us to a very natural and, it seems now, obvious hypothesis:
If we eliminate the need to switch between Zendesk and Chargify, then our team members would be more productive and be able to provide better service to customers.
Fortunately, Zendesk supports a third-party application development platform, that means we can build internal tools that will work natively in the Zendesk platform. So now we have a great opportunity to test our hypothesis.
We’ve also decided to make our Chargify Zendesk app open source, so that anyone can use it. The reasons for that are:
- Zendesk apps are not how we make a living.
- The more contributors there are to this project, the more we will all benefit from a better product.
- If we can make it easy for other businesses to provide better customer service, then we’ve done some good in this world.
We’ve built, tested, and released a minimum viable product of the open source Zendesk app, here’s how:
After reading the documentation for Zendesk’s Apps Framework v1 we learned a few things:
- Zendesk published and supports a ruby gem to aid in the development of a custom third-party app.
- Among the tools provided by the ruby gem were:
- A tool to create and scaffold a new blank project.
- A tool to lint and validate the code that you write for your project.
- A tool to package your application code in a zip file that will be uploaded, unzipped, and installed within your Zendesk account.
- Zendesk supports a third-party app marketplace where you can find and install public applications; some free and some paid.
- Zendesk supports installation of private apps without going through the marketplace.
With these observations in mind we created a goal for the experience of our app:
Whenever a Zendesk agent is viewing a customer profile or ticket, we want to use the email address associated with that customer or ticket to display customer and subscription records from within Chargify.
After some research we discovered that a single email address can be associated with more than one Chargify customer record, and each Chargify customer record can be associated with more than one subscription.
This discovery drove the decision to include two views:
- A customer search results view, and
- A customer detail view.
Using the “app.activated” event emitted by the Zendesk application framework we attempt to load the customer search results view first.
During the creation of this view we use Zendesk’s Data API to fetch the customer’s email if we are looking at a customer profile view in Zendesk, or the requester’s email if we are looking at a ticket.
With this value in memory we issue a customer search to Chargify to fetch customer results.
We introduced a few use cases here:
- If no Chargify customer records are returned we update the search results view with an “empty results” alert.
- If more than one Chargify customer records are returned we update the search results view with a list of each of those customer records as links which will load a customer detail view.
- Finally, if a single Chargify customer record is returned we redirect the application to that customer detail view; we feel a search results page with one result is not valuable.
When loading a customer detail view we issue a couple other calls to Chargify to first fetch the fully hydrated customer record as well as a second call to fetch each of the subscriptions associated with the customer.
When all this data is available we update the customer detail view to display the data.In order to facilitate these API calls to Chargify our Zendesk application needs to know two pieces of unique information:
- The subdomain associated with our Chargify account
- The API key associated with our Chargify account
Fortunately, the Zendesk framework provides a way to ensure we can gather and securely store that information during installation.
In the unlikely event that the app begins running and that information has not been set, the app will display a third settings view with instructions on adding that information via the Zendesk API.
Another hat tip to Zendesk here as they have made the installation and management of third-party apps very simple and straightforward.
The process involves:
- Downloading the zip file of the latest binaries
- Uploading the zip file
- Accepting some terms and conditions
- Providing subdomain and API key
That’s basically it! Be sure to read the documentation on the project page for a more granular walkthrough.
Additionally, if you need to update your subdomain or API key, you are welcome to do so via the API or a point and click interface provided by the Zendesk App management tool.
Once installed the app will appear in a new pane to the right of a Zendesk user profile view and Zendesk ticket view.
We mentioned previously that this project was designed as a minimum viable product, and that’s what we’ve delivered here. While our team is really enjoying the current version, there is plenty of room for improvement.
Here’s a short list of immediate opportunities that we see:
- Add client side caching to reduce API traffic to Chargify’s API
- Add nested detail views for things like Subscription Statements, Subscription Invoices, etc
- Add some update operations to push data into Chargify’s API
- Add the project to the Zendesk App Marketplace
- Minor enhancements designed to get novice engineers involved in open source; look for the “first-timers-only” label in the issues.
Contributions to the project are very much welcome in regards to any of the items listed above, or any other improvements you can dream up!