#123 Forecasting Consumption Revenue

Philipp Stelzer: Hello and welcome to another edition of the RevOps Lab Podcast. I'm Philip, and I'm here together with Ioannis. Hello, Ioannis.

Janis Zech: Hello, hello. Hello. Good to have you.

Philipp Stelzer: Good to be back myself. I think the last two episodes were done by you as a solo podcast warrior. Sorry to do this, yes. And our guest today is like a repeat guest, actually, Colin Gerber from Socure. Colin, good to have you back.

Colin Gerber: Yeah. Great to be back. Feels like it was just yesterday.

Philipp Stelzer: It basically was.

Colin Gerber: Basically was. Yeah. More or yeah. About a month, I think.

Janis Zech: Yeah. That's when we last talked.

Colin Gerber: Yeah.

Philipp Stelzer: Colin, for those of our listeners who don't know who you are, who are you, and what do you do?

Colin Gerber: Yeah. Totally. So, yeah, I'm Colin. I am leading revenue operations and strategy over at Socure. We are in the IDV and digital identity and KYC space. So, basically, any sort of digital transaction or any instance where you need to prove who you are, who you say you are in the digital world, we power the technology that actually enables that. So anything from ecommerce, traditional banking, a lot of fintech, public sector slash government, online gaming or gambling, you name it. If you have to say you are who you say you are on the Internet, Socure powers it.

Janis Zech: Yeah. That's obviously a huge market, and I think it's only about to become a lot bigger as, like, yeah, I think just faking identity is becoming easier and easier, I would argue. Like, to some extent.

Colin Gerber: To some extent. Or even, you know, what we call first party fraud. You have a little buyer's remorse, and you say you didn't do something that you did, and you try to pull a fast one — that's also another really big and growing segment of fraud.

Janis Zech: Alright. Okay. Not just made up identities or people stealing our identities. People do it themselves too all the time.

Colin Gerber: Yeah. Yeah.

Philipp Stelzer: My wife has an ecommerce business, and there's some shady stuff going on. With some customers. Anyway. Okay. Going on a tangent here. I think to bring people back up to speed, and for those who missed part one where we talked about CPQ, which was a really, really good episode — can you just give us a quick recap on how pricing is working at the moment at Socure?

Colin Gerber: Yeah. Totally. So, you know, we are predominantly or majority a consumption based model. We do have some, I would say, repeatable or contractual based revenue. Like, that would be things like a nominal platform fee or annual support fee. But generally, the vast majority of all of our revenue is based on API call consumption. So the way our product works is a platform comprised of, you know, thirty five modules, and each module does a different thing. Say you are an ecommerce business and you want to screen the people coming to your website at the top of the funnel — so consumer onboarding — you configure a workflow. That workflow would be solving the use case of consumer onboarding. There would be several modules below it in a sort of waterfall that essentially does different hits on different pieces of your identity or digital identity to ensure you are who you say you are. So our pricing is really based on the API calls throughput within those workflows, within those individual modules. We're similar to, like, an AWS or a Databricks pricing. We do spend based discounting and different things. Like, if you have a fairly even baseline of knowing what your volume's gonna be, you can do commitment, prepayment. That also really drives what we call ROI based pricing or ROI based selling. So that's really our model in a nutshell at this point.

Janis Zech: Yeah. So it's very much outcome based, I think, is how a customer would look at it?

Colin Gerber: Yeah. That's actually super interesting that you bring that up. I'll come right back to that. But, yeah, what we're calling is decisions, and the decisions themselves are basically a combination of a number of modules they have to go through. If it's a riskier identity — or say, you know, one demographic in the eighteen to twenty five age bracket — they don't really have a lot of credit history or a lot of actual digital history on the Internet. Like, they've probably never taken out a loan. They've probably done some BNPLs, stuff like that, but there's really a thin file. So we might be calling more modules to ensure they are who they say they are. Maybe someone with a longer credit history or someone who's maybe at more of a middle aged bracket and has a lot more history on the Internet, a lot more history at these different companies — you might only call a few modules. So at the end of the day, decisions, yes, are outcome based, but whatever modules are being used is really dependent on the consumer coming through and how risky their profile actually is and how much it actually takes to ensure they are who they say they are.

Janis Zech: Okay. And just a quick follow-up question on that. Like, it sounds like when a customer makes one API call, they actually don't know how many modules are being called or what the cost of that API call is. Is that a fair assumption? And then, like, how do you give them reliability on total usage, similar to, like, a cloud bill where you sort of just know how much you actually spend?

Colin Gerber: Yeah. That's a great question. I mean, that's really something we've really been doubling down on in the last eighteen months — really that real time billing or real time visibility into your consumption against what you're actually contracted for from a price perspective. I'd say go back maybe four years when our infrastructure was still kinda being built, a customer would get an invoice, they would see all the calls they made, there'd be some explanation, but they really wouldn't have that real time visibility. But even prior to signing a contract, when we do an offline POV or POC, we run a sample set of their customer data — like a representative sample set. So they do understand when they're configuring the modules and the workflows, about what percent of people coming through any given workflow are gonna hit, say, the first step or top of funnel versus ones who may hit the second or third steps, because there could be seven to ten modules maybe in a workflow. Those are probably divided into two to three steps. So they're not calling one one one one one. It's usually like three or four, maybe another two, and then maybe a final one if there needs to be a step up. And usually for a step up, that's after document submission — like, you take your passport or your government issued ID, scan it, and that's really the last way for them to actually tie everything together. So we do do these tests so they do kind of understand their populations and who's actually gonna be hitting what and what percentages. So there is somewhat of a baseline of what to expect, and they do, once again, have the real time visibility within the platform to what they're actually consuming from the workflow use case to the module level.

Janis Zech: Yeah. Super interesting. I mean, it reminds me very much of the agent builder we launched, where you also have essentially different types of agents you can build, and depending on the workflow runs and the complexity of the agent you're including in the workflow, you have different kinds of consumption. Okay. That makes a lot of sense. Thanks for clarifying.

Colin Gerber: Definitely.

Philipp Stelzer: Alright. I think it's great to have you, Colin, because I think consumption based forecasting — or just consumption based pricing, and as a result, also consumption based forecasting — is becoming more and more prevalent. Like, it's popping up everywhere. Right? Like, traditional industries or companies that have used seat based pricing before are now shifting either to some kind of hybrid models or trying to go all in on consumption based pricing. I'm not saying that customers always love it. I think if you come from seat based pricing and switch to consumption based pricing, it can be a quite tough one. But it's happening, right? And especially new companies, when they launch their business, they immediately start with consumption based pricing more and more. I think it's just something that is driven by AI, which is the accelerant here. But speaking from a RevOps perspective, I think it's interesting because it puts you in this position where it's not like what's closed won that is defining what actually can be forecasted on, but there's something else that you need to untangle in order to get into the position where you actually can do a proper forecast. So I'm just curious what your current setup is overall. What would be interesting to talk about is how does a typical forecasting session look like at the moment at Socure? And then we can talk about the tooling, the ownership, the processes behind it.

Colin Gerber: Yeah. Definitely. Really, a signed contract that's, once again, potentially what the revenue could be — there has to be a lot of evidence and supporting pieces to actually substantiate it. And one thing about consumption based pricing — like, in a typical seat based or SaaS world, kind of the RevOps machine stops at closed won typically. It's like, okay, we booked it, we know we're gonna get this revenue. Being in a consumption based model really extends it out and extends out the responsibility and the controls and structures you need in place after closing, because that's really where most of the work is at that point. So when we typically go through and forecast, obviously looking at sales stages or looking at the funnel itself — the more mature the deal is, the more we're gonna know about it. One thing we did have implemented in the past year is what we're referring to as a solution readiness document or solution readiness process. And I think I might have touched on this a little bit on our last call. But essentially what this is is basically spelling out exactly what is the business use case, how are we solving it, what's the solution, and how is that solution comprised? Like, what product, what modules are you using? The second part of this, which is the actual substantiation or the really valuable part when it comes to forecasting and what we actually gut check our bookings or pipeline amounts against — and this is something that happens a little later stage, probably in parallel with our contracting stage or toward fairly late stage — this is what we call the phase two. This is essentially a custom object my team had built out in Salesforce, which basically takes the use case and we have one record per use case. And then what are the number of decisions you're making on a monthly basis? What are the modules which comprise that use case? And like I was saying, we could be in steps. So modules can be grouped together — one, two, three. What percentage of the decisions are actually gonna hit those modules? So say the first step is gonna be a hundred percent. Second step could be fifty. Third step could be twenty five percent. Basically, based on the pricing that the customer has in their contract, times the number of decisions, times that percentage for each module — that is basically the number that we use to substantiate the bookings number. So those numbers need to be pretty close or the same, because that is a solution that our solution consultants have worked on with the customer using all the contextual information they have through discovery — like understanding, for consumer onboarding, how many new customers are they signing up each month? Really understanding what that looks like. Is it — if it's an online gambling site, it might be a little bumpy, a little seasonal. If it's like a BNPL, could be a little smoother. But a lot of these companies, especially the more mature ones, should have an idea of what their actual net new customer acquisition is a month. So it's really that mass times the number of decisions a month, times the percent that each module gets hit, times the price of the module. And then we substantiate that against the bookings, so that really gives us our best guess or our best foot forward onto what the actual booking number should be. And that's the number that we actually book and close when the contract is signed. So that's really the main control prior to booking.

Janis Zech: Yeah. Is it — so I grew up in performance advertising. Sounds very similar complexity. Would you say, like, do you have a minimum contract term? Is it always twelve or twenty four months so you can just spell out the number? Or do you take into consideration the seasonality of the customer data that they give you? Like, often there's specific quarters that have specific ramps. Is that something that you take into consideration on the new booking side?

Colin Gerber: Yeah. On the new booking side, we book at an annualized number at what we call full ramp. So if it's an existing service or company — and we see this a lot in state and federal government, like say it's for the Internal Revenue Service in the United States, say it's for taxes — like, they know how many taxpayers they're gonna have. They know how many people each year are gonna log in and file their taxes. But say it's like a prelaunch or very early fintech — they don't actually really know. And that's where we tend to be a lot more conservative and maybe only book what they're actually contractually obligated to. But kind of in the middle ground — say we have a fairly robust and mature BNPL or online gambling — like, sure, there's some seasonality in there, but they generally have an idea of how many new people they're signing up. And we kinda bake that into the annualized number at full ramp. Really, when we're talking about what we call internally as our BAR — booked ARR realization — that's really where it does depend on what month they're actually implementing and then what that realization looks like month over month based on that time in the year. So say if we're — I keep going back to BNPL and online gaming — we know these companies have code freezes in, typically, September, October. It'd be for NFL season in the US or Black Friday, but we know they're gonna see a huge spike in November, December for BNPL, for online gaming September, October, and then playoffs like January, February. Those are the big spikes, that's the seasonality, but that's what we model into the ramp for each individual opportunity against these customers that we're booking.

Janis Zech: Do you have a gap between close won and go live?

Colin Gerber: Yeah. So with our platform and the way we've been doing implementations, we mostly do what we call a live trial now. So typically most of our new customers are actually fully implemented by the time that we actually close won them. Even if they're just sending test data through, their workflows, their modules, everything — their model that they're using — everything's kinda been just checked, sense checked, tuned. So at close won, at least from our end, the majority of our customers at this point should be ready to start using. Typically when we see a lag in any sort of implementation or utilization, it's typically based on the customer's timeline. That's something that the team has gotten a lot better about sussing out. Like, is there gonna be some sort of internal change or internal delay? Like, are you not launching this specific product that you implemented us for until x y z date? There's usually externalities we need to be aware of. It's not typically our own implementation delays because we're doing this upfront prior to close now via live trial, where typically before we had done an offline POC or POV, which was a demo test environment, demo test information. But now we're actually running them in the live environment prior to signing the contract.

Philipp Stelzer: So basically you model out the new logo bookings number. You have ramp. You have pretty clear guardrails around how do you convert from kind of a trial into production or into real revenue. How do you do the actual revenue recognition and in-life, right, existing customer forecasting? Because I assume that is super important. Right? Like, that's where you have the extra data. You see probably also discrepancies between what was planned versus what the actuals are. How do you deal with that, and how does that feed into the forecasting?

Colin Gerber: Yeah. So we're on a monthly forecast cadence. Typically, after we close each month, we have a meeting series that is curated by my team and our FP&A team. This is our realization series. Essentially, that's exactly what it's looking at. It's a very specific cohorted view of our booked opportunities by customer, looking at the actual revenue realized against the ramp forecast that was provided. From there, we either move stuff — essentially upgrade or downgrade. You can be upgraded off the list. Like, hey, they're on their ramp, they're hitting their number. There could be ones where we need a way to explain a discrepancy, and then we adjust the forecast. And then in a very small, not so typical case, there is also a thing where, like, hey, this customer signed, they didn't use it, they don't intend on using it. That's marked as red, and that ends up being a write down, and we actually back out the bookings. That doesn't happen too often, but it's either like, hey, they're doing great, we can move them off this list — they have graduated from the realization, what they said they're using, they're using. There's ones that are yellow — they're below, but there's still a path to get there, and we need to monitor and adjust the forecast accordingly. Then there's the small population where it's like, this is not gonna happen, it's not gonna materialize, it needs to come off the backlog. But that's really the account executives, our CSMs, speaking to each specific opportunity and speaking to the forecast that they provided based on the customer ramp at time of booking and what's actually realizing.

Janis Zech: Okay. Yeah. That's super interesting. One question that pops up in my head — so you mentioned already some custom objects. Right? So I'm assuming you tried to do some of this in Salesforce, but what kind of other architecture have you deployed just to control it? Because from the way you describe it, it sounds like there's a lot of alignment going on, and you sort of need to pull in information a bit manually also from different sources and just discuss things. I'm curious if that is true.

Colin Gerber: Yeah. I'd say the majority of it is actually systematized. The pieces that we don't have systematized — basically what we call the monthly ramp realization forecast — we use a seed file which feeds into Tableau, because in Tableau is where we run this meeting or do this reporting. Essentially it's marrying Salesforce for all the pipeline slash SRD data. We have Jira for our implementation tickets, which does factor into the BAR realization piece. We're pulling in NetSuite data, obviously, into Tableau as well for the actual revenue that's realizing. And then the actual forecast piece is on a rolling basis, and it is cohorted. We've tried to build stuff in Salesforce — not a great custom object use case there. So that is the one piece we are using a flat file or a CSV file to actually put in the ramp schedules to mirror all the revenue against and then cross reference all the workflows, opportunity specific information, booking information, just into one single pane. It's really simple as that. It's really four sources going into one kind of visual there, and those are the main pieces.

Janis Zech: Okay. Got it. So the monthly forecasting meeting, that's basically everyone sitting in front of a big Tableau report.

Colin Gerber: Yeah. And I was gonna say there's a fair amount of prework as well. So it's not really like we're discovering all the context prior to the meeting. Like, the week before we have it, all the opportunities or line items in question go out. The CSM and AE, they gather all the context, so that's actually in line. And then it's really only a discussion between them and the leadership as to progress, remediation plans, against a specific set of opportunities. And yeah, this one's only monthly because we do it after we close the books so we actually have our finalized revenue. We obviously do a fairly robust several cadences of pipeline or actual opportunity forecast. But this is really specifically to the realization piece, and we do it monthly because that's when we actually get the revenue for the month because we bill in arrears.

Philipp Stelzer: Okay. Let's dig a bit deeper into that because I think that's super critical to understand. Right? So you do the opportunity forecasting still. So you still basically ask reps, like, okay, which deal is real, which one would you commit? And then those basically go into a ramp evaluation. Or do you already say, like, hey, we have those ten deals that are being committed, and historically we know that ninety percent of those will actually properly convert and use the budget that they promised to spend with us? Or how do you do that piece? Because I think that new booking realization also needs to be fed into the system somehow. I'm just curious how you bring it all together.

Colin Gerber: Yeah. I think it's a common misconception in consumption based models that bookings are sort of irrelevant or it just comes down to revenue because you're kinda booking a made up number — but that's not really the case, because that does inform essentially your forecast and understanding how much revenue do we expect and how do we track towards this. So that's the goal line. As far as booking and at the top of funnel or in the pipeline — we understand, based on historical data, even customer type or customer size, what our realization will be at the twelve month mark, and that's usually our goal line. So when we report up to a board, report up internally, and when I was talking about these cohorts, we basically look at quarterly cohorts of booked customers, looking at the average ramp within each cohort. And we have an assumption on there. We don't wanna inflate our actual bookings target because we have a really low realization of it. That's why we wanna be really accurate. We wanna be ninety percent accurate. We don't wanna be realizing sixty percent on a rolling twenty four month basis because that would mean our bookings number is either wildly inflated or we need to wildly inflate it in order to get to a hundred percent. So that's why those controls at the top of the funnel or within the contracting process are very important. So it's as close to reality as possible so that we can get to that ninety percent realization by month twelve on average on a cohorted basis.

Janis Zech: Yeah. Just let me maybe play this back because I think it's actually really, really important. So in the end, there's like three motions going on. Right? There's the new logo bookings where you basically take away the amount field from the reps because you actually have built a custom object that essentially has input factors —

Colin Gerber: Well, we use it to compare, actually. The rep still does call their number, but if the number is way off from what the SRD is spitting out, then that's a discussion to be like, hey, something's not right here, we need to figure this out before we book it.

Janis Zech: Okay. Okay. But I think that's actually really, really important because obviously as a sales leader, what I want to do is focus my reps on certain customers that have core metrics that are very healthy, where the product we offer is very attractive and will generate a lot of revenue, and where the likelihood of ramp success is high. Right? So by customer segment, you have certain assumptions of ramp, you have certain assumptions on if you put these things in, this is the amount, and that gives guidance to the rep. And I think that is very, very important because if you don't do that, it will be all over the place. And then you already solved the gap problem — the gap problem being, you know, once it's closed won, often in consumption based, if you don't immediately start production, the ramp can be delayed for three, four, five, six months. We had that at Fiverr. We had a technical integration process, and we had huge customers, and sometimes we didn't get to the road map, and then we got to the road map three or six months later. And suddenly your forecast looks very different. Right? So I think that's one motion. Then the second motion is how do you do the actual ramp execution, right, where you have essentially the actuals versus the forecast. And my question there is, like, who's involved in actually managing the ramp? Is that the AEs and the AMs? Who is actually managing that? And how long are people comped on the new logo side into the ramp side? That's super interesting.

Colin Gerber: Yeah. So really, if we look at our account teams right now, it is kind of a — on the direct side, it is like a heavy technical team. Predominantly, those responsible for the ramp — the AE is always gonna be the quarterback on it. But the main DRI, the main person responsible for ensuring that the customer stays on track — it really is, like you said, it is our CSM, but we also have post sales solution consultants or post sales platform solution consultants. Those are the ones actually actively working with the customer on their deployment or implementation as well as tweaking and tuning things to ensure the performance they are getting is kind of like what we presented or what they had prior to close. But then there are also externalities. For us, a lot of it is — maybe a customer said that we were gonna be at the top of the funnel for their flow, but we're secondary to it. Like, how do we get moved up to the top of the funnel? Like you were saying, with the technical sale — do we understand where we are on the road map? Do they have engineering resources to actually do the integration? That really is that realization piece and the pieces that we need to be very clear about to actually accurately forecast these net new bookings or these new customers. Even with upsells and expansions, same thing. And then kind of on that piece, as far as compensation — generally, outside the AE team, seventy percent of folks' variable compensation is based on revenue. And that is either what we call GTM pod or segment based revenue that could be whatever kind of segment you're servicing. It could be at an executive level or leader level — it's like a company revenue or commercial versus public sector. But seventy percent of everyone's variable is on revenue. Majority of that revenue is gonna be existing customers or existing implementations, but that's still, you know, we signed them before twenty twenty six, most of that's gonna be ramping up customers from last year. There is a small piece which is ramping up new customers, but it's just kind of a compounding effect. And that's just all in your plans. The AEs — due to this being sometimes a slow burn — we want them to be motivated to get these customers ramped up, and they're basically paid out on a contract over twenty four months, so eight periods. And that starts basically at go live, which is a very low threshold — it's like a small amount of calls in a given month basically starts the clock, and then they get eight quarters from there on that opportunity to get paid out. So they are the most motivated, and should a customer ramp up too quickly, it's to get that revenue capture.

Philipp Stelzer: Yeah. I mean, it's also good to get a steady stream of income. No big Rolex purchase at the end of the quarter.

Colin Gerber: Depends on who you're closing, how long you've been here. So if you're a rep and you have what people like to refer to internally as a stacked annuity, you just kinda stack yours as overlap on top of each other. So we have reps who are gonna be getting paid out within three different plan years in the same period depending on when they were actually booking stuff and how long they've been here. So there's a compounding effect.

Janis Zech: I think this is actually really tricky because most AEs will probably not spend most of their time the next twenty four months, but actually the CSMs and the solution consultants will spend most of their time. But the AEs get most of the commissions. So it's a very tricky thing. Right? Like, it also depends obviously on the size and how involved they are.

Colin Gerber: Yeah. I mean, it depends on your risk tolerance. Like, I don't think I'd ever wanna be an account executive, but high risk, high reward. Folks on a solution consulting plan or a CSM plan, they're gonna have shared KPI targets. But if you're an AE, you're really only eating what you kill. So I think it just depends on what you're actually looking for and what motivates you, but it's a very different profile role to role. Like, a RevOps profile is not the same as a CSM profile, not the same as an AE profile. Different people want different things, and certain people — that resonates with them, and they wanna be an AE. So they like the risk, and they like the higher reward.

Philipp Stelzer: Yeah. Yeah. No. And it can be both. Right? It can be both. Just trying to move us on a little bit here because we only have a few minutes left. So last time, one piece in the last podcast that I really liked was just the top three mistakes, you know, that you would kind of warn others about when they move into consumption based forecasting. Do you have — I mean, if it's just two or if it's four, that's also fine. But curious if you have any recommendations, some advice for our listeners here.

Colin Gerber: Yeah. I think my two top main ones — and ones that are burned into my brain just over the last six years I've kinda been in this world. First one being, if it's fully consumption based and you are selling into small companies, I would say be very conservative on how you book. If it's like a prelaunch startup and they think they're gonna have crazy growth or crazy users, probably be like, that's great, we'll maybe book a follow on deal when that happens, but only book about what they're actually contractually obligated to. Otherwise, you're gonna have a huge hole in your forecast, and you're gonna be answering to everyone for the next twenty four months on that one and why that hasn't realized. Not to mention you will miss revenue targets if you do that enough times. And then the second one — in order to avoid a perverse incentive — you really want bookings to be important and drive some compensation, some performance management, but you do not want that to be the main focal point for your teams and how they're compensated, because that will end up with the same problem as well, which is overinflated bookings. Say you paid out on it, that person leaves — do you have a hole in your revenue forecast again as well? And it ends up being very unreliable, and people are basically motivated to do the opposite of what you want them to do. You want them to be there for the long term, grow the revenue. You don't want them to book a bunch of insane bookings that don't end up realizing and, despite your controls, you end up with the same thing and missing forecast.

Philipp Stelzer: Yeah. That's the worst.

Colin Gerber: Yeah. That's the worst. Those two are — when I'm thinking about realization, revenue — are the two big ones that stick out of my mind.

Janis Zech: So here in Germany, we had a moving company, and they incentivized the salespeople at the wrong time, and they almost went bankrupt because of it. It was high velocity, very different story. But I think obviously having guardrails in place and ensuring that the company won't suffer or you incentivize wrong behavior is always super, super important, especially with such a long time frame of ramp.

Colin Gerber: I mean, think about the gig economy — the Ubers and Lyfts of the world when they were doing the ride subsidies for the drivers and basically the fare wars. It was great as a consumer. I was paying like five dollars to go twelve miles, but it wasn't sustainable and it was a perverse incentive overall to a lot of the drivers. And they would be waiting till the surge hit. So the company was losing money because the drivers caught on to how they were actually doing things. And no matter how many times they kept changing it, it was just kind of a race to the bottom.

Philipp Stelzer: Hundred percent. Yeah. That was crazy. That was actually a fun story. So sorry — quick tangent here, but just recently you had a birthday party and one of the guests told me — so when Uber came to Berlin and Germany, they started handing out promo codes to all the different startups to get early adopters. And the promo code was always something like, and then the company name — it's always the same. So what he did is just went and typed in all the promo codes he could come up with just with all the different startup names. And then had, like, I don't know, like, dollars of free credits. Didn't take his bike or public transport to work anymore. Just used Uber for like half a year until he burned through all those credits.

Colin Gerber: Yeah. There are thousands of stories like that, I'm sure.

Philipp Stelzer: Yeah. Completely insane. Alright. Colin, thank you so much. Absolutely love the episode. Hopefully — well, I'm a hundred percent sure that this was very useful for our listeners. I