How do you architect revenue ops for a cloud infrastructure company in 2027?

What consumption-based revenue architecture actually is

A cloud infrastructure company sells capacity, throughput, and time — compute-hours, gigabytes stored, requests served, egress transferred, nodes running. That single fact reorders everything downstream in revenue operations. In a seat-based SaaS company, the revenue event is a contract signature and the operational cadence is the renewal calendar. In an infrastructure company, the revenue event is a metering tick, and it happens thousands of times per second across every customer simultaneously. You are not architecting a sales operations function that happens to sell infrastructure; you are architecting a metering and reconciliation system that happens to have a sales team attached to it.

The practical consequence is that your system of record splits. CRM opportunity records still exist, but they describe commitments and expectations, not realized revenue. The actual revenue lives in the usage pipeline: raw metering events, aggregated into rated usage, applied against commitments and credits, netted into an invoice. When a finance leader asks "what did we bill last month," the answer comes from the rating engine. When a sales leader asks "how is the Acme account doing," the answer also comes from the rating engine — because the health of that account is a usage curve, not a stage field.

Most infrastructure companies run some version of a committed-spend contract. A customer signs for a dollar commitment over a term — say $600,000 across twelve months — in exchange for a discount schedule, and then draws that commitment down through consumption. This structure creates a set of revenue-ops objects that simply do not exist in a seat world: the commitment balance, the burn rate against that commitment, the projected exhaustion date, the overage rate that applies past the commitment, and the true-up or forfeiture terms at term end. Every one of those needs a home in your data model, a refresh cadence, and an owner.

The reason this matters beyond bookkeeping is that these objects are the leading indicators. A customer whose burn rate implies they will exhaust a twelve-month commitment in seven months is an expansion conversation you should have in month four, not month seven. A customer running at forty percent of committed pace in month eight is a churn risk with a specific number attached to it. Neither signal appears anywhere in a traditional pipeline review. If your revenue architecture cannot produce a ranked list of accounts by commitment-pace variance on any given Monday, it is not architected for this business model — it is a seat-based system wearing infrastructure clothing.

There is a second structural difference worth naming: the buyer and the user diverge more sharply than in most software. The person who signs the commitment is usually a VP of engineering, a CTO, or a procurement lead. The people who generate the usage are individual developers and platform teams spinning up services, often without any awareness that they are consuming a contract. Your revenue architecture has to serve both — commitment-level reporting for the economic buyer, and granular per-project, per-team, per-environment attribution for the practitioners who actually control the spend. Companies that only build the first layer discover that they cannot answer "why did our bill go up" during a renewal, which is the single most damaging conversation to lose.

The step-by-step process for standing up the architecture

Building this in the right order matters more than building it fast. The sequence below reflects the dependency chain: nothing downstream works if the metering layer is unreliable, so you fix that first even though it produces no visible dashboard for weeks.

Step one: establish the metering contract. Sit with product engineering and write down, for every billable dimension, exactly what constitutes a countable event, when it is emitted, what its idempotency key is, and how late an event can arrive and still be counted. This document is boring and it is the most valuable artifact in the entire project. Ambiguity here — "does a failed request count," "is storage measured hourly or at a daily snapshot," "do we bill egress between our own regions" — becomes invoice disputes twelve months later. Expect this to take three to six weeks of real calendar time because it requires decisions, not just documentation.

Step two: build the usage pipeline with reconciliation baked in. Raw events land in an event store, get aggregated on a fixed schedule, and get rated against the price book. At every hop, emit a count and a sum, and build an automated check that compares hop N to hop N-1. The failure mode you are defending against is silent partial loss — a pipeline that drops two percent of events and never tells anyone. Two percent of a $40M usage business is $800,000, and you will find it during an audit rather than on a Tuesday.

Step three: model commitments and credits as first-class objects. A commitment record needs: contract value, term start and end, discount schedule, drawdown rules, overage rate, rollover terms, and current balance. Credits — trial credits, service-level credits, promotional credits, partner marketplace credits — need their own ledger with expiry and application-order rules. Application order is not a detail. Whether a customer's promotional credit burns before or after their commitment changes both their invoice and your recognized revenue.

Step four: sync a deliberately thin slice into CRM. Do not replicate the usage warehouse into Salesforce. Sync the small set of fields that change seller behavior: current-period usage, trailing-90-day trend, commitment balance, projected exhaustion date, and pace variance versus plan. Five to eight fields, refreshed daily. Everything else lives in the warehouse with a link.

Step five: rebuild forecasting on cohorts, not on stages. More on this below, but the mechanical step is: define net revenue retention by cohort, build a baseline expansion curve from historical cohorts, and forecast existing-customer revenue as baseline plus adjustments rather than as a sum of opportunity records.

Step six: instrument the reverse path. Usage data flowing to sales is half the loop. The other half is contract data flowing back to product — entitlements, rate limits, feature gates, and hard spend caps. A customer who signed for a commitment with a hard cap needs that cap enforced in the platform, and that enforcement is a revenue-ops responsibility as much as an engineering one.

Costs, timelines, and typical ranges

Budget honestly, because this project is consistently underestimated. The metering and rating layer alone is a six-to-twelve-month effort at most companies that have outgrown their first homegrown version, and the cost splits roughly evenly between engineering time, tooling, and the organizational work of getting product, finance, and sales to agree on definitions.

On headcount: a cloud infrastructure company doing eight figures in usage revenue typically needs at least one dedicated revenue-ops person whose entire job is the usage-to-invoice path, separate from whoever owns CRM administration. Below roughly $10M in annual usage revenue you can often combine these roles; above it, the combination reliably fails because invoice-cycle work is deadline-driven and CRM work is interrupt-driven, and the deadline work wins every time, leaving the CRM to rot.

On build-versus-buy for the rating engine: commercial usage-billing platforms exist and are a reasonable choice when your pricing model is conventional — a handful of metered dimensions, standard tiering, standard commitments. Building becomes defensible when your pricing has genuinely unusual mechanics, when your event volume is high enough that per-event vendor pricing becomes punitive, or when metering is so entangled with your product's core data path that extracting it creates more complexity than it removes. The honest test: if you cannot describe your pricing model to a vendor in one page, you are probably building. Note that "we might change pricing later" is not a reason to build — most commercial platforms handle pricing changes better than homegrown systems do, because that is their entire product.

On timelines for the analytics layer: once metering is trustworthy, cohort-based forecasting and account-health scoring take another one to two quarters. The gating factor is usually historical data quality rather than modeling effort. If your metering changed definitions eighteen months ago and nobody restated history, your cohort curves are built on sand, and the first real project is a backfill. Plan for that backfill explicitly rather than discovering it in month two.

On what to expect from the numbers themselves: net revenue retention is the metric that matters most in this business model, and it behaves differently from seat-based NRR. Consumption NRR is more volatile month to month because it moves with customer workload rather than with contract dates. A single large customer migrating a major workload can swing a quarter. This volatility is a reporting problem before it is a business problem — leadership accustomed to seat-based smoothness will read normal consumption variance as a crisis. Set the expectation early, report on trailing multi-month windows rather than single months, and separate the metric into its components: expansion from existing workloads growing, expansion from new workloads landing, contraction from optimization, and churn from workload migration away.

The optimization category deserves specific attention because it is unique to infrastructure and adjacent to the FinOps discipline your customers are running against you. Customers actively work to reduce their cloud spend. A customer who cuts consumption thirty percent by right-sizing instances is not churning — they may be more committed than ever, and their engineering team may now regard your platform as well-managed rather than expensive. If your revenue architecture cannot distinguish optimization-driven contraction from dissatisfaction-driven contraction, your churn analysis is noise. The distinguishing signal usually lives in the workload dimension: optimization holds workload count steady while reducing per-workload cost, while genuine churn reduces workload count.

Where teams get it wrong

The most common failure is treating billing as a finance system rather than a revenue system. Billing gets built inside finance to produce correct invoices, optimized for accuracy at month-end close, with no thought given to whether sales can see the same numbers mid-month. Then sales builds a shadow usage report from a product analytics tool, and now the company has two numbers that never match. Every account review turns into a reconciliation argument. The fix is architectural and has to happen early: one rating engine, one set of aggregates, multiple consumers reading from it at different latencies. Sales can read a less-final version of the same data; sales cannot read different data.

The second failure is over-syncing to CRM. Someone decides sellers need usage visibility, so a pipeline pushes daily per-service usage records into Salesforce as custom objects. Six months later the org has tens of millions of rows, API limits are exhausted, reports time out, and nobody trusts the fields anyway because the sync fails silently on Sundays. CRM is a workflow tool, not an analytics warehouse. Push the handful of fields that trigger action; link out to the warehouse for depth.

The third failure is forecasting existing-customer consumption through opportunity records. Sellers are asked to create opportunities for expected expansion, which means they are guessing at how much compute a customer's engineering team will use next quarter — a thing the customer's own engineering team often cannot predict. The forecast becomes fiction, and worse, it becomes fiction that a seller is compensated on, so it gets optimistically shaped. Existing-customer consumption should be forecast statistically from cohort behavior, with seller input reserved for the events they actually have information about: a known migration date, a contract renegotiation, a customer that just told them about a planned workload.

The fourth failure is compensation design that fights the model. Paying commission on booked commitment value rewards a seller for landing a large commitment the customer never consumes — which produces a forfeiture fight at term end, a damaged relationship, and no real revenue. Paying purely on consumed revenue makes new-logo selling economically unattractive because consumption ramps slowly. Most companies that get this right land somewhere in between: a landing component on commitment with a clawback or holdback tied to actual consumption reaching some threshold, plus an ongoing component on consumed revenue above the commitment. The specific structure matters less than the principle — the comp plan should make the seller care whether the customer actually uses the product.

The fifth failure is ignoring the partner and marketplace channel until it is already material. Cloud marketplaces have become a significant path to purchase for infrastructure software because they let a buyer draw down an existing cloud commitment. That channel arrives with its own data shape: different billing cadence, marketplace fees, private-offer mechanics, and attribution that does not look like direct sales. Companies that bolt marketplace onto an architecture designed only for direct contracts end up with revenue they cannot attribute and margin they cannot explain. Design the commitment and credit ledger from the start with the assumption that some contracts will be intermediated.

The sixth failure — quieter than the others and more expensive — is treating the metering definitions as settled. They are not. Product ships new capabilities, and each one raises the question of whether it is billable and how. Without a standing forum where product and revenue ops decide monetization at design time, you get features that ship unmetered, and retrofitting metering onto a live feature is far harder than building it in. Establish that forum early and make attendance non-optional.

Decision framework: when to choose what

The architecture choices in front of a cloud infrastructure company are not universal — they depend on pricing complexity, scale, and how much of the business runs through commitments versus pure pay-as-you-go. A few decision rules hold up across most situations.

On billing infrastructure: buy when your pricing fits a conventional shape, build when metering is inseparable from your product's data path or when event volume makes per-event vendor economics untenable. Revisit the decision when pricing complexity or volume changes by an order of magnitude, not annually.

On where analytics live: the usage warehouse is the analytical system of record, always. The question is only what gets pushed outward and at what latency. Push to CRM what changes a seller's next action. Push to the product what a customer needs to see about their own spend — and treat customer-facing cost visibility as a retention feature, not a courtesy, because a customer surprised by a bill is a customer negotiating from anger.

On forecast methodology: use cohort-based statistical forecasting for existing-customer consumption, and rep-driven pipeline forecasting only for new logos and known contractual events. Blending them into one forecast number is fine; blending them into one methodology is not.

On team structure: at smaller scale, one revenue-ops team covering the whole path is right. As the usage business crosses roughly $10M in annual consumption revenue, split the deal-desk and commitment-structuring work from the metering-and-analytics work, because those roles require different skills and different reaction times. The deal-desk role becomes essential earlier than most companies expect, because non-standard commitment structures proliferate fast and each one is a future reporting exception.

On adjacent motions: if you sell a self-serve tier alongside enterprise commitments, resist the temptation to run them on separate systems. The product-led path and the sales-led path should share one metering layer and one usage warehouse, differing only in the workflow layer on top. The whole strategic value of a self-serve tier is that it feeds the enterprise motion, and it cannot feed anything if the two paths cannot see each other's data.

How this compares to adjacent business models

It clarifies the design to look sideways at neighboring models, because the boundaries are where the reasoning becomes visible.

A hybrid platform company — one selling both per-seat licenses and consumption add-ons — faces the hardest version of this problem, not the easiest. Two revenue models means two forecast methodologies, two comp structures, and a constant question of which number leadership should watch. The workable pattern is to report them separately at the top level and only combine at the total-revenue line, resisting every request to produce a single blended retention metric. A blended NRR obscures exactly the thing you need to see: whether seat growth is masking consumption decline or vice versa.

A managed-services or professional-services attach changes the picture differently. Services revenue is time-based and does not fit the metering pipeline at all, but it strongly predicts consumption growth because implementation work lands workloads. Track services as a separate revenue stream, then correlate services engagements to subsequent consumption ramp — that correlation is often the single best argument for funding a services team, and most companies never measure it.

An open-source-core infrastructure company adds a visibility problem no metering layer solves: a large fraction of usage happens in environments you cannot instrument. The revenue architecture has to accept a partly blind funnel and lean on proxy signals — download telemetry where it exists and is disclosed, community activity, support-channel presence. The temptation is to build increasingly invasive instrumentation into the open-source distribution, which reliably damages the community goodwill that makes the model work in the first place. The better path treats the open-source population as a market-sizing input rather than a pipeline, and invests in making the commercial conversion moment obvious.

There is also a useful comparison to the customer's side of the table. Your enterprise customers are running FinOps practices that mirror your revenue architecture from the opposite direction — allocating your charges to their internal teams, forecasting their spend with you, and hunting for optimization. The more your platform helps them do that well, the more defensible your position, because a customer who can attribute your cost to a business outcome can defend the line item. This is the argument for investing in customer-facing cost analytics even when it appears to work against short-term revenue: it converts a spend line into a justified spend line, and justified spend survives budget cuts.

Related questions

How is consumption forecasting different from subscription forecasting?

Subscription forecasting anchors on contract dates and renewal probability. Consumption forecasting anchors on workload behavior: cohort expansion curves, trailing usage trends, and known migration events. Rep-entered opportunities should cover contractual events only, never baseline consumption growth, which is far better predicted statistically.

What should sales reps see about usage inside the CRM?

Five to eight fields, refreshed daily: current-period usage, trailing-90-day trend, commitment balance, projected exhaustion date, and pace variance versus plan. Anything deeper belongs in the warehouse behind a link. Pushing granular usage records into CRM exhausts API limits and produces reports nobody trusts.

How do you handle customers who reduce spend through optimization?

Separate optimization-driven contraction from dissatisfaction-driven contraction using workload counts. Optimization holds workload count steady while cutting per-workload cost; genuine churn reduces workload count. Reporting them together makes churn analysis meaningless and hides both a retention risk and a healthy customer behind one number.

When does a cloud infrastructure company need a dedicated deal desk?

Usually earlier than expected — often around the point where non-standard commitment structures appear more than a few times a quarter. Each bespoke drawdown rule, rollover term, or overage schedule becomes a permanent reporting exception, so the deal desk pays for itself in avoided downstream reconciliation work.

Should marketplace revenue run through the same architecture as direct sales?

Yes, and design for it before it is material. Marketplace contracts carry different billing cadence, fees, and private-offer mechanics, but they still draw down commitments and consume metered units. Building a parallel path produces revenue you cannot attribute and margin you cannot explain.

FAQ

What is the single most important thing to get right first?

The metering contract — the written definition of what constitutes a billable event for every dimension you charge on, including idempotency and late-arrival rules. Everything downstream inherits its ambiguity. Companies that skip this step spend the following two years arbitrating invoice disputes that trace back to a definition nobody wrote down, and each dispute erodes trust in every number the revenue team produces.

Can you run consumption revenue ops without a data warehouse?

Not at any meaningful scale. The volume of metering events and the need to aggregate them across multiple time grains, customer hierarchies, and product dimensions exceed what an operational database or a CRM can serve. A warehouse with well-defined usage marts is the minimum viable analytical foundation, and trying to skip it usually means building a worse warehouse accidentally inside a reporting tool.

How do you compensate sellers on consumption revenue?

Most workable plans blend a landing component tied to commitment value with an ongoing component tied to actual consumed revenue, plus a holdback or clawback if consumption never materializes. Pure commitment-based comp rewards overselling commitments that get forfeited; pure consumption-based comp makes new-logo work unattractive because ramp is slow. The principle to protect is that the seller's incentive should track whether the customer genuinely uses the product.

How often should usage data sync into the CRM?

Daily is right for nearly every case. Real-time syncing creates load and API pressure without changing behavior, because no seller acts on an hourly usage change. What matters far more than frequency is reliability and visible freshness — a timestamp on the record showing when it last updated, and an alert when the sync fails, so nobody makes a decision on data that quietly stopped moving.

Does this architecture change for a company selling both seats and consumption?

Yes, and it gets harder. Run both models on separate forecast methodologies and separate retention metrics, combining only at the total-revenue line. A single blended net revenue retention figure hides whether seat growth is masking consumption decline. The metering layer can be shared; the analytical treatment above it should not be.

What breaks first when the architecture is wrong?

Trust in the numbers, usually surfacing as a mid-quarter argument between sales and finance about what an account actually consumed. That argument is the symptom of two systems computing usage independently. Once it starts, every subsequent forecast conversation carries the same doubt, and the practical fix — consolidating on one rating engine — is far more expensive than it would have been to design correctly at the start.

Sources

• https://www.openviewpartners.com/blog/usage-based-pricing/
• https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox/
• https://www.finops.org/introduction/what-is-finops/
• https://aws.amazon.com/marketplace/features/private-offers/
• https://cloud.google.com/pricing/list
• https://azure.microsoft.com/en-us/pricing/
• https://www.bvp.com/atlas/state-of-the-cloud-2024
• https://stripe.com/docs/billing/subscriptions/usage-based

Related on PULSE

• How do you forecast consumption revenue without renewal dates?
• What does a usage-based compensation plan look like for enterprise sellers?
• How do you build a deal desk for non-standard commitment structures?
• What belongs in a CRM versus a data warehouse for revenue teams?
• How do cloud marketplaces change go-to-market attribution?