How we migrated 500K+ customer cases to Help Scout

When you have a case history in excess of half a million, the thought of switching help desk software can be more than a little daunting. But in June of this year, the Customer Service team at Olark decided to take the plunge.

As we undertook this behemoth of a help desk migration, we made a note of some of the things we did to make it go smoothly.

Today, we’re sharing our top tips with you!

Why switch help desks?

We all like comfort zones. Even comfort zones with wrinkles and oddities can be comfortable. We know the wrinkles, we expect the oddities, and we feel safe. Historically, despite the occasional frustration, our CS team had felt safe and comfortable with our help desk software status quo.

Over the first half of 2017, however, the occasional frustrations became more frequent and grew louder. It became really clear that we needed to have a conversation about a possible migration, and what the implications of that were.

When I heard that the team wanted to find a new tool, my first instinct was to push back. I muttered something about it not being part of the roadmap and "maybe in six months."

Then I had a coffee and a stern conversation with myself. Sometimes the needs of the team have to take precedence over the roadmap. I decided to detour.

As a lifelong list writer, I started with a list of pros and cons.

Cons:

• 500,000+ cases will need to be moved. That feels scary.
• We have a lot of channels, and a lot of moving parts. Updating all of that for a new help desk also feels scary.
• If we mess it up and lose case history, people will be very upset.
• If we really mess it up and people can’t contact us, they will be even more upset.

Pros:

• Happier team
• Chance to start from scratch with new workflows
• Happier team
• Better, faster, customer service if we find the right tool
• Happier team

As the CS Director at Olark, I want two things: happy customers and a happy team. Team morale was taking a pounding, partly due to increasing frustration caused by the existing tool, and partly because there was no concrete plan to even evaluate a possible migration.

My list also spoke volumes. Being scared is not always a good reason to decide against something. My desire for a happier team and happier customers won the day.

How to evaluate a help desk solution

My first task was to let the team know that we would look into a migration, and that the whole team would be involved in the process. Because it was a big project, we would need everyone to take on some extra work to make it happen.

Step 1: Figure out why you want to switch help desks

Write up a document that outlines the pros and cons of moving, and ask the team to weigh in with their thoughts. When we went through this exercise, it became clear that evaluating another solution was the way forward.

Step 2: Create an evaluation method

In our case, I used the document from step one to create a wish list. We categorized everything on the wish list as either a “Must Have” (e.g., intuitive search, JIRA integration), “Should Have” (e.g., ability to copy and paste images inline) or “Nice to Have” (e.g., free ponies), and then we compiled a list of possible software options.

Step 3: Evaluate your help desk options

Each member of the CS team evaluated a piece of software. If it didn’t meet all of the “Must Have” criteria, we crossed if off the list and moved to the next option. 

To narrow down the possible options, we evaluated remaining software options against the “should haves”, and then the “nice to haves”.

Step 4: Choose a new help desk, and get consensus

Make sure the team has consensus. Once we had a final contender, we met as a team and I asked everyone for their opinions. I made a point of personally checking in with anyone who didn’t speak up at the meeting, to make sure that they were comfortable with the choice.

Step 5: Embrace reality

Take off your rose-tinted specs. However good the solution you pick appears to be, there will always be teething troubles and a whole new set of wrinkles. Once you are clear about the reality, go through the list of requirements with a fine-tooth comb, and try to think around corners.

Our final pick was Help Scout.

Their product hit almost all of our requirements, we loved their human attitude toward their software, and we were impressed by how approachable they were.

How to plan and execute a help desk migration

When it came time to plan the actual migration, it quickly became apparent that the evaluation was the easy part. I live and die by my lists, and the migration to-do list was mighty long.

Step 1: List all the channels that come into your help desk

For our team, this list included:

• Email—this seems obvious, I know, but how many different email accounts feed into your help desk? We have several, and I discovered three I wasn’t previously aware of.
• Twitter
• Chat
• Formstack
• Stripe
• Nicereply
• Disqus

Most of these could be easily re-routed, but we had a few issues. Right now, Help Scout doesn’t support answering tweets inside the help desk. Our old solution did. One of the first things I did was to create a new Twitter workflow using Slack, so that we got used to not answering support tweets in our help desk. That made the transition easier as the team was already used to the new workflow.

Formstack doesn’t have a direct Help Scout integration, so I used Zapier to create a connection between those two platforms, which made information sharing seamless.

Step 2: Migrate your case archive to the new help desk

We needed to migrate an archive of 500,000+ cases.As previously noted, that number felt scary—but Help Scout could not have been more helpful. They took care of the import. With an archive the size of ours, we ran into a few issues, but the majority were ironed out pretty quickly.

Step 3: Think about your custom help desk setups

We had a few custom set ups in our old system, such as:

• Tags
• Rules & Filters
• Custom fields
• JIRA integration

Additionally, every member of our 40-person team would need a unique profile in the new system.

We were able to deal with our custom setups as follows: 

• Tags and team profiles: Turns out that importing the case history also imported tags, and Help Scout automatically set up our team profiles as part of the import. Boom.

• Rules and filters: We decided to take a little extra time to reconstruct our rules and filters thoughtfully by hand, rather than just copying workflows verbatim from our old help desk—some of those rules had been around since Noah came out of the ark, and we wanted to start with a clean slate. The team knew it might mean a crazy inbox for a few days while we figured out what to do with emails that had previously been automatically resolved, assigned, or otherwise dealt with, but we decided that the benefits outweighed the hassle.

• Custom fields: In our old setup, we passed custom data (such as links to billing software, customer IDs, and internal account information) from our app to our help desk using custom fields. Help Scout treated custom fields differently, so we put our awesome support engineers in charge of creating a static app inside Help Scout to pull in the data we needed. Post-migration, those same engineers built a dynamic app to supercharge our agents by putting additional account data, such as recent billing events, at their fingertips.

• JIRA integration: One of our “Must Have” requirements was a solid JIRA integration. Because we use JIRA for bug tracking and feature requests, integrating JIRA with our help desk allowed us to reduce the time it takes for chat agents to send customer issues and requests to our engineers. Our folks on chat can now send information directly to JIRA, which cuts down dramatically on time spent copying, pasting, and transferring information. We road tested the Help Scout JIRA integration thoroughly prior to migration, and it delivered in spades.

Step 4: Train your team on the new help desk

Because we do All Hands Support at Olark, we needed to train all 40 of our employees to use Help Scout. Again, Help Scout delivered—this time by running and recording a training session via Zoom, so the whole team could learn together. We ran the training a couple of days before we transitioned, and emailed out the recording link to ensure it was fresh in everyone’s mind.

Big happy team cavorting at our annual company retreat. Keeping anything fresh in these minds is a challenge! 

Step 5: Set a date to switch

Not long after we began the migration process, I set a target switch date of June 28th. We successfully switched on June 28th. I suspect the entire Olark team was sick and tired of hearing about the Help Scout migration and the June 28th date, because I took the opportunity at every meeting to remind people when it was going to happen.

Apart from me sounding like a broken record, having a date was really valuable. The migration took no one by surprise, and as the date approached, the entire team was cheering CS on.

Step 6: Do it!

When the target date arrives, go! To reduce day-of stress:

• Make sure you have a list of all the integrations you need to switch over.
• Make sure you have access to the main email account for your support team.
• Make sure you have set up your users, sent out account invitations, and done as much setup of basic workflows as you can beforehand.
• Follow your to-do list to the letter, and tell people what you are doing as you do it. When making as big a change as this, you cannot communicate enough.

Here’s what June 28th looked like for me:

• I switched our integrations to Help Scout, then switched the main email account.
• I ran an export in the old help desk to gather up any customer cases that had come in between the first export and going live.
• I drank a lot of coffee, and panicked from time to time.
• I checked and double checked everything.
• I forgot to switch the Google Apps forward on after setting up the Help Scout connection, but I figured it out after a few minutes and I don’t think anyone noticed...

Throughout the day, I tried to remember that I needed to cut myself some slack. Switching help desks is a stressful process, and things can go wrong. That is both expected, and okay. Keep communicating and forge ahead.

Step 7: Tidy up after yourself

No matter how long and detailed our lists are, we all forget something. In my case, I didn’t realize that our chargeback email notifications did not go directly into our main inbox, but instead took a circuitous route via a personal inbox before being forwarded to the support inbox. It took us a week to notice they were missing, and a day of digging before we figured out what on earth was going on.

These things happen. Just allow a little time after the migration to find them, fix them, and apologize to any affected customers.

Step 8: Celebrate!

Let your team know they did an awesome job. We got help from our execs, engineers, HR, the security team—heck, everyone! CS was supported all the way, and everyone did an awesome job. In the end, no email was left behind, and I count that as an all-hands-hands-down win.