One of the most critical challenges for someone running a Deal Desk is ensuring that the data from a deal is captured correctly.
For Jonathan Krangel, Head of Revenue Operations at Retool, the issue of data integrity became clear almost immediately after starting his new role.
In this Deal Desk Interview, Jonathan goes through his process of identifying the issue, how he went about looking for a solution, and the results he saw after implementing it.
{% video_player "embed_player" overrideable=False, type='scriptV4', hide_playlist=True, viral_sharing=False, embed_button=False, autoplay=False, hidden_controls=False, loop=False, muted=False, full_width=False, width='700', height='430', player_id='65606185835', style='' %}
Jonathan Krangel had recently joined Retool, a software company that provides businesses the tools to build internal applications with low-code and no-code, as the Head of Revenue Operations.
Jonathan comes from a career beginning in sales and success and transitioning towards the world of Operations at companies such as LinkedIn, Mode, and Brex, before joining Retool a little over a year ago.
It became clear to Jonathan early on that the company had challenges around data integrity when getting the correct data from deals into their CRM and reporting on it.
According to Jonathan, "our sales reps were given a Word template to write up their contracts and their MSAs. And they literally had the ability to put whatever, wherever they wanted to put it. This was not good."
While the sales organization was still small, with two reps doing about five or six deals a month, it was clear that the current process was not scalable.
While it may have felt easy for reps, Jonathan knew the company would quickly grow and add a Heads of Finance and Accounting, and he would eventually need to start building reports for the board.
When he was tasked with building reports, Jonathan found that how deal data was being put into the CRM did not match up with the data model in Salesforce.
Jonathan took a unique approach to understand the problem - he wanted to feel its pain for himself.
He wanted to "own the pain."
Jonathan established a manual review process of all deals, building out the architecture in Salesforce that would be required, such as line items and contract details.
According to Jonathan,
"it is impossible to adequately build strong solutions if you yourself have not experienced the deep pain of the problem."
So he had to make sure that he would be able to build an infrastructure to support the company's needs with whatever solution he went with.
Jonathan spent two months doing this hands-on work to fully understand the contours of the issue and what was needed for a solution.
He looked at details such as the aspects of a deal typically negotiated on and the terms used in agreements. He identified that things such as pricing caps, pricing guarantees, and autorenewals were common as well.
Jonathan knew early on that he needed to implement a CPQ-like solution to overcome the data integrity problem he was facing.
When he tried to work without this kind of solution, he found that the built-in quoting functionality of Salesforce was too limited. However, having experienced the arduous implementation of Salesforce CPQ previously and knowing that some of the reps on his team had negative experiences with that platform, Jonathan felt he needed to find something more modern, flexible, and friendly for reps.
In his research phase, Jonathan looked at solutions like Pandadoc but found that it didn't support the complexity of what he needed.
Tapping into the Ops community, Jonathan was introduced to the RevOps Deal Desk Platform through Modern Sales Pros.
Close deals faster, with fewer errors, and have complete visibility throughout the process.
{{cta('0c0339e1-0774-4e79-8bd4-32d6f446af8c')}}
With his approach of first feeling the pain of not having a solution, Jonathan understood how his data should be structured and what the ideal MVP would be for his team.
A big challenge going into this project was making sure his reps were on board and that they would actually use the solution he was pitching.
"It had to feel 10x better to a sales rep than the next best alternative."
And the alternative, according to Jonathan, was going back to Word docs and Google Sheets.
Jonathan used his experience of reviewing deals manually to map out how the data needed to be structured in order to build a scalable process.
After understanding the pain and knowing where the weaknesses in the current process were, Jonathan dove into the actual data.
There was a lot of sitting down and actually reading both historical agreements, as well as the ones that were coming across his desk. Jonathan was able to notice the patterns in the way deals were structured that helped him better model what his ideal world would look like.
Going a bit deeper, Jonathan worked with Klarity, a tool that takes historical agreements and generates structured data. After using this solution to analyze 350 historical agreements, he was able to generate the structured data he needed to map out the model he would need.
Given that there were already deals in the pipeline, the implementation of RevOps was going to be more of a transition.
Jonathan's goal was to have the rollout be as smooth as possible.
Jonathan was able to onboard his entire SMB sales team, the highest volume segment for the company, onto RevOps.
According to Jonathan, "I can't remember the last time we had a deal that that was done outside of RevOps."
Jonathan feels considerably more confident about deals being sent by his SMB team than he did before.
Along with confidence, Jonathan is dealing with considerably less manual data entry by his reps. Previously, his reps would have to spend 10-15 minutes gathering data from PDFs and other documents and manually entering them into various Salesforce fields. The new process saves them both time and significantly lessens the likelihood of errors in the data.
Recently, a new rep in the company landed a relatively large deal. Jonathan was able to do a quick training on RevOps and the agreement was out to the customer and signed within an hour.
As a result of the solution Jonathan put together to fix the company's data integrity issues, the rate of deals with incorrect information going out went from 50% prior to implementation down to less than 1% afterward.
This transcription has been lightly edited for clarity.
Our sales reps were given a Word template to write up their contracts and their MSAs. And they literally had the ability to put whatever, wherever they wanted to put it. This was not good.
I'm the Head of Revenue Operations at Retool, and I joined the company about a year ago. When I joined, I was tasked with building the full infrastructure with a fairly untouched Salesforce instance from scratch.
We had about two sales reps, and we were doing maybe five or six deals a month. I quickly recognized that some of the stuff we had been doing was not going to scale. Our sales reps were given a Word template to write up their contracts and their MSAs, and they literally had the ability to put whatever, wherever they wanted to put it.
This was not good.
It felt easy and simple, but I knew at some point in the near future, we were going to get a Head of Finance, Accountant, and somebody was going to ask me to compute board metrics.
The way the bookings were working at that point was that reps were putting into Salesforce all of the details about a deal after the deal was signed.
So you could imagine whatever creativity they were coming up with actually to get this thing over the line; it rarely matched whatever schema had been built out in Salesforce to capture that data. This meant that we had no integrity around our bookings, and we had no idea how to roll all of this stuff up.
Then you start trying to do things like pay people and report out, and it just becomes incredibly painful.
So I knew early on that I had an opportunity to look for a CPQ solution or something along those lines to make this a little bit less painful before we started processing 50 or a hundred or 300 deals a month.
That's why I kicked off the search.
It was definitely obvious to me that we needed a solution. I found that I was being asked to help prepare board metrics, and I noticed that there was much argument and confusion around what was going on.
I saw the way that our Salesforce modeling had been originally set up and I noticed that the data from our agreements that we did have models for was a flat set of on the opportunity object.
And they were trying to articulate things like what the platform fee was and the seat price and how many seats we sold. We had all these confusingly named fields like total seats, platform seats, incremental seats.
It just didn't make any sense to me.
It was trying to shove what should have been a relational model - with products and line items and all of these things - into a single flat file; it was the system's expression of trying to do with a database we're trying to do with the spreadsheet, what you actually need a database to do.
It was obvious to me that we had a challenge once I tried to roll up some of this data and just saw how messy it was, and how it just didn't match what we actually signed.
At Mode, where I worked previously and I had implemented this sort of thing, I initially went without a CPQ solution. I found that Salesforce's built-in functionality was not quite going to do the trick.
So I said, okay, I don't want to make that mistake again, but do I have to go all the way to Salesforce CPQ?
I knew that Salesforce CPQ is kind of the default answer; It's the "buy IBM."
Nobody ever gets fired for buying IBM.
But I also knew that nobody likes Salesforce CPQ. Most of my reps who had worked at other companies that were larger had used it before and had nightmares about it.
I also knew that Salesforce wouldn't sell you CPQ without a $30,000 professional services agreement. I could probably handle that, and the budget wasn't the issue, it was mostly the expression of how hard it would be to implement.
And I wasn't afraid of the systems challenge. It was more that, it just told me a lot about the configuration burden. So I went on a search for other vendors, maybe more modern vendors that could help me here.
I looked at PandaDoc briefly but realized pretty quickly that they're not actually a CPQ solution, they're more of a making-your-orders-and-quotes-pretty solution.
But when I started looking through Modern Sales Pros, I found a post by Pete Kazanjy, who's a fairly prolific person in the Revenue Operations and Sales Operations world. And he says, "Hey, we use RevOps here and it's like playing a video game. You just press buttons and deals come out. And it feels really fast and it feels really fun."
When I saw the platform, I said my gut tells me, this is the future. And I started a conversation and the sales process, and one thing led to another, and wound up with a contract to get going with RevOps last year.
I was fairly new at the company, so the first thing I had to do is I had to do was own the pain. And by that, I mean, I set up a deal review process where I started looking at all of the agreements as they came in the front door.
I built out some of the Salesforce architecture, and fields that were going to be required, not only for RevOps but just to model this stuff - line items and contract details and all of that.
One of the things I have found in the Operations space is generally it is impossible to adequately build strong solutions if you yourself have not experienced the deep pain of the problem.
And the problem here was the unstructured nature of these agreements. Unless I was really in the details, I wasn't going to know what to build.
I made sure that I had a high degree of certainty that I could build a solution that made sense to me in RevOps. That's when I pulled the trigger on the product.
I set off on about a two-month process of owning the deal review process so that I knew what the shape was of all of the data that we had to put into the system.
What I mean is, I needed to know what are the things we typically negotiate on? What are the types of terms that we typically deploy? And that's really hard to do because you can't just search through PDFs. You know, we do pricing caps. We do pricing guarantees. We do auto-renewal. We do this, we do that. Some of it's obvious, but some of it's not.
And then I had to figure out how all of those things should be modeled in our database.
I could then point RevOps at those things in order to capture the information.
It was an iterative process. It was a lot of reading agreements; historical ones and those that were coming in the front door. And then you notice patterns over time.
I also worked with a vendor called Klarity. They are building a solution that basically allows for structuring data from contracts; SaaS contracts are one of their first use cases.
I fed them all 350 historical agreements and some measure of the patterns that I saw. And then they came back to me with structured data that said, you know, these are all the different things we've noticed - data points, auto-renewals, contract dates, all that sort of thing.
I used all of these things to triangulate what I think the data model ought to look like, and I got about 85% of the way there.
One of the things that I like about the way that RevOps deployment works was it was pretty easy for me to add onto that data model as time went on.
I would notice we're actually doing more pricing and renewal pricing guarantees. Okay, cool. I can add some fields in Salesforce. I can add a term in RevOps. I can wire them together and then not worry about it.
Similarly, we had a challenge with customer opt-outs or termination for convenience. That was the sort of thing that we don't do very often, as most companies should not. But when you do them, you need to know about them and they have huge implications on RevRec and other things. And so that was something that I was able to pretty quickly spin up in RevOps and in Salesforce and start capturing appropriately.
The actual configuration wasn't the blocker, it was more making sure I understood the shape of the data that we needed to launch. In my mind, the MVP we launched had to feel 10x better to a sales rep than the next best alternative. Because it's kind of like TurboTax - people think that the competitor to TurboTax is H and R Block and a few other things.
They're actually wrong about that. The historical competitor to TurboTax is the pen and paper, and everybody could always fall back on doing things manually or working with an accountant.
In my world, the pen and paper was Dropbox and DocX templates that were hanging out in the folder that people could use and just say, oh, you know, I couldn't figure out how to do it in RevOps or whatever.
All of a sudden I could get a deal on my desk. It's already signed. And it's like, well, we can, we can accept this, right? And then I'm in a horrible position where I have to basically accept the deal that doesn't look right or defer the revenue and re-sign it and all that fun stuff.
So I needed to make sure that RevOps had a real wow moment. That was what I keep talking to our CSMs about; that there had to be a number of wow moments or else we weren't going to be able to get this off the ground.
So I worked hard with the team to make sure that when we launched, it felt smooth, it felt modern, and it felt really polished across all of the deal use cases that we had.
There's always going to be a little bit of a transition. You know, anytime you launch a CPQ solution, there are deals currently in flight. So you can't just say that today, everything moves through CPQ. There's a deal that's already out for signature that didn't go through.
We got to a place where over 95% of deals in the queue in the September of Q3 were being done through RevOps in our SMB segment, and now it's a hundred percent.
I can't remember the last time we had a deal that that was done outside of RevOps in the SMB segment.
And again, I don't want my reps living in two worlds. I need a solution that works for them, without any caveats.
We're just onboarding enterprise now. So that's why I keep, I keep caveating that, but for the SMB reps, which is maybe we're all focused on this, the world for them is, is much, much improved.
And for me as well.
I sleep very soundly for the most part about deals that run through RevOps. The process of building the quote and building the structure means that my eyes have been on every single deal before it goes out the door.
This is by design.
I want to make sure that I see even the smallest deals because sometimes I can catch little things. It also means that there's no more passing around of DocX or PDF files internally to get things looked at. There's always an extra pair of eyes on the deals, which makes me feel a lot better about them.
And there's a lot less data entry.
At the point of closed-won, reps would have to spend probably 10 or 15 minutes gathering data from the PDF and putting it into a whole number of fields in Salesforce; that doesn't happen anymore. You don't have to go and fetch the PDF and put it in a certain place and figure out all the details or work through all the cryptic fields.
All of those things happen because RevOps writes the data back into Salesforce and then I can use Salesforce workflows to put all the data into all the complicated places it needs to go.
So it's just a system that's working and it allows reps to move a lot faster.
Just two weeks ago, I had a rep who joined in December get a Bluebird deal that came in. It was hefty. It was about a $90,000 deal. The customer had an expiring budget at the end of the year and needed to use it and wanted to use it with Retool.
And he said, I, I don't know how to do this. So I did a 20-minute training with him on RevOps and we put the deal together and about 10 or 15 minutes. The DocuSign was out and signed, I think within an hour. Right. It just is very simple, very straightforward.
And there were no issues, like if the language was correct. And I don't have to load it into DocuSign and configure it and send it; it all just kind of happened. And then there was no additional downstream accounting. It's just like he was able to close the deal.
I started tracking what I loosely call agreement errors, or agreement issues, earlier in the year when I was really at my wit's end with all the challenges that we were finding. With the SMB team, I found that one out of every two agreements, so 50% of agreements in June, had some sort of issue, a problem that I didn't like, such as the date was off by a day or we forgot to include some sort of term or something like that happened.
Now, I think I saw one agreement issue in Q4 with the SMB team (out of 150 deals).
