CrunchTime’s Experience with Help Desk Migration Service

About CrunchTime!

CrunchTime! was founded in 1995, when we created the first web-based restaurant back office system. Since then, the world’s best brands representing tens of thousands of restaurants have chosen CrunchTime as their integrated back office solution, and is now considered the industry gold standard.

CrunchTime employs approximately 170 full-time staff with the main headquarters based in Boston, Massachusetts in the USA.

CrunchTime is restaurant software that optimizes food and labor operations, our back-office solution has everything you need built-in to reduce food and labor costs, improve the guest experience, and increase profits in all your restaurants.

How did you like migrating data using our service? Was the process confusing at any point?

We looked at a couple of different solutions for the migration and we initiated our migration with each solution to evaluate the capabilities and found that Help Desk Migration (HDM) offered the most robust solution. The aspect that really dialed it in for us with using Help Desk Migration was that we would be able to migrate all related attachments and there would be no extra work or effort on our part. All the other solutions that we evaluated were not able to do this as seamlessly as HDM.

The biggest win in our use of HDM was their ability to work with our team to customize aspects of our migration (for a fee that was absolutely worth every penny) that were not part of the “out of the box” solution. We had legacy data that existed in Team Support that we needed to map to specialized custom fields in Zendesk and they were helpful and accommodating in working with our team to solve these data transfer opportunities from Team Support to Zendesk.

The migration interface was reasonably straightforward and there were a couple of aspects that were confusing such as some of the mapping and association of correlating data from one platform to the other (nothing to do with HDM) as Team Support vernacular and workflows were different enough from Zendesk to lead to confusion. This was all sorted out with direct assistance from HDM and our account manager who was always available whenever we had questions or needed assistance.

What were some of the reasons your company decided to switch to another help desk?

Crunchtime was using an MS Access database to track all support requests and inquiries in 2005 when we deployed Salesforce and leveraged the built-in support tool which CrunchTime was able to use successfully for approximately 10 years.

We started to look for a different solution when we began to look at multichannel capabilities, especially around a customer portal. Salesforce required a license fee for every portal customer and when we evaluated the cost to benefit. We determined we would end up having to spend the entire organization’s net earnings on Salesforce to onboard our customer community based on our identified requirements.

We evaluated a couple of solutions and decided on TeamSupport as they were still relatively young as a company and reminded us of where CrunchTime has been just one decade before. We were very optimistic about what TeamSupport would be able to provide as a multi-channel support platform however we found that we were not able to get the capabilities and functionality that we ultimately required of our support solution.

We were partnered with TeamSupport for about 18 months when we decided to search for another solution. We evaluated 12 other support solutions as part of our RFI / RFP and did a robust analysis of all features and capabilities with weighted internal analysis/feedback and narrowed it down to Zendesk and ServiceNow ultimately choosing Zendesk.

Why did you need historical support records in the new help desk?

We had a tremendous amount of historical data which included all the historical support requirements and development requests from our previous systems. We did not want to lose any of that data much of which had either been resolved or included in our development cycle and saved for consideration later or prioritized for a future release.

Being able to easily review where you have been and what you have experienced provides organizational wisdom on lessons learned as well as conveying an experience that is data-driven and less tribal in nature.

We also had a significant amount of information that correlated to other systems in use such as JIRA that would have limited the associated information and context if that history was lost.

What are some of the tips you can share with those who are also getting ready to migrate their data to a new help desk?

Make sure that you clearly determine the output and throughput of the API calls with your existing solution as what you can load into a platform may be radically different from what you can retrieve. This aspect will be the biggest impact on getting the current active ticket history migrated as well as any historical. We determined that we had approximately half a million API calls to migrate our data and while Zendesk enabled 700 API calls per minute (42,000 API calls per hour, 1,008,000 per day) to push our data into their solution, our existing platform only allowed 5000 API calls per day initially.

We had to request an increase from 5000 calls a day (3.5 per minute) up to 10,000 per day, and then finally were granted an increase up to 20,000 a day (14 API calls per minute). The migration of our live ticket data ended up taking approximately 3 days and our historical data was approximately one month to extract from Team Support.

When setting up the HDM migration connections with the support platforms make sure to create generic administration accounts so that the create user or associated configuration user accounts are not specific to an individual.

Lessons learned specifically when migrating to Zendesk are:

1. Clean up existing ticket associations and assignments to individuals that are full agents or reassign any historical tickets to a generic admin user prior to the migration for anyone that will not be a full agent in Zendesk will cause issues during the migration.
2. Each migration effort (if separated due to the situation above) will automatically assign all agents to all groups which will have to be cleaned up manually. This is not difficult but will affect auto notifications as they have to be turned off so that all agents are not notified of all the new tickets created associated with different groups.
3. Make sure to specify the correct default group in the set up so that it will be easier to determine which agents clearly belong to which group. For agents that belong to more than one group document the exceptions to more easily manage them post-migration.