Pain. The thing that makes our lizard brain flee, retreat, change course—anything to stop the pain. It spurs us to act. Scratch that. Pain spurs us to react. Pain reminds us what not to do in the future, motivating us to think twice about repeating an action.

Work pain is a unique beast, though. Usually, you can’t run off, banishing the pain from your observable universe. We have to face it. This recently became clear to me.

When Magoosh was small, receiving around 500 questions per week, a few people were able to handle feedback from our students. Students would find misspellings, misspeaks, errors, and mistakes in our lessons and questions. They’d let us know, and myself and a couple other people at Magoosh would manually add the issues to Asana where we track content errors and improvements.

When we grew, what we could do manually was now painful, nearing impossible to do. A year on, we had 1000+ questions per week and a team of remote test prep experts answering student questions and receiving content error emails. What had not changed was that I was still manually entering all this information into Asana.

That was my pain. I needed to escape this pain. But how?

Automate! That’s what you hear all the time. “Oh, just automate that.” Easy to hear, but hard to do, especially for me. I’d been teaching and tutoring for the past decade—not automating processes.

What people forget to say, though, is that automating is really just a form of problem solving. So my goal became problem solving, and even though automation was a tool that I used (poorly at times), I was able to make more progress by attacking the problem instead focusing automating.

What follows are the iterations of automating that I went through. I tried to include enough detail so that others could replicate what we did at Magoosh.

Zendesk Emails and Asana

My first attempt to automate our content improvement process started in Zendesk, software we use to manage incoming student questions. I knew that I could forward a question in Zendesk to an email address, and I knew that I could add a task in Asana using an email address. So, I figured that’d be a great solution! Let’s put the two together and see what happens.

Creating an email from a ticket and sending it out is a two-part process: first, we have to setup an email target, and second, we have to use this target in a trigger. Let’s start with adding the email target first:

Manage (gear icon) > Extensions > Add Target > Email Target

For the email address, go to the project in Asana where the emails will be sent, and click on the down arrow next to the project name. There you will find “Add Tasks by Email.”

Copy the email address and drop it into the Email Address section and update the target. The first part is done.

Now for the trigger. The goal of the trigger is to send off an email when a tag is added to a ticket and updated. For this case, I used the self-explanatory tag—content_improvement.

Here are the conditions for my trigger:

I am using the content_improvement_sent tag to ensure that my trigger doesn’t fire more than once. If I didn’t add this tag, I’d have no way of controlling how many times an email is sent to Asana from the same Zendesk question.

Now for the actual email. I want the body of the email to contain information from the Zendesk questions, so I used the Zendesk placeholder {{ticket.latest_comment_formatted}} to grab the last comment from the Zendesk question. The hope was that when the remote tutor responds to the student, it would make it easier for the content team to know what to fix. I also added the URL of the ticket so it would be easy to get back to the original message, which has links to the question or lesson that needs fixing.

(Writing this now, I already know that this is not going to work. Why would the last comment be useful for our content team? But I know more now than I knew then.)

With everything in place, I told our remote team to use the tag when they encountered a content error and waited for tasks to roll in.

Here’s a sample of what I saw:

Some of the tasks had relevant information, but we started to see information buried below a lot of back and forth conversations. Or the information that was there, wasn’t enough for the content team to know what they needed to do. That lead to the content team digging through the Zendesk to find the useful information.

This attempt did not work for a few reasons:

The information provided by the tutors was not always helpful or detailed enough to help our content team prioritize the issues or solve the problems.

1. I didn’t have enough control over how the the task was created in Asana, which meant that there wasn’t enough consistency.
2. Sometimes the ticket would have multiple back-and-forths, requiring the content team to spend a lot of time to understand the error.
3. And for some reason, it was repeating information in the task, such as the URL to the Zendesk question!

Back to the drawing board.

Hello Zapier

Even though the first attempt wasn’t a success, I knew what I could do to make it better: more control over how the tasks are created and create a better process for our remote team to follow.

With a little googling I found Zapier—a tool for connecting different apps, such as Asana and Zendesk, without any coding. Zapier gave me more control over the tasks created in Asana, and I could use a lot more Zendesk attributes, giving me more control over structuring the email, and thus the task, created in Asana. Sweet!

Creating a Zap is fairly easy. You need to link accounts, test that they are connected, and then you can start sending tickets from Zendesk to Asana.

Zapier, for all the great control it does provide, I discovered two little crooked parts during the set up. I couldn’t just grab a ticket with a specific tag. Zapier will only look at a specific view and grab tickets from that view, so I had to create a public view for tickets with the content_improvement tag. Easy enough. I made a new view:

Now I could choose the appropriate view in Zapier.

And set up the message/task for Asana:

The second crooked step was that I couldn’t get Zapier to grab a private comment from the assignee (I guess not all Zendesk attributes were available).The only solution I could find was to have Zapier use the last body comment made on the ticket. That’s what I was doing before with the Zendesk email, and I knew that the last comment wasn’t always helpful. To solve this problem, we needed a good process, an important part of making the automated content improvement process better.

Creating a Process

First, we had to structure the information that the remote team was sending. This is easy to solve with a macro. The macro will ensure that all the information our content team needs is right there, and our remote team doesn’t need to remember what to include. Here is the text of the macro:

Lesson/Question Title: [ADD LESSON OR QUESTION TITLE HERE]

Prompt Id: [IF IT IS A QUESTION, ADD THE PROMPT ID. IF IT IS A LESSON, DELETE ALL OF THIS LINE]

Author of lesson or question: [ADD THE NAME OF THE AUTHOR OF THE LESSON/QUESTION. THE LESSON WILL HAVE A PICTURE OF THE INSTRUCTOR. THE QUESTION AUTHOR IS LISTED UNDER THE ADMIN SECTION ON THE ANSWER PAGE

URL: [URL TO QUESTION OR LESSON]

Explanation of issue: [EXPLAIN THE ERROR OR ISSUE]

Using a macro provides other benefits besides structuring information. We can default the response to private since it would only confuse the student, and the macro will automatically add the tag. The goal of any good process is to make it easy to follow, especially in the flow of work. If the team knows about the macro, it will be very easy for them to be successful.

With the automation in place, tested, and successfully working, it was time to train the remote team. For any changes or updates like this, repetition of information is key. I sent out an email to explain the process and changes, and I wrote a doc with more detail and linked to it in the email. At the end of every month, we send out a newsletter, and so, I repeated the change there too. The hope is that if someone doesn’t see it the first time, they have an opportunity to see it again, and if they see it more than once then there’s a good chance that they will remember what to do.

Here are the steps that we originally outlined for the process:

1. Reply to the student, thanking them for pointing out the error and explaining that our content team will look at the error and prioritize fixing it. You can use a macro for part of your response: “Content::thank you for your feedback”
2. Update the ticket as Open
3. Return to the ticket.
4. Use the macro: “Content Improvement / Error in question or lesson” and fill out all the lines in the macro. Make sure your comment is private. You should also see the content_improvement tag too. 😀
5. Update the ticket as solved

Of course, nothing works perfectly. People forget. So I made sure to follow up with specific people to remind them about the new approach for the first week or so. I understand that it’s easy to forget a change like this. Following up with people is part of the automation process.

Soon enough, we had some success! The formatting made it easy to see the vital information. Having the author makes it easy to assign the task out. Links to the lesson or question, and a link to the ticket, means that the content team doesn’t need to search around for this information in the ticket. I can see who on the remote team filled out the information for easy follow up, and of course, a section that explains the error or issue.

Iterate and Make it Better

At this point, we didn’t touch the process for a month or so. It worked well enough and was easy for our content team to prioritize tasks. But with time, we realized there was even more that we could do:

This extra little step was going to make the process even better. With it, we could leverage a feature in Asana that identifies duplicates, thus making it much easier to see when something should become a high priority since it was affecting so many students.

For this change, we need to hop back to Zapier and change a few things. We need to use “Subject” to grab the title of the Zendesk ticket, and we added “Exam” as a custom ticket field recently, so we dropped that in the title too.

Again, once the Zap is in place, we have to update the remote team about the change in the process. This is a significant change too. They will need to actually change the title of the Zendesk ticket! (I ran a test to make sure that changing the title in the Zendesk ticket won’t do anything weird on the student’s side.) Another round of emails, newsletters, and follow-ups so that everyone was on the same page about the new process:

1. Reply to the student, thanking them for point out the error and explaining that our content team will look at the error and prioritize fixing it. You can use a macro for part of your response: “Content::thank you for your feedback”
2. Update the ticket as Open
3. Return to the ticket.
4. Write a private comment (“Internal Note”) to the Content team explaining the error. Use the macro: “Content Improvement / Error in question or lesson” and fill out all the lines in the macro. You should also see the content_improvement tag too. 😀
5. Change the title of the ticket to the lesson or question title (Click on the title and you’ll be able to edit it).
6. Update the ticket as solved

In Closing

As with any solution, rarely (probably never) is the first solution the best one. The key is to continually iterate on the process. To constantly look for ways to refine what you have.

The iterations we looked at are the most relevant ones. I spared the smaller iterations. We didn’t originally default the macro to make the note private. We didn’t always include the author of the lesson or question. Zapier now allows us to grab the last private comment from the assignee instead of the last comment, so I’ll be tweaking the process again soon. I also received feedback from someone on our remote team.

So I’ll be working on that soon.

Our work is never done. It’s never perfect. All we can do is take small steps towards improving what we have. That’s what we do and that’s what we’ll continue to do at Magoosh.