neon-rutger/b2b-revops-skills/pricing-monetization-ops

Pricing and Monetization Operations

You are a monetization operations specialist. Pricing is strategy. Monetization is execution. This skill covers the systems, infrastructure, and processes that turn a consumption or hybrid pricing model into reliable, auditable, customer-friendly revenue.

The core challenge: Consumption pricing is only as good as your metering, billing, and reconciliation infrastructure. Get the plumbing wrong and you overshare with some customers, underbill others, break revenue recognition, and spend your quarter in spreadsheets trying to reconcile.

Stage check: do this before anything else in this skill

This skill was written for a company that already has a repeatable motion and named owners. Applied at face value to a company that does not, it prescribes governance, scoring and cadences the team cannot run, and it hides the one question that matters at that stage. Sort the company into one of four situations first, state the situation in the first paragraph of the deliverable, and run only the version the table names.

The four situations (full definitions and signals in references/stage-check.md):

1. Start-up, pre product-market fit: fewer than roughly 30 comparable customers, wins from the founders' network, no measured win rate, cycle time or retention, nobody on quota. The only question: do existing customers get the promised outcome and would they buy again? Run the minimum version, or do not run it.
2. Start-up, product-market fit: one segment with 10 or more customers won the same way, a known win rate and cycle time, retention measured monthly, one CRM owner. Run the skill for that one motion; thresholds are guidance, not rules.
3. Scale-up: named owners for sales, marketing, customer success and operations; trusted CRM stage history; reps on quota; a forecast someone is held to. Run the full skill.
4. Enterprise: situation 3 plus more than one revenue organisation, a governance layer above go-to-market decisions, and finance owning the board revenue target. Run the full skill with the enterprise deltas in the table.

If the evidence is thin, ask three yes or no questions: Is there a segment with 10 or more customers won the same way? Is retention measured monthly? Does someone own the CRM as part of their job? Three no answers means situation 1. One or two yes answers means situation 2. Three yes answers means situation 3 or 4; then ask three more: Is there more than one business unit or region with its own revenue plan and leader? Do go-to-market decisions pass through a formal governance layer? Does finance own the revenue target for board reporting? Two or more yes answers means situation 4; otherwise situation 3.

The full skill applies to both scale-up and enterprise. Not every skill applies at every stage; the table below says what this skill does at each, and "do not run" is a valid answer.

What this skill does per situation:

Skip before product-market fit: Layer 2: Rating and Pricing Engine; Layer 4: Collections and Payment; Layer 5: Revenue Reconciliation and ASC 606; Operational Playbook 2: Packaging Changes and Price Increases; Operational Playbook 3: Data Quality and Billing-Grade Standards; Operational Playbook 4: EU/GDPR Considerations.

The Monetization Stack

Every B2B company running consumption or hybrid pricing has five interconnected layers:

LAYER 1: METERING
  Usage ingestion, normalization, deduplication, customer mapping
  ("What events happened, and who did they belong to?")
 
LAYER 2: RATING & PRICING ENGINE
  Contract-aware billing rules, tiered pricing, overages, credits, minimums
  ("How much did that customer owe, given their contract?")
 
LAYER 3: INVOICING
  Invoice generation with auditable line items, payment terms, reconciliation
  ("What bill did we send, and can we prove why?")
 
LAYER 4: COLLECTIONS & PAYMENT
  Payment processing, dunning, retry logic, churn detection
  ("Did they pay, or do we need to follow up?")
 
LAYER 5: REVENUE RECONCILIATION
  Contract-to-invoice matching, variable revenue tracking, ASC 606 compliance
  ("What revenue should we recognize this month, and why?")

Break any layer and the whole system collapses:

• Bad metering = wrong invoices. Bad invoices = churn from bill shock.
• Bad rating = revenue leakage (you underbilled) or customer churn (you overbilled).
• Bad invoicing = no audit trail. No audit trail = month-end re-reconciliation and finance mistrust.
• Bad collections = cash timing misalignment and churn spikes.
• Bad revenue recognition = wrong revenue in the books and investor confusion.

Layer 1: Metering Architecture

Metering is hard. It's easy to undercomplicate it and impossible to overcomplicate it.

Core Metering Flow

Every billable event (an API call, a report run, a token consumed, a user seat-day) triggers your application to emit a usage event:

Event Emission:
  Timestamp, Event ID (idempotency key), Customer ID, Subscription ID,
  Event Type / Dimension (e.g., "api_calls", "storage_gb", "active_users"),
  Quantity (e.g., 500 calls, 10 GB, 3 users), Metadata (tenant, region, feature)
 
Event Ingestion:
  Stream to a real-time queue (Kafka, Pub/Sub) or API endpoint
  → Pipeline buffers, timestamps, and adds source tracking
 
Normalization & Mediation:
  Customer ID mapping (raw API key → billing customer account)
  Dimension standardization ("api_calls" vs "API Requests" vs "request_count" → single canonical name)
  Time window anchoring (event UTC timestamp vs ingestion lag vs billing cycle anchor)
 
Deduplication:
  Idempotency key matching. If you see the same event ID twice, keep only one.
  Aggregation window (hourly, daily, or per-billing-period) to coalesce raw events.
  Late-event handling: events that arrive after the billing window closes.
 
Aggregation & Customer Mapping:
  Roll up raw events to the subscription level.
  Cross-check customer ID against your billing customer table.
  Flag mismatches: unknown customer, deleted subscription, or orphaned events.
 
Output:
  Metered line item per dimension per billing period per customer subscription.
  Example: Customer A, Subscription X, May 2026, API Calls: 2,450,000 units

Deduplication and Idempotency

This is the highest-leverage move in metering. One duplicate event = double billing. Millions of duplicates = churn and legal liability.

Best practice:

• Every event carries a globally unique Event ID (UUID or scoped ID like "customer-123-request-uuid").
• Billing system stores seen event IDs in a dedupe log for the last 12 months (or longer if you have annual contracts).
• If the same event ID arrives again within the deduplication window, reject it and log it.
• Backfill mechanism: if events arrive late (24 to 72 hours after the period closes), re-run the metering pipeline to recalculate the subscription-month total.

Real-world pattern: Publish / Subscribe with at-least-once delivery + idempotent consumption. Your event queue will deliver each message at least once. Your metering system must absorb that guarantee and emit exactly-once billing records.

Customer Mapping at Scale

As a customer's account grows, their usage often spans multiple systems: your app, your API, a third-party integration, a data warehouse sync, AI tokens from an LLM provider, support tickets. All of those need to map back to one billing customer ID.

Pattern:

Application layer emits events with:
  user_id / api_key / tenant_id / session_id (what created the event)
 
Mediation layer maintains a mapping:
  user_id or api_key → account_id / billing_customer_id
 
Metering aggregates by billing_customer_id, not the raw upstream identifier.

Gotcha: When a customer adds a new team, integrates a new tool, or provisions a new API key, you need to update this mapping fast. If the mapping lags by hours, the first day of usage on the new API key doesn't get attributed, and the billing invoice is incomplete. Sync the mapping hourly or on-demand before you aggregate.

Metering at Scale (1B+ events / month)

For high-volume usage (APIs, AI, compute):

Unified Events Architecture (three-stage pipeline):

1. Raw collection: Real-time event stream with minimal processing. Store to a data lake or warehouse.
2. Aggregation: Nightly or hourly batch aggregation from raw events to metered subscriptions. Use a warehouse query (Snowflake, BigQuery, Redshift) to group by customer + billing period + dimension, aggregate sum(quantity), and land metered totals in your billing system.
3. Dedupe check: Run a cardinality check: if event IDs are unique, you have N events. If you have duplicates, the cardinality will be lower. Flag the difference and investigate.

Why warehouse-native metering:

• Scales to billions of events without middleware infrastructure.
• Backfill is a SQL query, not a complex backpressure mechanism.
• Audit trail is built in (warehouse logs every query).
• Cost is lower than a purpose-built metering platform when volume is high.

This skill consumes: raw usage events from application logs or analytics platforms (reliability: high if application-emitted, medium if inferred from product telemetry), customer ID mappings from your CRM or identity system (reliability depends on sync currency; flag mismatches), metered aggregates (generated by this skill; audit trail built in), billing system records and invoices (reliability depends on platform auditability).

Layer 2: Rating and Pricing Engine

Once you have metered quantities, you need to apply billing rules. Billing rules are contracts. Contracts vary wildly.

Contract-Aware Billing: Six Structures