What We Learned From Building Our Own Ticketing Platform

What We Learned From Building Our Own Ticketing Platform
Updated Jan. 12, 2022 Published Oct. 10, 2019 6 Min. Read

Since Design Pickle’s founding, we’ve managed all of our 250,000+ design requests using a ticketing platform designed for customer support requests.

 

And for four years, it worked really well for us.

 

Until it didn’t.

 

You see, customer support requests just aren’t the same as design requests. Design requests aren’t simple questions that can usually be answered in a few back and forth messages. Fulfilling design requests involves a whole team that needs to be aware of client preferences, brands, document delivery, reporting, the order in a client’s queue, and skills required to fulfill the request.

 

More and more, we began to compromise our workflows based on what our ticketing platform was and wasn’t capable of. Instead of innovating processes, we found ourselves coming up with workarounds that would fit in with the software.

 

When improvements were suggested, we’d respond with “Unfortunately, we can’t do that because the ticketing software won’t let us,” or “That’s not possible because the API doesn’t support that.”

 

It was frustrating as a product team to keep saying no over and over again to things that if we were able to build them, would have improved the business.

 

Oh, and the 200+ users on a per-seat pricing model was adding up quickly.

 

For a couple of years, we kept throwing around the idea of replacing our ticketing software with our own solution. But the task always seemed daunting and was typically pushed back on the roadmap to “some other time.”

 

But soon enough, we realized that there was no way that the ticketing platform could scale to accommodate the company’s vision. It was simply bursting at the seams as we grew. It was time to tackle the project — time to create our own ticketing platform.

 

So we charged onwards to replace our off-the-shelf ticketing software with something we could finally fully access and customize.

 

And guess what? We did it!

 

For the past two months, we’ve successfully been running on our own platform.

 

Looking back, we learned a few lessons that we’d like to pass on to anyone who’s considering tackling a project of similar scope.

 


Related Articles

4 Print Design Mistakes (and How to Avoid Them)

8 Graphic Design Essentials for Every Business

I Survived Another Website Relaunch: 6 Lessons I Learned

 


 

Buy, Then Build

 

 

If we’d built this entire solution from the very beginning, it wouldn’t have worked out as well as it did today. I’m really happy the founding team made the decision to purchase the initial ticketing software.

 

When you’re first starting up, it can be tempting to build custom everything to get it just the way you want it. But apart from it being expensive and time-consuming, as a startup, your workflow is definitely subject to change.

 

You can take a bit of the risk off of your plate by buying an existing system that meets 80% of your needs, and then use custom integrations and automation software (like Zapier) to take care of the remaining 20% of your workflow.

 

Even once you’ve survived the first contact with your customers and have careful processes in place, it may still be worth it to keep buying the software. If it ain’t broke, right? You’ll know it’s time for an upgrade when your purchased software starts pigeonholing you into decisions you know aren’t best for the company.

 

Have a Transition Period if Possible

We were lucky that we could continuously roll out features so our design team could test them as we went along.

 

However, that didn’t always work since the old software was still fully accessible during the transition period. No one was using the new software.

 

We needed to get people on board to test the new platform so we opted for a transition period where both systems could be used in parallel for a few weeks.

 

During this period, we were able to unearth some issues, requirements, and use cases we weren’t aware of upon roll-out.

 

We then had the choice to either keep using the two systems in parallel at a degraded experience to the customer or do the proverbial “ripping off the band-aid.”

 

We opted for the latter. When the band-aid did come off, we were busy with support and feature requests for a few days there, but everyone on the team handled it like champs. Plus, many of the issues had already been solved during the transition.

 

You’ll Overlook Small Things Here or There. That’s OK.

Sure, we missed a couple of details here and there that were quickly caught and passed on to us by our excellent customer success team. Everything was quickly remedied in less than a day.

 

The most important thing was that we got all the big stuff… the stuff that if that didn’t work, chaos would ensue. And that’s the stuff that really, really mattered.

 

There’s Always More To Do

Even after the initial roll-out, there will always be more improvements to make. The work won’t stop as soon as you push to production.

 

There will be bug fixes. There will be feature requests. There will be people still used to the old way of doing things. You just gotta roll with it and come up with a plan to get a little better every day.

 

Have a Single Place to Gather Feedback

We created a single place where all change requests, bug reports, and other concerns could be directed. It made the transitional and initial roll-out processes much more manageable.

 

Let Customers Know

If you’re making a huge change to something in your system, it can be wise to alert customers of the upcoming change and possible downtime. That way, if something were to happen, they’d know why.

 

Asking them to report any issues can also be helpful.

 

…But Try Not to Affect Their Experience

Ideally, your customers shouldn’t even know something changed on the backend.

 

If you can, plan your rollout so that downtime and possible issues for customers are minimized.

 

There Will Always Be Things You Don’t Know

If we were to have gathered 100% of everything that all 280+ employees of Design Pickle do in our system, we would have never completed this project.

 

Even with weeks of requirements gathering, things can always change before roll out or lack the context needed to clearly execute the feature.

 

Stay flexible and roll with the punches. And oh yeah, do a little happy dance once it’s all over!

 

This was one of the largest software projects Design Pickle has taken on to date. We’re very proud of how it turned out and grateful to the engineers who helped make this a reality.

 

We’re excited about the future possibilities that are enabled by this change. Get ready for a lot of new and exciting features to come out in the next few months.

 

Stay up to date with product changes

 

Stay tuned to the blog for announcements of major feature releases. You can also keep an eye on our changelog or even submit your own feature request.

 

What We Learned From Building Our Own Ticketing Platform

Related Posts

Simplify the way your design work gets done.

We’re an all-in-one platform with a built-in global design workforce, trailblazing the path to easier, faster, and more efficient creative.