In 2018, I started my career at Kinsta as a Support Engineer. We were a small company of only about fifty back then. When I first joined the team and began helping customers, I recall being very impressed with the detailed level of internal documentation that we had at Kinsta. To this day, we maintain the same level of documentation to help our customers.
Internal Documentation
While internal documentation was great, there weren’t a lot of tools or automations in place. It wasn’t until after about the tenth time of installing Redis or perhaps setting up Ioncube that I decided to take matters into my own hands.
You see, prior to this, everything was done manually. We would go to Confluence and look up the specific steps and configuration options that needed to be added/modified, and there was a lot of copy/pasting of code blocks, checking data in specific locations, and updating things in other places. This led to updates taking longer and created more opportunities for mistakes, as missing a step in the process could cause problems.
I began writing Bash scripts for each task as part of a project to help me improve my own work and to allow me to perform these methodical tasks repeatedly without mistakes. Over time, other team members saw what I was doing and began to use the scripts. What used to take 20 minutes now took mere seconds, all while reducing the possibility of human error.
It wasn’t until I approached Tom Sepper, our Chief Customer Officer and Director of Support at the time, with my idea to turn these scripts into a larger tool that would be available to everyone that things began to take shape.
The Kinsta Tool
I undertook the process of rewriting the scripts I had written in Bash, converting them to PHP to be more versatile, and thus, the Kinsta Tool was created. Kinsta Tool is still in use today by our support team and has a vast multitude of automations for tasks such as malware scanning, installing PHP extensions, or setting up Redis.
The Kinsta Tool remains a valuable tool for our team as it fills in the gaps where features may not exist in the MyKinsta dashboard. For example, a request that we often receive from customers is to reset a site back to the default WordPress state. While you can do this in MyKinsta, it requires deleting the site and recreating it.
In order to make this process easier for customers who sought assistance, I added a function to the Kinsta Tool that utilizes both WP-CLI and MySQL commands to purge the database, remove files, and re-install the latest version of WordPress with a single press of a button. The action, in total, takes less than 5 seconds. If we were to repeat the steps manually, it could take anywhere from five to ten minutes, depending on the circumstances.
The Chrome Extension
Others have undertaken similar implementations. Before me, Thoriq Firdaus, now a member of our marketing technology team but previously a support engineer, developed a Chrome extension. The extension was internally used to show a website’s headers and detect whether or not it was hosted at Kinsta.
Up until recently, Thoriq’s extension remained in use but was not being maintained. We recently undertook the process of writing a new extension to ensure that we were using the latest version of the Chrome manifest, including the original concept but adding our own additional tools and features that made sense to help our customer-facing teams do their jobs more efficiently and effectively.
A great example of this is how the extension will automatically obfuscate untrusted URLs when our team is typing responses in Intercom. This adds an additional layer of security by ensuring that we don’t send someone a malicious clickable link.
The Chrome extension also gives an at-a-glance indication of whether or not the site is hosted at Kinsta. Our support engineers can click on the extension and quickly see all of the relevant headers the site is sending, which can help track down issues with a website.
Additionally, the extension provides a temporary notepad so that support engineers can copy/paste notes or code, which will persist as long as the tab remains open. This makes switching tabs from Intercom to MyKinsta much easier and more productive.
Chat Routing System
Another internal tool that I worked on was utilizing Intercom’s API in order to create our own chat routing system. Intercom offers a “round-robin” approach, and while we found it to be effective, it often caused some support engineers to have many more conversations than others, and the queue quickly became imbalanced.
In response to this, I wrote custom routing code in PHP that interfaces directly with Intercom’s API and webhooks to receive and respond to actions performed directly from within Intercom. As a result, we have been able to stabilize how conversations are assigned to support engineers.
To maintain the timeliness and informativeness of our support responses, we implemented our own routing logic, which plays a crucial role in assessing the complexity or ‘weight’ of each conversation.
For instance, a discussion about DNS is generally considered less challenging than one concerning a reverse proxy. Consequently, the DNS conversation is assigned a lower weight compared to the reverse proxy discussion.
Our routing logic evaluates the availability of support engineers, calculates the cumulative weight of ongoing conversations for each engineer, and allocates new incoming conversations to the engineer with the lowest weight.
Moving Forward
Leading up to July 2022, we began to realize just how important these types of tools and systems are and will remain important for the overall success of our customer-facing teams. As the primary person working on these tools, in addition to my other responsibilities, with each project that I worked on, I acquired technical debt.
Each system would need updates and need to be maintained. This continued to eat up more time than we had allotted for. All the while, I was serving as Head of Support and eventually as Director of Technical Support, which is my current role.
In response to the ever-growing workload and the realization that we would continue to have a need for customer support-based tooling, we decided it was time to hire someone for that role permanently. We were able to promote internally and found someone with the knowledge and experience to step in and not only fill my shoes, so to speak, but would have the time that they needed to produce quality tools.
Since bringing our Internal Tools Developer on, we’ve worked together on projects that have enabled us to track statistics better. We rebuilt the Chrome extension, and we continue to work on improvements for existing tools.
Summary
Back in 2018, we were still a young company, and something as small as an idea for what became Kinsta Tool can often lead to bigger and better things. I believe that this type of ‘startup mentality’ can be overlooked as a way for people outside of the traditional development cycle to contribute their own ideas for efficiency gains and tooling.
Efficiency and making the job easier have been a priority of mine in my tenure at Kinsta, and I strongly believe that a lot of teams can benefit from their own forms of tooling and automation.
By sharing my experience of how we capitalized on this for our customer-facing teams, I hope that you, too, can find ways to improve efficiency, lessen the possibility of mistakes, and improve your team’s job performance.
Jeff Paul joined Kinsta in October of 2018. He's worked as a Support Engineer, Support Lead, Head of Support, and Director of Technical Support. Jeff is responsible for the overall direction of four customer-facing teams: Support, Migrations, Malware & Abuse, and Internal Support.
Leave a Reply