Many of our customers have asked us how Fog Creek does customer service. Joel has already written a great article on Seven steps to remarkable customer service, which can be put in place at any company. We also wanted to share some of the specific customer service implementation details put in place here at Fog Creek. This post—the first in a series on customer service—will go into detail about how we handle email support.
Posts in this series:
- Fog Creek’s Email Workflow (this post)
- Better Customer Service with Snippets
- Schedule Calls, Protect Your Support Team
- Know the Responsibilities of Your Team
- Big Board: Having Fun with Data
A Quick Video Tour
This video provides a quick walkthrough of how a support email gets processed once someone submits an email via the contact form on our website. If it feels a bit rushed, don’t worry; I will explain everything in detail below.
Email Set Up
We primarily try to channel our support inquiries through email and we use FogBugz to handle all customer support messages. While we use Google Apps email to receive notifications and for personal communication, everything customer-related is almost exclusively handled through FogBugz.
Within FogBugz, we have a single Inbox project for our current paid-for products (FogBugz, Kiln, etc.) with cases automatically sorted primarily into either a Sales or Support area. Since we strive to respond to each customer email within one business day, we turn off the auto-reply for each of our mailboxes and set the due date to 7 Working Hours.
We also made a small modification to the default workflow so that when the customer responds, the case will be assigned to the person who last emailed the customer.
How Customers Email Us
You might also notice a “Record a screencast” button on our Email Us page. This button uses Screenr Business to help the customer record a screencast of their issue. Once the screencast is submitted, Screenr sends an email to email@example.com with a link to the Screencast. We love this feature because of how quickly it can speed up the “Oh that’s what’s wrong!” aspect of troubleshooting.
No Cherry Picking
We set the primary contact for the Inbox project to a user called ‘Up For Grabs.’ To discourage cherry-picking, we run a random assignment script every hour, which looks for cases assigned to Up For Grabs and reassigns them to members of our support team (we have a similar script that runs for sales). This allows each member of the team to focus on their personal case filter instead of periodically picking from a filter that’s shared by the entire team.
Send & Close
When we reply to a customer, we almost always do so using ‘Send & Close,’ which sends the email and then closes the case. This behavior implies that we consider our work done until the customer responds, either because we’ve solved their problem (hopefully) or because the customer needs to provide additional information in order for us to continue troubleshooting. (If you use Send & Close, be sure to make the aforementioned workflow modification).
Separate Inbox Work from Engineering Work
At a small enough scale, it’s manageable to simply fix bugs as they’re reported and immediately respond to the customer that the bug is fixed. As more support emails start coming in, this can quickly become untenable.
Although it may not be obvious, there are actually two distinct work items at play when a customer reports an issue:
- Respond to the customer
- Fix the Bug
This applies both for legitimate bugs (e.g. “flagrant error occurred when trying to check email”) as well as issues that merit being fixed two ways (e.g. “based on the error message, customer didn’t realize they didn’t specify their mail server. Easy workaround, but a clearer error message would be helpful”). When these kinds of emails come into FogBugz, we’ll spawn a new case into the engineering project and put ‘See Case XXXX’ in the description to refer back to the original case.
Sometimes a bug fix is required before responding to the customer. We’ll keep the email case open as a reminder to check in with the engineering team. The engineer can fill their case with ugly stack traces and esoteric notes while the inquiry case remains reserved for communicating with the customer.
Mostly, we simply use “Send & Close” for the inquiry case and the bug case is handled in the development team’s triage process. This means the work of responding to the customer is considered done even if the bug is still open. If the customer responds to check the status of the bug fix, the inquiry case is reopened and a reply is needed per our usual one business day response time.
We recently blogged about the Case Event Merge Plugin, but it’s worth mentioning again here. Since we have “Reply Automatically” turned off, sometimes customers will fire off a separate ‘one more thing…’ email that creates a new distinct case, thus two (or more) cases for the same email thread. The Case Event Merge Plugin allows us to resolve the duplicate case and have all of the separate emails show up in the original case, essentially collapsing the conversation into a single thread.
In the bottom left corner of our cases, we show a ‘mini search’ that tries to match the case correspondent with our internal customer database. This is a simple iframe embedded via a BugMonkey script and it saves us lots of time looking up customer information.
While we have a lot of tiny little hacks to get email just right, all of them are relatively easy to implement. Your workflow is probably different from ours, but hopefully you’ve found something that you can apply to your environment to improve email support. The key point is to be fearless when it comes to changing and customizing FogBugz to meet your needs.
If you have any additional questions about how we implement our support workflow, don’t hesitate to send us an email.