If you’ve shipped a product and you’re growing a userbase, you probably know how hard it is to find the right customer support system. At first, you just reply within minutes to every email you get, but then it gets tiring and if your product is even mildly successful, handling support can become a pain.
For years, we used Zendesk to receive reports and comments about our classic Inbox by Gmail app for Mac. When building a much bigger product, Boxy Suite, we soon slowly realized that we had a problem: we felt that Zendesk was messy, overly complex and cumbersome to use, while customer support should be frictionless.
Another reason that convinced us to look elsewhere from Zendesk was that even with our paid plan (the cheapest one), we couldn’t even easily see and export all tickets. That was the final nail in the coffin.
So we challenged ourselves to find, or create, a better solution. We wondered: can we set up a support system for free and with (almost) zero coding and maintenance?
Getting started with our customer support system
To get things started, we made a small list of must-have features:
- This system should be lean and easy to set up
- We should get an email for each new ticket and be able to reply easily
- Our apps should prefill the support form with user email, and app/OS info
- We should be able to see and export tickets in batch
- Bonus: tag tickets with relevant features or issues
- Bonus: commenting/threads on each ticket
After some research, we settled on these building blocks to create our own customer support system: AirTable for creating and storing tickets and Zapier to receive tickets emails. We already used these tools in the past and loved them.
Powering the support system with AirTable
AirTable is a Google Sheets on steroids — imagine if Google Sheets and a relational database had a child. It has superpowers that allow to sync sheets, create automations and easily filter and group records. Moreover, it support forms beautifully, so it really seemed like the perfect solution for us.
On AirTable, a document is called base and it can contain multiple sheets that interact with each other. To familiarize with it, we suggest starting from the Bug Tracker template, which also has a submission form and all kinds of field types that give a new overview of the power of AirTable.
For our system, we didn’t start with the
Bug Tracker template though, since the main sheet should be
Reports, which would be support ticket system where we gather user bug reports and feature requests. Actual issues, which the reports would point to, will go into another linked sheet (more on this later).
Here’s how the main sheet looks like, with user reports coming in:
As you can see, fields in AirTable have different types, so an email is an actual
Type field is a
Single select field, meaning that we defined some options that users can choose from a drop-down menu. You can find out more about field types here.
The great thing about this system is that we can view, group and sort tickets in all kind of ways, with the maximum degree of flexibility. This is something that few dedicated commercial solutions offer. The way you do it is by creating additional views for your current sheet. We have many views, and actually the screenshot above is taken on a
Light View that hides fields like
Version and Build Number or
Has Attachments which are “technical” fields we don’t want to see all the time. Besides, when you expand a ticket, you can see all the fields anyway.
We also have a
Gallery view that gives a nice visual overview of the new tickets (you can customize these cards to show what you need):
So, how are the users sending tickets? We’ve created two forms (here‘s how to do it): one accessible from the apps — auto-filled with app and system info, you can see it here) — and one that is more generic and we put on our website. Via these forms, the AirTable base crates a record for each new support request. If you’re wondering how we get an email for each ticket, just keep reading because we’ll get to that. So, here’s how the system looks in action:
Tagging and counting issues
We were already quite happy with this system, but we realized that to make it more complete and comprehensive, we needed to add support for actual issues and feature requests, as mentioned above. The current situation was dire: we had some issues open on GitHub and some lists of issues on Dropbox Paper, but not a single source of truth.
To leverage the flexibility of AirTable even more, in our
Reports sheet we created two new fields, one to tag issues and one to tag feature requests. The issues and requests themselves would be in two different sheets in this same base, so we used what AirTable calls a
Link to another record type field.
How do we tag issues and feature requests? Every few weeks, we review all new tickets and create or link existing items from the linked sheet. All existing items populate the popup menu when you click on the linked field, it really works like a charm.
The linked sheets is the actual “bug tracker”, so we added some fields to make it work like one, like
Priority. We keep it very lean, but following the
Bug Tracker template example, it could become much more complex and useful.
So now we have a single system where we get tickets, and where we create and organize issues and feature requests.
But there’s still a missing piece: how do we respond?
Receiving and responding to tickets via email
If you’re a maker and you don’t know Zapier, stop reading now and check it out. It will make your life better. It might remind you of IFTTT, but it can do much more, with many more services. It lets you create workflows (Zaps) that connect apps, with any number of steps in between, and continuously run in background.
We created a Zap that is triggered when a user fills the support form, then it formats and sends an email to our shared inbox.
The Zap starts with an AirTable trigger,
New Record, which continuously checks an AirTable sheet of choice for new records. Then a
Send Outbound Email action does the magic. It looks like this:
As you can see we even grab files uploaded by the users and handle them as actual email attachments, and we format the email with HTML markup to make it look really nice. When you create a Zap like this, make sure to have submitted a few sample tickets to your form using all the available fields: in this case, sample tickets without attachments would make it hard to create and test this step.
A very important field in this action is the Reply To, where we put the user email so we can just hit Reply in Gmail to respond and start a thread with the user.
A non-obvious part of this action that is really important is embedding a link to the original ticket on AirTable. To do it, I grab the
Record id field and prefix it with the URL of the specific AirTable view where the tickets come from, which looks something like
https://airtable.com/tblwOSNPA31LASKu/viwFPoSOINAAUvRQU (this is a fake URL).
Finally, here’s how a support request looks in our inbox. Thanks to the setup explained above, hitting reply works just like if the user directly sent us this email, starting a thread with him/her.
That’s it. This system is working flawlessly for us, but it could certainly be improved.
Is this really free?
When you set this up and have an initial working setup, this is actually 100% free. During the whole Beta Program for Boxy Suite we used this system only, without paying a cent, so that’s really great to get things started and tweak the system until you’re happy with it.
When the number of tickets grows, you might need to upgrade AirTable to their Plus plan for $12/month, and Zapier to their Starter plan for $18/month. So, for a fully functioning customer support system with hundreds of tickets per month, you would end up paying $30/month, which is great if you consider that you’re also unlocking countless other workflows with AirTable and Zapier.
Remember that you can also just downgrade anytime and stop paying if you don’t need that bandwidth anymore, and still have access to all your tickets.