Deepgram’s Slack Bot: An Unexpected Automation

One of the most important parts of providing best-in-class support at Deepgram is a tool we lovingly refer to as our “Support bot”. As the team lead for Support Engineering here, I learned that operating a small but highly efficient support team at a stage of rapid customer growth can be challenging on its own, but the journey to developing this innovation to connect with our customers was worth every step!

In this blog post, I’ll explain our process for evaluating our current interactions with customers, conceptualizing and building the support bot integration, deploying the integration, and the immense impact it has had for our team’s productivity and cross-functional awareness.

How We Built Deepgram's Slack Bot

Inspiration and Motivation

When I started at Deepgram a little over a year ago, we hadn’t yet launched Zendesk as a support platform and were supporting our 100+ customers purely through Slack; if you’re thinking, “Wow, that must have been intense!”—it was, very much so!

To address the overwhelming nature of monitoring these Slack channels for reported issues and following up, we had a few options before us:

• Focus on Slack as a main support channel. However, this would have been impossible to scale, and would have prevented us from deriving metrics to surface to other parts of the organization.

• Completely get rid of Slack support. This was viable, but how would that affect the level of personal engagement that we have with each issue?

• Build something new…

Reading the last item, you might assume that such an integration already exists—and you would be (partially) correct! An official Zendesk integration for Slack does exist, but it is limited in that it requires manual intervention to create tickets. Our customers were used to directly tagging people on our team directly for attention to issues, so we wanted to keep that workflow intact.

Homing in on the main goal here, our desire was to deliver best-in-class, personalized support, at scale. Given this goal, we needed a tool that was easy for customers and Support Engineers to use, reliable when troubleshooting high-impact issues, and easy to extract product feedback and insights from, which required the construction of a custom tool.

Through developing an understanding of the problem and our goal, the next logical step was to gain validation of my understanding from the wider team to expand context beyond my own perspective.

When these details were compiled, I met with our CEO (Scott Stephenson), CTO (Adam Sypniewski), and VP of Product-Led Growth (Natalie Rutgers) to get feedback on my proposed solutions.

After processing and integrating their feedback, I partnered with our Head of Customer Success to receive more context in understanding how our customers are used to being supported and verifying which bot features would be the highest priority in supporting them. This sort of engagement from director-level and executive stakeholders is the norm at Deepgram, as we are all builders at heart!

Ultimately, we decided that we should build a tool that: 

• Customers can @mention a bot with their message to our team.

• The bot sends an acknowledgement letting the customer know we received their ticket.

• Allows for threaded replies from our Support team into the Slack conversation.

• Connects customer replies back to the ticket thread in Zendesk.

• Tracks the creation of customer support channels in Slack.

Reviewing and Developing the Solution

When it came time to build, I started by building the webhook handler that we’d be using for the Slack Events API and hosting it locally to clear Slack’s app verification process (forked from the legacy repository, here).

From there, I added events to reformat event data to fit Zapier’s JSON formatting standard, and then post the data to the applicable “Webhook” trigger events for each of the major features that comprise the bot:

• Creating Tickets from app_mention Events

• Creating Tickets without mentions from :link: reaction_added Events

• Bidirectional Reply Connection and Closed Ticket Notifications

• Tracking for new support channels that are created

• Delivery of Mass Updates (broadcasts across multiple channels)

• Event Logging for troubleshooting and general visibility

After the handler was created and hosted via ngrok to simulate a web proxy, the Zapier workflows were built out to suit our custom business logic. I created a docker image to enable reproduction of the hosting environment and pushed it to our internal repository to prepare it for deployment.

During this process, the importance of reviewing the Slack Event API and Zendesk documentation, remaining flexible with the data used in workflows, and conceptualizing and testing edge cases in a staging Slack environment cannot be understated!

Preparation for Deployment

Preparing the event handler component of the bot deployment ended up simple and fuss-free by creating the Docker image and docker-compose orchestration files in the execution step.

From there, I scheduled live meetings to set up a code review and release process with our Product, Security, and Site Reliability teams to host the code in our GitHub repository and enable continuous deployment of the application when new features are added.

Once the bot application was deployed to our production environment, I did some additional verification testing to ensure no difference in the behavior of the bot within our Slack staging environment, and then migrated the app configurations in the Slack administration panel to the official Deepgram space.

As a last step, I got my team members to engage with the bot in a private slack channel I’d added it to, to ensure it worked in a way that was intuitive, and any edge cases were patched up prior to the internal demo and eventual release.

Initial Release and Updates

After all solutions verification and deployment steps were completed, I received approval to share the integration with our internal team via a pre-release event where I explained features and usage, customer communications for release, and received feedback from internal stakeholders.

Once the feedback was compiled and incorporated accordingly, I began adding the bot to customer channels and shared communications on how to use the bot with Scribe, an app that turns screen recordings into step-by-step instructions.

Conclusion

In conclusion, building the tools necessary to enable customer success and support is no accident! It requires an intentional, concerted effort to understand what your customers need, why they need it, and with special attention to their use cases and your business context.

With that being said, Deepgram is an organization of builders from top to bottom! Ingenuity and curiosity drives our teamwork and great teams make great products, and provide great support.

While it took approximately three months of work to complete—between actual planning, development, approval, and release of the app—the payoff has been clearly received on a daily basis; we have almost doubled the number of customers supported via Slack (now at over 200) without needing to drastically expand headcount, and our response times dropped to less than half of what they were 2 months before the bot was launched!

This enabled us to operationalize within 6 months of the inception of the Support team and cultivate internal and external value-added components, like:

• Tier-based support plans

• Response time SLAs (Service Level Agreements)

• Support performance targets and Support Engineer feedback loops

• The introduction of self-serve resources like the Deepgram Help Center, Status page, and Product feedback loops

Ultimately, this process will look different for every support team, but I hope sharing my example in detail will encourage you to stay flexible and creative when enabling your customers, Support Engineers, and Customer Success Managers!

If you’re interested in learning more about the technical details for this bot, feel free to review the bot repository here, which includes code for the event handler, data specs, public links to the Zapier workflows, and steps for listener container deployment.