In this interview, we speak with Kevin Clough, Senior Director of Sales Operations at Moogsoft, about his career journey, the challenges faced by his team, and the automation tools they implemented to enhance their productivity. Moogsoft is the leading AI Ops observability space tool that ingests observability data from cloud-based or on-prem observability tools to provide a single pane of glass into all the data, helping speed up the resolution process during outages.
Barry Burns, Co-Founder at Savant
Hi everyone. Thanks for joining us for this next installment of “An Interview with a Savant.” Today I am joined by Kevin Clough. He is Senior Director of Sales Operations at Moogsoft. Kevin, thanks so much for joining us today.
Kevin Clough, Senior Director of Sales Operations at Moogsoft
Yeah, happy to be here.
So let's just get started, as we always do. Tell us a bit about Moogsoft.
Yeah, so Moogsoft is the inventor and the leader of the AI Ops observability space. So we're a tool that you integrate with all of your existing observability tools, whether those be cloud-based or on prem observability. And we'll ingest all of that to give you a single pane of glass into all of your observability data.
And then the AI part of AI Ops, which is where Moogsoft really shines, is as we ingest all of those events, we can use our AI to automatically correlate, deduplicate and enrich all of the alerting that's coming in from your various tools. So if a single incident is causing events to be logged from multiple monitoring tools, we'll detect that and group them together. It really helps speed things up once you get your resolution war room going to not have to do all of that initial legwork. We've already done it. Speeding up your mean time to resolution on outages.
Great. And your typical buyer at one of your customers?
Yeah, typically either the SRE team or the IT Operations team.
Okay, very cool. Tell us about you, Kevin. What steps in your career brought you to Moogsoft and what do you do at Moogsoft?
Yeah, so I joined Moogsoft at a really interesting time. Moogsoft was originally an on-prem[ises] software company because at the time Moogsoft was founded, most observability tools were on-prem tools, observing kind of on-prem server farms and things like that. I joined Moogsoft right when we launched Moogsoft Cloud, which is our true native SaaS application, designed to work with other SaaS applications as well as your on-prem tools. So I joined Moogsoft to help Pivot to a SaaS business model as well as a SaaS delivery model. I've been working in SaaS tech for 9-10 years now, so I was one of the leaders that they brought in to help transform the company.
And prior to Moogsoft, where were you at?
I was at HubSpot for a little over eight years, where I did a variety of things, including Sales Operations, obviously, but I was also the founding analyst building out the business intelligence function at HubSpot. I worked on product strategy when we launched HubSpot CRM, and at one point I was our head of pricing as well.
Okay. And for those not super familiar with the responsibilities of a Sales Ops team, can you give me some of the key objectives of your group?
Yes. So we work with sales leadership as well as with the frontline reps just to improve the productivity of the team. So that can mean anything from working with our CRO on our go-to-market strategy as a whole. That can be team structure design and then that can be things as far down the funnel as I do the territories, I design our sales compensation incentive plan, as well as everything from coaching reps through individual deals. So just kind of end-to-end making sure our sales are as efficient and effective as they can be.
Okay, makes sense. So tell me about the business challenges that you faced or that your team faced that made you start looking for some type of automation tool to do your work.
Yeah, I think as a company scales automation, especially automation around your CRM becomes really important. Doing everything as a manual process just doesn't scale past a certain point. So when I joined we had already built quite a bit of automation just natively in Salesforce using the Salesforce native automation tools around tracking data about our new cloud product.
So every time somebody signs up for the cloud product, a custom object is made in Salesforce called an instance and a bunch of automation occurs in Salesforce. But the problem was we weren't including any data that wasn't originally in Salesforce. So any data that we wanted to sync and make available to the end teams from, let's say, our product databases, wasn't in Salesforce and if it's not in Salesforce, you can't touch it with the Salesforce automation. So that was really the first use case when we went out and we were looking for automation tools. A good example of the sort of information we weren't capturing before was who are the actual users of our tools and are those users in our CRM? Or even things as simple as how many people have logged in to this instance or how many people have been invited to log into this instance.
So we adopted a data automation tool, Savant, and our very first use case was going to our product database and syncing that sort of information back into Salesforce to make it available for our front line employees.
That makes sense. And I have to say, personally, having worked with a bunch of SaaS businesses I've seen similar challenges across all of them, being able to take internal product data and make it available to the sales team.
Yeah. And in any modern SaaS go-to-market like the usage data of how prospects and customers are using your product is critically important. But that never is natively living in the CRM. So you always need some sort of automation platform to go get that data and bring it into the CRM on a timely basis.
Completely agree. It's interesting, the modern buzzword for go-to-market strategy is product-led growth, right where some of your sales strategy shifts actually in product. I feel like Salesforce in some cases hasn't kept up with the transformation there because they aren't easily able to capture the sort of sales steps that a customer might be taking within the product itself.
Yeah, I think Salesforce's automation has really fallen behind for product-led growth, but it's also just Salesforce has been around for a while. There's a lot of different data models that underpin that CRM. So we find value in having a powerful third party automation tool, even to just run things that you would expect to be a native Salesforce workflow. It's much more flexible doing cross-object reporting, cross-object workflows using a third-party tool than it is using Salesforce itself.
Got it. So give us an example, Kevin, of an end-to-end workflow where automation has really helped you.
Yeah, so a recent project we just completed was trying to kind of build a forecasting tool without actually buying a forecasting tool. So originally when I joined, we were like every other small sales team: our forecast was driven entirely out of a spreadsheet. The spreadsheet was manually created by our head of sales. He would manually add deals to it, he would manually remove deals from it, he would adjust the amounts. What that inevitably leads to is your forecast is always out of date. It is never based on the most recent data that's available in your CRM. And it just creates this inherent messiness in both the forecasting doc and your CRM. Because if our CRO is updating information only in the forecast spreadsheet, how do we make sure all of those edits also happen back in Salesforce? The answer is your Sales Ops team does it one click at a time. So what we had graduated to is kind of an intermediate step in between. We had set up a spreadsheet where at least there was one tab that synced all of the deals from Salesforce on a consistent, regular basis. And then we could at least reference the most recent data, even if the version in the other tab where the forecast was actually happening wasn't always in sync.
At least you had those two side-by-side to compare and try and keep up. Where we've really leaned in with data automation now is to create a true BI directional forecasting spreadsheet. So it is constantly updating with live data from our CRM and on a schedule it's writing back to our CRM as well. So we have a true read-write forecasting spreadsheet now, and I think the way we go about that is very interesting. So we have our spreadsheet which syncs from our Salesforce and creates the nicely-formatted tables. So each rep has his own nicely-formatted table. We have the team summary table, and then our head of sales can just edit directly in the table. He can edit any of the editable fields in Salesforce in the table. And then every night once everybody's gone to bed, it'll read that table, it'll read a fresh copy of what's in the CRM. It'll read what it was last time it synced, and it will handle the merge conflicts as you're trying to write those changes back. So if our CRO made an edit, that one goes into the CRM. If a rep has edited the same field in that time, you can automatically decide, “Oh, we're going to have our VP of Sales edit rule,” or “We're going to have the reps edit rule,” and you never have to worry about the spreadsheet going back and overriding with old information. It always defaults to keeping the newest information.
That is an absolutely fantastic use case, Kevin. I can't tell you how many times I've sat in on sales forecasting meetings and there were just arguments over what the opportunity amount was of a certain deal and changing it live on a personal level.
I'm so glad now that we have this. I'm so glad that I don't have to listen to the inevitable conversation between the head of sales and the sales rep over close dates and which one of us is going to go move this from being a March deal to an April deal. As always, 20 seconds of back and forth as everybody tries to raise their hands. It's like pulling out your wallet at dinner. There's the inevitable conflict over it now. It's a very easy answer. Our head of sales just edits the close date in the spreadsheet and we know that's going to be synced back in a timely manner.
It's a really innovative use case for a pattern that we see a bunch of our customers using in Savant, which is there are business apps that can be updated directly within the application but what we find is a number of teams are keeping data offline in spreadsheets either Excel or Google Sheets, et cetera, and just creating a human in the loop automation where data and spreadsheets can make it back into a database or a business app with all of those rules about overriding certain fields from the spreadsheet to the business app governed by a central entity. There's so many flavors of that use case, but it's something that we see a lot of our users doing. So I'm glad you found probably what I feel to be one of the most innovative and most useful forms of that yet.
Yeah, it was a key initiative for us, to continue to improve our forecast accuracy, and one of the lowest hanging fruits there is is improving the quality of the data that's going into your forecast. So we were at a point where we were going to have to invest in a forecasting tool of some sort, but budgets are tight all across all of the tech industry right now. So I was really glad we were able to put something together that preserves all of the ease of use of a spreadsheet, because it's still just a spreadsheet with that sort of merge, with that ability to handle version control and all the sorts of modern requirements to actually keep that spreadsheet and our CRM in sync.
When you think about making investments in these types of automation tools and comparing that to the ROI you get from them, how do you start to think about the value that this type of automation brings to your team and the business as a whole?
Yeah, and I think it's always interesting in data automation tools, there's kind of two ways that you can think about the value. One of them is just the hard value. Like what are the tools that this tool is replacing? So in that example we just gave, because we have this data automation tool and we were going to need the data automation tool regardless to power our product-led growth initiatives, now we didn't have to buy a forecasting tool. So like, right off the bat, there's tens of thousands of dollars in hard value. Other use cases that we use stuff like that for is syncing information from our CRM over to our support tools. So we don't have to pay for an entire support team having seats in our CRM. They can live in the support tool and the data automation platform can handle moving the data where it needs to be. So that's always the version that finance wants to talk about when we're talking about making these investments: “Can you offset more than a one for one tool spend?”–which we've easily been able to do. But then I think the value that you see from your team is many multiples of that.
It's just harder to quantify what is the value of an account manager knowing that one of their customers just invited five new team members to the product, like very high, and that is happening at scale many times every day. And that's just one automation flow.
All right, it makes perfect sense. Last question, Kevin, then I'll let you go. And again, thank you so much for talking to us about your past and your current role at Moogsoft and some of the ways that you've been implementing automation so far. Now that you've gotten to this point already, what advice would you give to someone in a similar role that was looking to get started with automation and their team?
I would say a really important and often overlooked thing when you're selecting an automation tool is really understanding what the full breadth and capabilities of that tool are. In the case of Savant, which is the tool we ended up using, it's all built on top of SQL. SQL is an incredibly robust language to handle data. So if you're looking for something that is robust and flexible handling data, and it's built on top of SQL, you're off to a really good start. As opposed to some of the other automation platforms I've looked at in the past, where it's older school, it's really optimized around “If this, then that” style flows. I think it's really important to make sure you understand the power and the flexibility of the tool that you get, because you're always going to be craving more and more flexibility as your flows get more and more complex.
I do appreciate that, and it was one of the things that we tried early on, is to create a tool that could be accessible and flexible for folks that love Excel, for folks that love SQL, for folks that love workflow automation. It's a challenge that we constantly strive for: to bring everyone under the tent regardless of the way that they do analytics. So, yeah, that's very good feedback. Kevin, again, I have to thank you for spending time, it was incredibly insightful to hear about your forecasting use case, and thank you for your continued partnership. Excited to see what you're going to build in the future.
Yeah, I'll let you know what's next.