In this week’s episode of the Enterprise Monetization Podcast, Sandeep Jain sits down with Albert Wong, Director of Revenue Operations at Alloy to discuss some of the struggles revenue operations teams face when trying to select tools to use for their Quote to Cash Lifestyle.
Welcome to the 13th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders from monetization space that is CPQ billing, so that you can learn about challenges, opportunities and best practices in enterprise monetization. Today, I'm pleased to invite Albert Wong to this podcast. Albert has deep expertise in the field of revenue operations. Currently, he's the director of revenue operations at Alloy that I'm sure most of you are aware of, but we'll let Albert talk about that in a second. But prior to Alloy, Albert has worked at companies such as CaptivateIQ, Gong, Blend, and others. With that, I want to extend a very warm welcome to Albert.
Thanks for having me.
Awesome. Thank you for your time. So let's jump into this Albert. So before we go into Quote-to-Cash or CPQ billing, your favorite topics? Could you just share a fun fact about yourself with audience?
I guess some quick things about myself, born and raised in Southern California, a certified scuba diver and my deepest dive was about 125 feet, where it was probably questionable if I should have been doing that at all.
That sounds like a lot of fun. Awesome. That's a good hobby. When was your last day by the way? Did you get time to do those?
My last dive was last Thanksgiving, roughly.
Not too far ago. Well, the Thanksgiving is coming up again. So maybe the next time. Moving on to the next one up, could you give a background to our listeners? How and when you started? How do you came about revenue operations? Is that what you always wanted to do, or you assured yourself in that direction, somewhere along the line?
So I myself, started my career out in consulting for financial services. I did that for a little, over two years before I got my first job in the startup world at a FinTech company called Avant where I was doing BI and then I switched to a strategy role at a company called Loot Crate that was consumer facing. And that my first real b2b role was ad blend, where I was one of the founding members of the business operations team. And I joined as the first biz OPS person, under the CEO at Gong, where I helped skill it and accidentally transitioned into sales operations. And then from there, I built in started the RevOps team at Captivate. And now I'm leading the RevOps team as director of RevOps here at Alloy.
Alright, so let's talk more about alloy, what does Alloy do?
So, Alloy is a data orchestration platform to help identify frauds, what it does, is connect with a variety of data sources that essentially provides data identification, it's like, is this person who they say it is? And because of that, can we actually confirm them? It's primarily designed to help anyone, who's dealing with financial data. So a lot of FinTech companies, as well as banks, especially as the financial world is becoming more digitized.
Give us a little bit more information about the Alloy in the sense of how many employees you are. And how big is a sales ops team?
Alloy is roughly around 323 0r 330 people right now. I would say the direct sales team, somewhere AES is something between 15 to 20 and then BDRS is probably around10 or something like that. And then we have solutions engineers, I would say it's probably another 10 or something like that. We also have post sales teams, and so on. So as for my direct team, I specifically manage the revenue operations portion, where it is the sales and marketing operations piece. While we also have a post sales, CX operations person and enablement within my team as well, directly under me, there are four and then we have two enablement people and a CX operations person. And my boss, the VP of revenue operations, that oversees all of us.
That's pretty interesting. And the reason I say this is revenue operations sometimes just involves sales, but the name is revenue operations part. But it seems at Alloy, you're doing marketing, sales, customer success, the whole revenue cycle, which makes the revenue operations synonymous to what it should be. So it's interesting to see the word matching the work.
Yes, it's something that's we did it by design, mainly because we wanted to streamline everything, because what happens is, none of this stuff sits in a silo, it all effectively flows from one team to the next. So we essentially sit there as decentralized team, that it's essentially helping pass information in a more consistent manner. So we can properly report to the executive team as well as to other teams that, this is exactly what's happening. This is how things are moving through the funnel.
Awesome. So let's do a double click on that. Could you start from the start? What are the things that you're using? What are your pin points in this relay race, beginning from the marketing stack?
From our marketing stack, our primary marketing tool is Marketo. And I'm sure there's a number of other stuff on top of that, and especially as you are moving towards adopting and ABM strategy, while Salesforce is our bread and butter, that's actually holding information across the board and tied to Salesforce. There's like a million other tools, Lane data for routing and zoom info, for essentially data enrichment. I'm currently going through a CPQ implementation, and also sales engagement tool such as sales loft, which we are actually transitioning off of, and then post sales, it goes to a another platform called Catalyst.
What about the billing side? What's the handoff from the courts to do the invoicing?
On the billing side we previously did off of opportunities, and it was a manual process. And then we essentially we're creating these opportunities and stuff and uploading them and then creating it afterwards in a platform called Ordway. We looked at Ordway once previously for CPQ purposes, but it didn't fit the bill. It wasn't flexible enough and what didn't fit the complexities that we needed it to. And as such, we actually ended up implementing in Salesforce CPQ, which has been a massive, undertaking.
Understood. I'm assuming there are some stories here that you might want to tell, so the billing is manual, and the coding around Salesforce Marketo for marketing, use the term called ABM, I believe that's Account Based Marketing. The practitioners would know but in case somebody's wondering what that is. So tell me one of the biggest challenges, this is not specific to Alloy. And you worked at big companies like Gong, which is a massive company captivate IQ. Now there are big sales company, one of the things that you see, again and again, the core problems in this stack.
The core problems of sourcing across is having documents and having systems of records and having information, that works for everyone across the org, or essentially, how do you provide the right information for these different groups, from sales, to finance, to accounting, to legal, which are probably the main groups that really deal with the sales cycle, and especially creating quotes and sending out sales orders and stuff. And that's one of the big problems, that I've seen over and over again, and it's a massive point of friction, and you have to go back and forth all over the place. So it's like, this is what I'm seeing from here. This is what I'm seeing from this system. So what I'm seeing from that system, essentially, that reconciliation just take so much time and energy.
Do you think it's an implementation problem? Or is it an architectural problem? Is it a tool problem? All of the above?
I think the problem is, a lot of these tools, they were designed for local maximization rather than global. And what I mean by that is, essentially, each of these tool was meant to optimalize for a certain thing, for a certain purpose. And when the product designers, product managers went into this process, I think very much the emphasis was just that, it's the, how do I do everything I need for this function? for these purposes? without looking at the bigger picture of, let's not think of all of this as individual parts, but rather like an entire entity. And that's been one of the big problems, where it makes it so, not all of this fits together. Because who made it, they weren't working together when designing it. It's just okay, we built all this out. And then they can talk to the next piece using an API, and someone else will figure out the next piece, to do all the cleanup.
Understood. When I talk to customers, especially high growth companies, I see most of them start off using a manual order form, a Google Sheets or a Word doc. And it seems that it's because it's much easier to do, when you're starting off with few customers, that's a quick thing to go. But they keep on doing this because it becomes a habit. Could you talk about, what's the pros and cons for using manual order forms and not automating it?
The pros of it is, one, it's incredibly flexible. It's pretty much unlimited flexibility, you can do exactly whatever you want. And two is, it's free/cheap. Essentially, you don't have to spend any money implementing, and it's just the amount of energy and stuff that you have to put into creating the initial quotes, is a lot easier. And for a small company, or an early stage company, when they haven't actually figured out a lot of their pricing and packaging, it honestly makes a lot of sense. Because you're constantly in a reiterative process of like, I don't know what the structure is, I'm going to test this way out and that way out. And sometimes you might be testing multiple pricing models at the same time, where on a system that's much more complex to do. But if you're at a 10, 20, 30 person company, it's like, okay, I have two salespeople. I'm the CEO, and I'm the direct sales person. It's like, okay, I can test all these different things. So that's definitely the benefit of a manual, simple order form, like on Excel or Google Sheets, as I've seen before. The problem is, when you scale, when you actually have a more set process of, this is what the expectation is. Where you're trying to scale, we're starting to hit that next, that first renewal and stuff, you start running into a lot of different problems then, in terms of scaling, what happens is, you're no longer just like the CEO, who's also the seller, but you are actually having a sales team and where you're having a sales team. If you don't lay down a proper system or something like that. Allowed them to do whatever they want, it becomes the Wild West, where they can go rogue and do some pretty crazy things. As I can tell, from personal experience, I have seen sales orders, where they sold things, where technically there's no way to actually differentiate or something like that. And what I mean by that is we sell as the company only has one type of license period. But we sell this as if there's two or three different types of licenses to provide different pricing. And we're like, we sell one type of license for account executives, one type of licenses for BDRs, or something like that. But the reality is, the company itself only has one license. So it's pretty much completely going by trust of what your customer tells you like, we hired a 10 more AES or 20 more BDRs, the BDR price might be half as much, you have zero clue if they're telling the truth or not really. And you're not about to try to scan over and ask them for their org chart. So I've seen instances like that, where it can be really scary. I've also seen stuff like for this specific type of person, or persona or something, you have unlimited licenses. So where it effectively capture your ability to ever do real upsells. So that's the danger of, why you need to actually put some constraints, and actually need to have a system in place in order to stop crazy sales orders like these.
Understood. What I've also heard about and would love to get your perspective on that is this bad data. And by that what I mean is, these codes get QDF, and they get signed. But somebody has to operationalize this freeform text into your Salesforce CRM or whatever CRM you're using. And the operations team and the billings team, now need to actually extract that data. So could you talk about like if we are using or if anybody's using a manual order form, how does this translation happen? What's the cost for that? And is it okay to do it?
It is an extremely, painful process, especially for a stranger, or wonky deals, where turtling might be all over the place. As if you have something that's like, this deal is for 13 months and 10 days or something like that, it can be really bizarre. Just from personal experience, how I had to do it is essentially, figure out the time length, and then change it to based off of whatever the company's time length is, it's like, by month or something like that, you have to transform it, as this equals to 12.11 month and calculate it out for the contract value, whatever this upsell might be. And that amount of manual overhead is one, it's very prone to error. So it's easy, if you under calculate, then it means you're getting yourself paid less. If you over calculate, and you get caught. It leaves a really bad customer experience. People bring up questions and they question your professional competency. So it hurts either ways. And try to get it to be perfect means sucking up a lot of time and energy. Oftentimes the folks who need, it is probably like into finance, or someone who is usually decently quantitative and analytical. And it's honestly not the best way for them to spend a lot of their time.
Got it. What about amendments, renewals, proration? How should companies deal with manual order forms? Is it easier to do? Does it become increasingly harder?
Increasingly harder without a doubt. It becomes so much harder because for a manual order form, there's nothing for you to really be able to automatically reflect on. You have to go and essentially look up what the original order form, in order to do the amendment, especially if there is some type of tearing, like from ‘X’ amount to ‘X’ amount, and this amount of price and then for the next tier, it's for the next amount of price, that whole process has to be pretty manual And then like I said before, you have to calculate it out for that TCV, which can be very cumbersome. And for renewal, you also have to look back and see, what was the exact terms or what type of provisions are there? I've seen built in deals, where there's provisions like, upsell, next year renewal, the maximum amount of price increase might be like 3%, 5% ,7%, or something like that. It's built in advance or like, there is actually a contractual cap to it. And when you don't have a set system, you pretty much have to almost start playing layer, until they go through line by line. It's like, wait, what was the special terms associated to this?
Well, that seems like a lot of work. And what do you think about I've heard these things called AE axiety. If you're using a manual order form, is everything all right? Is that a thing?
As the robots manager, and I have actually had the experience where we essentially screwed up, it's actually an AE screwed up a quote, bad enough, where it was a couple of $1,000 discrepancy. And I would say, the amount of stress and pain it caused, definitely what we would classify as that. And that's the other part, when AEs have to go through and check through all these little bits and pieces. A bunch of times, what it does is, it sucks energy, and momentum from them to actually going out there to sell. Instead, they're trying to check in for the map. It's like, is this actually right? Am I going to be able to get approval for it? What are all the issues, which, it's not the best use of their time either?
What do you advice or recommendations to probably vendors or product managers, for these tools who are listening to this podcast? Like how should they think differently about solving the problems?
It's pretty much what I said at the beginning of the podcast, of really thinking about things from a broader, more global perspective, instead of thinking of them locally. Too often, our organzations way too siloed, where finance thinks about finance, where accounting thinks about accounting, and sales thinks about sales. There's not a collective group. It's like a gathering of minds. Let's think about this whole process, from end to end, that impacts all of us. So I think it's definitely having a meeting of the minds, of actually understand what this whole process looks like. And try to understand, what does a great process look like? And each of us might individually take on some more pain here and there. But overall, it becomes the most optimal process for the entire team. And from there, you have the discussion, which is as what should we be bringing on board? And quite frankly, from what I've seen it, it is oftentimes, the least number of systems possible. The idea is, you bring on as many systems as you have to, but you try to limit it to the minimum number of possible, I think is probably the ideal. So that's where, really systematic thinking, of if there's a vendor where it's covering multiple portions, as monetize does, it does help where it is, we're thinking about this problem. And this problem, too.
Understood. And what are the priorities for you in the next couple of quarters.
Internally for my company, one of the big priorities is actually billing. We are currently on a utilization billing model. And I can definitely say, there is some pin points associated with it, especially with that and disconnect of not having CPQ before. So that's definitely one of the top company priorities. For myself. It is essentially driving much more of an outbound motion and activity. And essentially to help my team hit the targets.
Any metrics that you will recommend that Reb ops people listening to this podcast should be using to understand the health of their current systems?
I guess that depends on what type of help we're talking about. If we're specifically talking more about the CPQ, where all the Quote-to-Cash world and stuff like that, I would say what you want to see is, what is your rate of collection? How much of your invoicing going out, you're able to collect? And also, what's the average turnaround time that you're able to actually get cash everything in? Versus, we had sales orders out for X, Y, Z amount of time, we haven't been able to do this piece or that piece, and it's stalled out too long. And also, it's like, what is the procurement process? Or what's the process of average timeline, of when someone sends out the sales, essentially starts the quote, to be able to send it out and getting it signed? What parts are taking up a lot of time, energy and momentum? For me personally, and that's also on the plate right now, there is a legal component of contracts and stuff on an iron clad, how does this all fit in? It may not have been globally optimized before. And now I'm diving into that right now.
Let's talk about usage billing. Actually, the thing that you brought up earlier? Is this something that you look at a new tool? Because you're saying you're implemented a CPQ? Or you're implementing one, you probably have something for billing. So when you think about usage, how do you tie the ends together with an existing CPQ, or billing system? How do you think about that problem?
Billing or utilization billing is, a little bit of the new trend. And it's good and bad in some sense, the good part is, it's a great marketing pitch. Where you pretty much can tell customers, you are only going to have to pay for whatever value you're able to derive from the platform. And that's a very strong message. But the bad part to it is actually being able to execute, it is really crazy difficult. And what I mean by that is, it is interconnected process of everyone needs to be on the same page, from essentially sales to finance to accounting to legal to a lot of the technical side, because a lot of the utilization metrics and stuff that is actually flowing from the technical end, so it's flowing from your product and engineering people, which a lot of traditional times, they haven't been super, intertwined into the go to market motion. But with a utilization model, they become much more central to that, in order to actually make this whole thing work. So I would say, the thing about having set systems ahead of time, it makes it so much more structured, versus the whole idea of engineering is you engineer for scale, or describe engineering almost like never make sense. If you're trying to do something went off. It only makes sense if it's the idea of like, I can spend 100 hours to build this thing that saves me five hours of time in perpetuity. That's why it makes sense. If it's like, I'm going to spend 100 hours to build this thing that saves me something that would take 10 hours time. And I'm only doing it once, it doesn't make sense anymore. So that's where I would go from it. That's why you need to have a lot more set systems or else, there's no way you can, try to build for every single one off that, someone could come up with off of their infinite amount of creativity on a sales order, will drive every one crazy across the org and it just sucks so much time from everyone.
Got it. Actually a follow up on that. How often do you see people building their own tools because they're frustrated with what is available outside or maybe just not connecting well with each other?
I don't think anyone really tries to build the whole thing end to end, they might build parts, bits and pieces of it, here and there, try to bridge a gap. It's very rare to see someone like, I'm going to build my own entire CPQ system. I've heard of certain instances, but they're very rare. The only ones I can name off top my head are like Microsoft. I know, Microsoft has an infamously like famous billing system where that whole system probably cost like billions of dollars all on its own. And it can do the craziest most complex stuff. But the number of businesses that are at the scale where I can dedicate that much resources, that are just not very many. There's Microsoft and then, who does this leave open to be also be able to do this? I guess Meta and Google can, but not that many other people can.
That reminds me, I was at Cisco a long time ago. And we had our own CPQ. We used to call it CCW, Cisco commerce workspace. I don't know if it's still around, but to your point, big companies, they end up building their own but that's interesting. There's one thing we haven't talked about as yet. But the trend of which I see more or less the similar to usage billing, which is self serve. In B2B, some people call it product lead growth. What are your thoughts about this? Is this thing real? And actually, more than that, from a revenue operations perspective, what does it mean to you?
I definitely think that the trend is very real. It also perfectly aligned with this no code movement, essentially, the idea of simplifying things and making things a lot more usable for like non technical users. It's essential for velocity, it's essentially like, a company is trying to build, and they're making changes quickly, they need to have the ability to actually make these changes themselves. And instead of each time they want to make these changes, they have to have a meeting of the mind with someone externally, like I don't want to have to go to one of my vendors or contractors each time and go meet with their CSM or their services team to make a slight tweak, that takes up a lot of time, because that’s line up calendars and stuff like that. So this trend towards self serve is very real. And it is a representation of how far technology has developed, where previously technology was developed, especially for enterprise software. It's developed for experts. Now it's developed for much more generalist, people who are trying to build and run a company. One thing you'll definitely see from this is probably a greater emphasis on R&D to make this experience possible. And probably a discount in the amount of services revenue, a lot of companies might have.
That's interesting. But how about revenue operations if Alloy decides to do self serve, what does it mean to your internal systems? Is it like something easy? For revenue operations team to incorporate that as a channel? Do you have to go back to the drawing board again? Like what's the experience like for RevOps teams?
It's definitely something you have to really think through because you have to figure out, for this self serve, how much of the enterprise experience does it encompass? Alloy itself has three product lines right now. Is this self serve going to cover all of them? How are the bundling and packaging and stuff going to work on it? So there's a lot of considerations to it? But we're self serve deadly, is much easier to jump in is, if you already sold the initial product and then it's about utilizing the product is much more self service as well, as upsells is much more self service that already provides a lot of time savings and costs.
One thing that I've heard, which I would love to get your feedback on as, like you already have a CPQ billing system. They have their own product catalogs, often, which are disparate. But now your self serve, as you were saying earlier, out of three product lines, we will sell only one. And so do current billing systems, CPQ systems understand self serve, while you have to go back to the engineering teams to build something for you. Like, how does that work?
So I would probably say, in a self serve world, you want to keep the catalog simpler. Even if there's something crazy and complex in the back end of all these different things you might sell, I would say, at least for customer facing, keep it very simple, where it's like, here's the clear selection list, or five options or something like that. You don't want to delve down this rabbit hole of like, there's 200 permutations, it's going to break everyone's brains and, they don't know what to do with it. And it causes a lot of hesitancy on the users and buyers end.
This brings us to almost end of the podcast. How do you see this industry changing by the way, we talked about consolidation as one of the trends? Maybe looking at the forest instead of the trees? I think that's what you're suggesting earlier. But anything else, do you think from a revolution perspective that's happening in this industry?
I think we are in the situation where technology has got better, there's more, no code solutions out there. And because of that, there's a general trend where like MPs are what's acceptable, what's okay, for enterprise tech is going to be higher, the bar is going to be higher, effectively. Previously, you would very much say, the MPs for an iPhone beats out any enterprise software by not even a mile, probably, like a flight worth of miles or like we're talking 100,000 miles or something like that. That gap is going to slowly bridge more and more over the next coming years, where the demand for enterprise tech is it needs to be a little bit better. So that's where it's trending towards, which coincides with what I said about, these tools should be easier to use, so they can be self serviced.
Got it. Albert, it was a pleasure speaking with you, but before you go, is there any resource like a blog, a podcast a community that you might recommend to our listeners?
So for myself, my personal favorite podcast I listened to is actually, ‘Masters Of Scale’ by Reed Hoffman. Reed Hoffman is obviously the founder of LinkedIn and partner at Greylock. Some of them can be a little bit cheesy, but overall, I love hearing stories of essentially like how founders, built what they built. So that's probably my personal favorite podcast. And as for books and stuff, the best business book I've ever read was actually ‘Ride of a Lifetime’ by Bob Iger, who was the former CEO of Disney?
What did you like about the book?
What I liked about the book was, yes, it was an auto biography. But at the same time, I'm sure some of it was embellished, but he does talk about the really hard parts of his journey. The really hard parts of his experience, where he had to deal with pretty bad issues, where things really hit the fan, such as there was an incident at a park where a child was (Inaudible 40:04) and like how do I deal with this whole crisis and his whole process of how he's been at Disney for a while, he was affected like CEO. And they dangled the role of CEO in front of them for years, for almost like a year or something like that, when they had a pain of other people, go through like how about we considered this person, this person and being although, I liked the fact that it made it much more relatable of, it wasn't just all success, but he also talks about some of its failures.
Got it. Anything on revenue operations, that comes to you, as some resources online, I know that they're not many to be honest, when I look around, I wish there was some RevOps University or something.
I think there are some Reb ops universities, online courses and stuff like that. But I think the revenue operations is as a relatively new trend. Right before this, probably the last couple years ago, even when I first transition in revenue operational was just first starting to pick up, before that it was much more siloed as marketing operations, sales operations, and maybe like CX operations, CX operations itself is very new. While marketing operations with stripe is new, I'd say marketing operations, you can maybe step back as far as like HubSpot and Marketo, whenever they came onto the scene. While for CX operations, it's roughly as far back as maybe Gainsight. So like, those are definitely a bit newer, while sales operations is a bit more mature. And the idea of consolidating them all under one umbrella is still very, very new. So I would say even the best thought leaders in this space, they've only had honestly, a couple of years, they were much more specialists in one of these, and then they're like, okay, because of my expertise in these things, I'm helping connect the dots in a lot of this stuff.
It's interesting, you mentioned this, I know we are almost to the end of the podcast. But revenue operations, as we discussed earlier, covers three things marketing, sales, and customer success. But when I look at the company's, most of the times revenue operations actually bought into the head of sales. So they call it revenue operations. But it's sales ops, ish. At only very few companies, I've seen revenue operations reporting into the COO role. And one of my pieces is, early stage companies don't have a COO, they have a CEO, they have head of sales, they have head of functions. And this RevOps is by definition, a merging of functions. And there is no role other than the CEO, where this merging happens. So it's sometimes CEOs don't want to have this thing reporting into them. And sales is usually the most vocal, out of the three groups. So they end up getting the team. I don't know, this has been my observation.
I would say, in those cases, I would describe it, as those are not real revenue operations. Much more of the trend, where it's like, this is what the latest trend is, let's just change the title lane to align with market. I've actually had a paddle of essentially sales and marketing operations, or sales and RevOps, professionals. And in this panel, in this conversation, the consensus was a large none. Alot of them actually would say, these were a little more senior folks. So they're not analysts or something. They were all minimum, like senior manager, directors and VPs, and stuff like that. Their consensus was pretty much, I would not report to a head of sales, I would not report to a VP of sales, I would only be willing to report to, much more a new trend as well as a CRO or CEO.
That's a good point. Some companies do get a CRO before they get a COO.
I would somewhat echo that settlement, which is funny to say because obviously my old boss Christian was VP of sales, but I would describe Christian was a unicorn where yes, he was VP of sales, but this was A guy who actually had ‘X’ sales operations experience, ‘X’ finance experience. So he definitely was able to think about things in a little bit different perspective than someone, who just purely came up through the sales award.
Got it, Albert. It was really good speaking with you and thank you for your time today.
Absolutely.
