Enhancing the Robustness of a Beloved Customer Offering

Photo by Parker Byrd on Unsplash

One of the best offerings a SaaS company can have is seamless integrations with tools that customers and clients work with already. It enables you to sell your product without your new clients worrying about the effort involved with overhauling their many workflows and the learning curve involved with onboarding a new tool. When I joined a former company, the integrations department was growing and already loved by the customers that took advantage of these offerings.

My teammate had done an awesome job building out the most asked for integrations and working with customers to get them set up. By the time I joined the organization there was a pretty hefty backlog of integration requests, as well as a myriad of products and tools we also needed to build. As our integrations began to scale, a few of things became apparent:

1. We often did not have any insight into how individual integrations were behaving, especially when they did not have wide adoption among our customers.
2. Most of the integration applications were pretty much the same. This was great for maintaining patterns across many repositories, but also provided a great opportunity to simplify.
3. It was a bit monotonous and error prone to research and stamp out a new integration.

With the launch of our webhooks platform (more details here) an opportunity presented itself to overhaul the way we built integrations and ultimately develop an integrations platform. Once launched, we obtained telemetry data that allowed us to get ahead of problems well before they were ever seen by customers and the time to develop a net new integration was reduced from roughly six weeks to under two weeks

Planning for a Major Change

To begin planning for this shift, we needed to first take a good, hard look at what our existing tools actually did in the most simple of terms. At the end of the day, our integrations either took asset data from our API and put it in another system or the other way around. As we thought about it, the concept of a “workflow” began to emerge and I began to design around that.

The resulting design sequence was as follows:

1. our application would receive an event that was tied to a user defined workflow.
2. We would look up the origin and destination services in that workflow.
3. The “job” was enqueued to execute as a worker became available.
4. Any additional data was gathered from relevant APIs.
5. The job was executed.

Beyond the flow of the system, it was also important to consider how to design the code such that we could easily add new integrations. Ultimately, a pretty elegant and simple solution was decided on. Each new integration would have two components — a Python class with a consistent interface and a database table that included data required to interact with the third party service. These components were called dynamically on an as needed basis through the business logic implemented in the core service.

With the design in place, the new challenge became how can we launch this without impacting any of our customers? At this stage, a proof of concept product didn’t really exist, so we decided to spend a bit of extra time building out one of the new integrations in our backlog. Instead of building it based on existing patterns, it was built using the design that had been outlined in planning meetings.

Once proven, my teammate and I began to add existing integrations into the new platform and launched new customers on this new tool. After we gained a lot of confidence in the new tool, we slowly began to transition existing customers to the new product.

Long Lasting Impacts

Despite a few hiccups along the way, building out this produc was a resounding success. As mentioned previously, our team suddenly had access to telemetry data that allowed us to get ahead of any potential problems. This was a major work-life enhancement that reduced stress and helped minimize costly context switching. Additionally, we started saving thousands of dollars on each new integration being built, given that each new service took almost a month less to actually build. Proof of concept integrations also became easier to build out, which was a huge benefit to our sales and presales teams as they were demoing to potential customers.

The coolest part of this project is actually where it is today. A while back I was catching up with my former manager and he told me that the entire tool had actually been rewritten. Initially I was a bit taken aback by this, thinking that they may have gotten rid of a tool I spent so much time designing and shepherding to completion, but when he explained I couldn’t help but smile.

It turns out they took the concept of content-sync and enhanced it to a point that the customer experience team could build out integrations on demand for customers — without engineering being involved at all. It was amazing to see that my concept had grown to a point that it positively impacted an entire organization beyond just our local team.