About Clay‍

Clay is about 50 people now. We just recently raised our series B funding about a month ago, and we’re mostly in person in New York City. We have a relatively relaxed policy, but everyone really likes being in the office.

Why did Clay need an incident management tool?

‍

The pathway to adopting Rootly was actually kind of a funny one. I had used Rootly at a previous company, though I wasn't directly in charge of it.

‍

When I joined Clay, Rootly reached out to see if we were interested in using the tool. Initially, our engineering team and I thought we were fine with just our Slack thread system. This worked until we experienced a few incidents, including one where our app went down, leading to four different Slack threads in separate channels. Information was getting lost, people's time was wasted jumping between threads, and updates were being missed.

‍

It became clear we needed a more organized approach. From my past experience, I knew Rootly could solve these problems. That was when I decided it was time to implement Rootly, and within a few weeks, we started rolling it out.

‍

What were you looking for in the incident management tool?

‍

The biggest thing we needed was centralized communication, which is the core of what Rootly offers. Another major issue was our status page updates. It was unclear who was responsible for updating it, and it often fell through the cracks.

‍

We also faced an influx of customer tickets during incidents. My team had to copy and paste the same messages to every conversation, which was inefficient. With Rootly, we built a custom integration with Intercom that triggers a ticket whenever an incident is kicked off, allowing us to communicate with multiple customers at once.

‍

Now, all updates are cohesive and streamlined, saving us significant time and effort. It's been a big win for us.

‍

Ultimately, Rootly pushed us to redefine what we consider an incident. Historically, an incident was clearly defined as the app being down or a major part of the app being affected. However, with Rootly's capabilities, we've expanded that definition. Now, anytime we need one-to-many customer communication, we kick off an incident, as it's a more efficient way to manage these situations.

‍

A good example for Clay is that we integrate with over 75 different providers. Previously, if one of those providers went down, we would simply notify the engineers, but there wasn't much they could do except wait for the provider to recover. Now, since we get many customers reaching out saying they can't use certain features, we use Rootly to handle one-to-many communication even if it's not a traditional incident.

Why Rootly?

‍

It was a no-brainer. There were several pieces that surprised me in terms of how easily we could integrate them. At my previous company, we used PagerDuty alongside Rootly, but here we were able to consolidate with Rootly's on-call system.

‍

The same went for the status page. We had looked at several options, but consolidating everything into one system with Rootly was incredibly helpful.

‍

We also considered building our own solution, as we often do. We thought we could create a basic version that was good enough, but after playing around with Zapier for 20 minutes, it was clear it wasn't worth the effort. We needed a proper system, and Rootly fit the bill perfectly.

‍

How long did it take to implement Rootly?

‍

The implementation was relatively quick. One of the most surprising things was the level of support we received from the Rootly team, even before we signed. They helped us build the case for why we needed Rootly, which was easy given the incidents we were experiencing.

‍

There was a lot of hunger, especially from the engineering side, to organize our process. From the initial discussions to signing and building everything out, your team reviewed the incident response documentation I had put together and provided feedback. There were regular calls to ensure everything was on track.

‍

You even offered to do a full team training and demo, which we didn't take advantage of but probably should have. Small touches, like your CEO and co-founder joining our Slack channel to check in, made us feel fully supported throughout the entire process. It was great to know we had the entire Rootly team behind us.

‍

How has Rootly improved your incident response process?

‍

Since rolling out Rootly, we've already had a couple of incidents, thankfully nothing major. It was almost funny—we were ready to roll it out and were kind of hoping for an incident to see if it worked, but not really. The incidents we've experienced have mostly been lower severity, like when an integration goes out, and it's been hugely beneficial to use Rootly.

‍

The engineering side, in particular, feels much better prepared. Before, it was chaotic—people throwing questions into Slack and hoping someone would answer. Now, we have a clean and structured process. When there's an incident, everyone knows how they'll be notified, who's involved, the severity, and what's happening—all in one place. We know when to update the status pages and the exact language to use.

‍

It's been a huge improvement from where we were just a month ago. We're thrilled with the progress, and while we're still waiting to see how it handles a bigger incident, we're confident that we're far better prepared now.