Tag: Salesforce

Ramps and Swaps 101: Easy Math, Hard Execution, Real Cost

Why the Math Is Easy, the Execution Isn’t, and Both Are Costing SaaS Companies More Than They Realize

For CFOs, CROs, and RevOps leaders at mid-market SaaS companies: learn why ramps and swaps cause bookings, billings, and revenue to diverge in Salesforce and NetSuite — creating margin leakage, RPO reporting gaps, and a finance team reconciling numbers that should never have drifted.


Ramps and swaps are two of the most common contract structures in B2B SaaS — but two of the most reliably painful to execute. A ramp is a multi-year deal where the price increases each year: for example, a customer commits to $20,000 in year one, $25,000 in year two, $30,000 in year three. A swap is a mid-contract product exchange: a customer returns the unused portion of what they bought and applies the credit toward something different. Both are standard. Both are expected. And both have a way of breaking things that shouldn’t break.

Consider this scenario. A customer calls their account manager. They’ve been on Product A for six months and want to upgrade to Product B. They expect a credit for what’s left on their current contract. It seems straightforward. The account manager agrees. They go to build the quote.

However, in most mid-market SaaS companies, what actually happens is more complicated than a three-day delay. The account manager calls finance, who is buried in month-end close. But even when the number comes back, it may not be what anyone expected. The implementation, training, or support services bundled into the original deal — discounted or included at no cost — were still allocated a portion of the contract revenue at the time of booking. The account manager never knew. They see what the customer paid, estimate the remaining value, and build the quote on a number that was never accurate to begin with. Add in the days that have elapsed since the swap request came in, and the proration has shifted too. The number is wrong twice over. The customer is frustrated. The deal is delayed. And everyone involved is doing work that, in a properly architected system, no human should have to do at all.

This is the ramps and swaps problem. Not a math problem. Not a people problem. A systems problem — one that most companies quietly absorb by building a RevOps team whose real job, underneath the title, is cleaning up the accounting side effects of deals the systems were never designed to handle.  What sales sees on an opportunity and what finance is actually recognizing in NetSuite are separated by seven records. That’s not a gap. That’s where margin goes to die.

Why Do Ramps and Swaps Leave Sales Flying Blind and Finance Cleaning Up the Mess?

To understand why this breaks, you have to understand what happens to a deal after it closes.

When an opportunity closes in Salesforce, the booking reflects what was sold: the price on the quote, the products on the order. That’s the number sales owns. It’s clean, it’s simple, and it’s already out of date by the time the deal reaches NetSuite.

In NetSuite, two things happen that Salesforce will never see. The first is allocation. When a deal includes a software license and a professional services engagement — even if the implementation was “free” — the revenue has to be distributed across both components based on their standalone value, not what the invoice says. A deal booked as $50,000 for software and zero for services might become $30,000 for software and $20,000 for services once NetSuite applies allocation. The invoice wasn’t wrong. The revenue treatment just reflects the economic reality of what was delivered.

The second is recognition timing. A ramp deal — $20,000 in year one, $25,000 in year two, $30,000 in year three for the same product — can’t be recognized as billed. The total contract value has to be spread evenly, because you’re delivering the same thing each year. So you recognize $25,000 annually regardless of what the invoice says. Year one generates an unbilled receivable. Year three generates deferred revenue. None of this is visible in Salesforce.

The portion of that total contract value not yet recognized is what’s known as Remaining Performance Obligation, or RPO. For a three-year ramp deal, RPO represents the revenue the business is committed to deliver but hasn’t yet earned. It’s a number that matters enormously to investors and auditors, and one that’s almost impossible to report accurately when ramp deals aren’t configured correctly in NetSuite from the start.

“The post-allocation financial picture that lives in NetSuite never makes its way back to Salesforce. In 99% of cases, only the most sophisticated organizations manage to close that gap — and they’ve had to build it themselves.”

So when the account manager goes to quote a swap, they’re working from the Salesforce number — what was originally booked. The actual remaining recognized value is a different number, sitting in NetSuite, accessible only to someone who knows where to look and has time to pull it. The gap between those two numbers is where margin goes to disappear. Sales closes the deal with the wrong credit. Finance inherits the mess: reconciling recognition patterns the sales rep never knew existed, after a deal that can no longer be unwound.

What Does It Really Cost When Ramps and Swaps Go Wrong?

The most immediate cost is margin leakage — and it’s more common than most finance teams realize. When a customer wants to swap products and the account manager calculates their credit as $25,000 because that’s what six months of a $50,000 contract looks like on paper, but the actual remaining recognized value is $15,000 because of how allocation was applied, the business has two choices. Get finance involved, slow the deal down, and try to explain to the customer why they’re getting less credit than expected. Or just give them the $25,000, close the deal, and eat the $10,000 difference. And it’s worth being clear about what’s actually happening here. The rep isn’t cutting corners — they’re working with the only number available to them. When systems aren’t architected to surface the real revenue position, over-crediting isn’t a training problem or a process failure. It’s the predictable outcome of asking people to make financial decisions without financial data. The rep trades margin for a fast quote. The customer gets their answer. The business absorbs a loss it didn’t know it was taking.

Most companies, most of the time, take the path of least resistance. They don’t have a process that makes the right answer easily available, so they default to the wrong one. Across PE-backed SaaS companies, it’s common to see 1 to 3 percent of ARR effectively donated this way each year — purely because swap credits are based on invoice math instead of recognized revenue. That’s not a rounding error.

“When a swap credit should be $15,000 but the sales rep can only see the invoiced number, companies are often cornered into issuing $25,000 and eating the $10,000 difference. It happens constantly. It’s not an edge case. It’s the hidden cost of two systems that don’t talk to each other.”

Beyond the immediate margin hit, the reporting consequences compound over time. When a customer’s recognized revenue drops mid-contract because a swap was executed at the wrong value, it shows up in the CFO’s monthly report as an unexplained ARR decrease. Weeks after the fact. Long after anyone could have done anything about it. Revenue forecasts drift. ARR reporting reflects bookings rather than recognized revenue. The gap between what the CRO thinks the business is doing and what the CFO knows it’s doing widens with every quarter.

For PE-backed companies, the stakes are higher still. Covenant compliance, investor reporting, and the credibility of the management team all depend on financial numbers that reconcile, including RPO, which investors increasingly scrutinize as a forward indicator of revenue health. When they don’t, the conversation shifts long before the board asks a question. Executives are defending numbers instead of discussing growth. The CRO and CFO are reconciling versions of reality instead of aligning on what’s next. By the time someone asks why bookings, billings, and revenue don’t line up, the credibility cost has already been paid.

Why Can’t Your Systems Handle Ramps and Swaps Automatically?

Because the revenue position that matters sits seven records deep in a system the sales team never touches. A deal moves through a chain: opportunity in Salesforce, order line in Salesforce, sales order in NetSuite, sales order line in NetSuite, revenue element, recognition plan, journal entries over time. By the time allocation has been applied and recognition has begun, the number that’s relevant for a swap or a ramp reconciliation is buried at the end of that chain. No existing tool has been built to traverse it automatically and send the answer back.

To get that number back to the person quoting the deal, someone has to manually bridge the gap. Call finance. Run a report. Export a spreadsheet. In organizations that have tried to build this themselves, it typically means a sales ops person who has a standing relationship with someone on the revenue team and knows to call before month-end when the queue is manageable. That’s not a process. That’s a workaround with a name badge.

The reason no one has solved this systematically is that it requires being native to both systems simultaneously — not integrated with them or synced to them on a schedule, but genuinely embedded in the data layer of both Salesforce and NetSuite. Most tools live on one side of that boundary. The revenue data lives on the other.

“Most quote-to-cash stacks stop caring about revenue the moment the invoice goes out. Everything after that gets handed to finance and forgotten. To take the final answer on that revenue element and tie it seven records back to the opportunity in Salesforce — and have a system send that answer back automatically — No one had built that yet. Until now. That’s what Continuous solved.”

How Does Continuous Solve the Ramps and Swaps Problem?

Continuous operates at the architectural boundary between Salesforce and NetSuite, embedded in both systems’ transaction and revenue layers, not bolted on through middleware or nightly syncs. It tracks the full lifecycle of a deal from opportunity through allocation, recognition, and journal entry, keeping the revenue position accurate in real time across both systems.

For swaps, that means the account manager sees the actual remaining recognized value before they build the quote. Not invoice math. Not a CPQ estimate. The number pulled directly from post-allocation accounting. Credits reflect financial reality, finance doesn’t get a phone call, and margin doesn’t quietly erode.

More importantly, the system enforces alignment. Revenue logic is embedded directly in the quoting flow, so sales cannot issue credits that exceed what has actually been earned. The gap between bookings and recognized value closes before it ever becomes a reporting problem.

For ramps, Continuous structures recognition correctly from the start and recalculates automatically when a contract changes. Allocation, deferred revenue, and billing schedules stay aligned without manual intervention. No surprises when a ramp year turns over, no reconciliation required when a customer modifies mid-term.

The same infrastructure governs amendments, credits, true-ups, and hybrid pricing models, absorbing commercial flexibility into system design rather than leaving finance to reconcile it after the fact.

On the reporting side, bookings, billings, and revenue reconcile structurally. The CRO and CFO operate from the same source of truth. ARR reflects recognized reality. Mid-contract changes surface in forecasts immediately, not six weeks later.

Continuous isn’t another billing tool. It’s embedded revenue infrastructure built to close the seven-record gap automatically — so ramps and swaps execute cleanly, accurately, and without hidden margin loss

Ready to learn more? See how Continuous ensures your revenue position is always accurate, in both systems, in real time.

Frequently Asked Questions (for FAQ section)

What are ramps and swaps in SaaS contracts?

A ramp is a multi-year contract structure where the price increases by a pre-negotiated amount each year. For example, a customer might pay $20,000 in year one, $25,000 in year two, and $30,000 in year three for the same product. A swap is a mid-contract product exchange where a customer returns the unused portion of an existing product and applies the remaining credit toward a different one. Both are common in B2B SaaS and both create significant complexity when it comes to revenue recognition and billing.

Why do ramps and swaps cause problems in NetSuite?

NetSuite applies revenue allocation and recognition rules that change the financial value of a product after a deal closes. A ramp deal that bills at different amounts each year must be recognized evenly across the contract term under ASC 606. A bundled deal with a free implementation must allocate value across each component based on standalone selling price. These adjustments happen entirely in NetSuite and are never reflected back in Salesforce, creating a disconnect between what sales knows and what finance knows.

What is the difference between bookings, billings, and revenue recognition?

Bookings are the total value of deals closed, typically recorded in your CRM on the day the contract is signed. Billings are the amounts actually invoiced to customers, which may follow a different schedule. Revenue recognition is the amount recorded as earned revenue under ASC 606, which depends on when and how value is delivered. For a ramp deal, all three numbers can be different in the same year: you might book $75,000, bill $20,000, and recognize $25,000. Understanding the difference is critical for accurate ARR reporting and financial forecasting.

How does revenue allocation affect swap credits?

When a deal includes multiple products or services, NetSuite allocates revenue across each component based on standalone selling price, regardless of how the invoice was structured. This means the recognized value of a product can be materially different from what appears on the quote. When a customer goes to swap that product, the credit they are owed should be based on the remaining recognized value, not the invoiced amount. If sales quotes the swap using the invoiced figure, the company may issue a larger credit than it has actually earned, resulting in direct margin leakage.

Why does ARR drop when a customer swaps products?

ARR can drop after a swap when the new ARR secured in the replacement product is less than the recognized ARR being retired from the original product. This often happens because the account manager is quoting based on the Salesforce booking value rather than the actual remaining recognized revenue position in NetSuite. The difference between those two numbers can be significant, and without visibility into the real revenue position, sales teams routinely offer more credit than the business has earned.

How can software companies automate ramps and swaps?

Automating ramps and swaps requires closing the data loop between your CRM and your ERP. The recognized revenue position for each product needs to flow back into Salesforce automatically so account managers have the right number before they quote. This means being native to both systems, tracking the full chain from opportunity through revenue element and recognition plan, and updating the revenue position in Salesforce as it changes over time. Continuous is built to do exactly this, eliminating the manual handoffs between sales and finance that slow deals down and introduce errors.

What is Remaining Performance Obligation and how do ramps affect it?

Remaining Performance Obligation, or RPO, is the total contract revenue a company is obligated to recognize in the future but has not yet earned. Under ASC 606, it represents the value of work still to be delivered on existing contracts. For ramp deals, RPO can be significant: a three-year ramp with $75,000 in total contract value has $50,000 in RPO at the end of year one. If ramp deals aren’t configured correctly in NetSuite — with even recognition across the full contract term — RPO will be understated, misrepresenting the company’s forward revenue position to investors, auditors, and the board.

You Don’t Need Another Billing System—You Need a Better Approach

Quadrant Graph with Question Mark

For RevOps, sales, and finance teams, this article explains why standalone billing systems fail at scale, and how Embedded Revenue Infrastructure offers a better approach.

TL;DR
- Standalone billing systems emerged to fill gaps when CRM and ERP lacked recurring revenue support.
- Modern pricing complexity exposes the limits of third-system billing architectures.
- Disconnected product catalogs and integrations create errors, delays, and revenue leakage.
- Continuous Embedded Revenue Infrastructure unifies CRM, ERP, and front-office systems into a single approach.

Recurring billing vendors promised simplicity. As businesses shifted toward what became known as the “Subscription Economy,” CRM, ERP, and customer-facing (front-office) systems lacked native support for recurring revenue models, creating operational gaps that gave rise to specialized vendors—”SaaS Recurring Billing“—to bridge the divide.

Today, customer expectations have evolved dramatically. Businesses now face greater complexity as customers demand flexible, personalized options for consuming and paying for products and services. This complexity significantly impacts front-office sales processes and drives downstream billing and reporting challenges.

While CRM and ERP platforms like Salesforce and NetSuite have responded to these evolving demands by continually innovating and enhancing their capabilities, the standalone billing vendors—both legacy providers and new entrants—have largely failed to keep pace. Instead of true innovation, these vendors have continued promoting a “third cloud” model that positions standalone platforms between CRM, ERP, and front-office systems. This outdated approach results in operational fragmentation and duplicated efforts, rather than genuine improvement.

Before exploring why standalone billing platforms inherently struggle, we must first clearly understand the essential pillars of every modern B2B organization’s revenue infrastructure:

CRM, ERP, and Front-Office Systems: Essential Pillars of Revenue Infrastructure
Effective revenue operations depend on three interconnected core platforms:

Infographic Showing CRM, ERP, and Front-Office Systems

CRM Systems: Excel in managing customer relationships, deal structuring, quoting, and flexible pricing management. Salesforce provides robust examples of integrated quoting and subscription management directly within CRM workflows.

ERP Systems: Focused on financial accuracy, compliance, revenue recognition, and accounts receivable. Platforms like NetSuite integrate comprehensive financial management aligned closely with accounting processes.

Customer/Front-Office Systems: Include platforms such as e-commerce, self-service portals, and internal product systems that manage customer engagement, subscriptions, credits, and prepayments, capturing the precise usage data critical for billing and monetization.

Additionally, specialized capabilities such as tax calculation engines, payment gateways, and specialized usage management systems can provide significant value if effectively connected to the core revenue stack. For companies already invested in specialized usage management solutions, leveraging these systems within a unified revenue infrastructure is crucial to ensure seamless interoperability and to avoid redundant or fragmented processes.

Together, these core systems should form a cohesive and unified revenue infrastructure. Effective monetization solutions must complement and enhance these systems—not duplicate or disrupt them.

Why Standalone Billing Platforms Fail to Deliver

Standalone billing platforms typically fall into three categories, each with inherent limitations and a critical shared flaw:

Quote-to-Revenue Platforms: While these newer entrants accurately recognize the importance of cohesive front-to-back-office collaboration, their strategy of replicating pricing, configuration, quoting, billing, revenue recognition, and collections capabilities within a single solution proves impractical at scale. Inevitably, they cannot match the depth and flexibility of dedicated CRM and ERP systems.

Legacy Subscription Management Solutions: Initially built for simple subscription models, these systems struggle significantly with complex usage-based or hybrid monetization strategies. Attempting to address complexity, many legacy vendors developed their own CPQ tools around their proprietary billing catalogs, which are inherently limited compared to modern CPQ systems.

Usage-Based Billing Platforms: These specialized platforms excel at usage rating but struggle to clearly define how their capabilities seamlessly integrate into broader CRM, ERP, and front-office ecosystems, often resulting in redundant configurations and operational friction.

The fundamental flaw shared by these SaaS Recurring Billers is their reliance on multiple disconnected product catalogs. Defining sales rules in CRM and separately redefining them in billing systems inevitably introduces complexity, data discrepancies, and costly integration challenges.

Infographic Showing SaaS Recurring Billing Vendor Challenges

Symptoms Your Revenue Infrastructure Is Breaking Down

How do you know if your revenue infrastructure is failing to support your business effectively? Look for these recognizable symptoms:

  • Forced Manual Handoffs: Sales and finance teams repeatedly re-enter or manually adjust data because your sales and billing systems don’t talk to each other efficiently.
  • Slow Pricing and Packaging Changes: Launching new pricing strategies or monetization models requires extensive IT projects and lengthy configurations.
  • Billing Inaccuracies and Revenue Leakage: Persistent discrepancies between quoted prices and billed amounts cause customer frustration and lost revenue.
  • Internal Team Frustration: Sales, finance, and revenue operations teams are misaligned, each blaming the other for process inefficiencies and delays.
  • Engineering and IT Overload: Significant resources are spent maintaining fragile custom integrations and resolving data conflicts rather than focusing on strategic initiatives.

These symptoms aren’t just operational headaches—they’re clear indicators that your revenue infrastructure needs immediate attention.businesses to build complex integrations, making it harder to achieve a seamless sales-to-finance workflow.

The Future: Introducing Embedded Revenue Infrastructure

Infographic Showing Continuous Revenue Infrastructure and a Seamless Workflow

The true issue is not any single billing solution but the outdated concept of a standalone “third cloud.” Originally necessary when CRM, ERP, and front-office systems were immature, this approach now struggles under modern monetization demands.

The future of revenue management demands Embedded Revenue Infrastructure—an innovative model that integrates advanced pricing, usage tracking, billing, and revenue logic directly into existing CRM, ERP, and front-office systems. This approach eliminates redundant catalogs and complex integrations, creating a unified, agile, and scalable foundation for revenue operations.

In our next blog, we’ll dive deeper into Embedded Revenue Infrastructure, explore its transformative potential, and show precisely how it addresses these critical operational challenges.

Ready to simplify your sales and finance processes?

Stop juggling fragmented systems and costly integrations. At Continuous, we unify your sales and finance workflows by building on the trusted CRM and ERP platforms you already use.

Request your free Revenue Operations Assessment from Continuous and get expert insights tailored specifically to your business—no cost, no commitment. Simply fill out this quick form, and one of our experts will reach out with your assessment survey.

Rethinking the Recurring Billing Status Quo: Why Analyst Reports Highlight a Broken Market

Quadrant Graph with Question Mark

Analyst reports from Gartner and Forrester expose a deeper issue in recurring billing. This article is for RevOps, Finance, and IT leaders evaluating billing platforms who want to understand why standalone billing systems create complexity, and what a better model looks like.

TL;DR
- Analyst reports reveal a recurring billing market built around standalone billing systems.
- These platforms attempt to own sales, billing, and finance workflows that already belong in CRM and ERP.
- The result is fragmented data, costly integrations, and rigid architectures that slow change.
- Recurring billing works best when embedded directly into systems like Salesforce and NetSuite.
- Continuous challenges the standalone billing model by extending CRM and ERP instead of replacing them.

On August 6, 2024, Gartner released their latest Magic Quadrant for Recurring Billing Applications followed by Forrester’s The Recurring Billing Solutions Landscape, Q3 2024 on September 3, 2024. These reports assess a competitive landscape that has been evolving for over a decade, evaluating vendors based on their ability to manage the entire sales-to-finance process for recurring billing.

While these reports are valuable, they also reveal a deeper problem in the industry—a problem rooted in how standalone billing systems approach the recurring billing challenge. At Continuous, we believe the way the market has evolved has fundamentally misunderstood the nature of the recurring billing problem, making it difficult for analysts to cover accurately and even more painful for customers to select the right solutions.

Both the Gartner and Forrester reports rank vendors based on their ability to handle the entire recurring billing lifecycle, which includes tasks such as:

Sales Process and Quoting:
Creating flexible pricing models and accurate quotes within the sales cycle, ensuring they align seamlessly with both CRM and billing systems.

Contracting:
Managing the transition from quoting to contracts, including drafting, signing, and handling amendments or renewals, while integrating pricing and terms from the sales process.

Service Provisioning:
Setting up and activating services according to contract terms, tracking usage in real-time to ensure accurate billing.

Usage Data Collection and Rating:
Capturing, mediating, and rating usage data in real-time, applying pricing rules to ensure accurate and scalable billing for consumption-based models.

Billing and Invoice Generation:
Consolidating one time, periodic and usage charges into detailed invoices, ensuring timely delivery to customers via their preferred channels.

Payment Processing:
Facilitating payment collection, managing recurring payments, and ensuring accurate reconciliation with financial systems.

Revenue Recognition and Financial Reporting:
Ensuring compliance with accounting standards by accurately recognizing revenue and providing detailed financial reports that integrate with the ERP system.

These tasks encompass a wide range of functions traditionally handled by CRM (Sales) and ERP (Finance) platforms. However, over the past decade, specialized billing vendors have emerged to address gaps in these systems. Their solution? Introduce a “billing system of record” – a third platform that sits between CRM and ERP to manage these critical processes. This shift has created a new category of software, one that analysts like Gartner, Forrester, IDC, and others are now tasked with evaluating.

The Rise of Standalone Billing Systems: A New Category Emerges

Around 2010, a belief took hold that CRM and ERP vendors couldn’t handle the increasing complexity of billing as companies shifted from traditional perpetual license models to subscription billing models. In response, a range of specialized billing systems began emerging, offering solutions to support this new “Subscription Economy”.

By 2017, this new category of standalone billing systems had matured enough to receive formal analyst coverage, leading to the release of reports like the Gartner Magic Quadrant and Forrester Wave. These vendors promised to simplify recurring billing by offering a third-party solution that could manage the billing lifecycle independently. This trend accelerated as consumption and prepaid credit models gained popularity, leading to the crowded market landscape we see today.

But here’s the issue: billing is not, and never should be, a standalone process. It’s intertwined with sales, finance, and customer management. When billing is siloed into a separate platform, businesses are forced to build complex integrations, juggle multiple systems, and deal with costly maintenance—problems that CRM and ERP systems were originally designed to solve.

What These Reports Reveal: Complexity, Not Simplicity

The criteria used by Gartner and Forrester to evaluate vendors include tasks that traditionally belong within the domains of CRM and ERP systems. However, instead of enhancing these core systems, standalone billing vendors have introduced an unnecessary third layer of complexity.

Consider the following:

  • Quote Creation and Negotiation are native functions of CRM systems, where sales teams manage customer interactions and quote data from all channels should be stored.
  • Contract Drafting and Management should flow naturally from CRM to ERP, enabling seamless financial reporting.
  • Invoice Creation and Payment Processing are core functions of billing that should reside within the ERP or CRM system, where financial and sales data is already managed.

By positioning a third-party billing system as essential, standalone vendors have shifted what should be natural extensions of CRM and ERP into fragmented processes. This fragmentation forces businesses to build complex integrations, making it harder to achieve a seamless sales-to-finance workflow.

The Problem with Standalone Billing Systems

At Continuous, we believe the current approach taken by standalone billing vendors is fundamentally flawed. Instead of simplifying processes, these vendors create friction by placing themselves as overlapping solutions with the CRM and ERP systems they are also dependent on. This introduces costly, cumbersome integrations that are difficult to maintain—particularly as pricing and packaging models evolve.

There’s no inherent reason why traditional sales and financial processes should be managed by a separate system when sales and finance teams have already invested in systems like Salesforce and NetSuite. Standalone billing vendors want businesses to believe they must control these processes, but the reality is that doing so makes their systems “stickier” by requiring complex customizations and significant services investments. The end result for customers of these vendors are deployments that are:

  • Expensive to integrate: Building and maintaining integrations between CRM, ERP, and standalone billing systems often requires costly services and custom work.
  • Rigid and limiting: Once integrations are built, they become rigid, making it difficult for businesses to adapt to new pricing models or market changes without extensive rework.
  • Manual and error-prone: Despite these integrations, many billing processes still require manual intervention, leading to inefficiencies and potential errors in financial reporting and customer invoicing.

This is why the current market is so difficult for analysts to cover: the premise of a standalone billing system is inherently flawed. The criteria that Gartner and Forrester use to evaluate these vendors encompass functions that should naturally belong in core CRM and ERP systems. However, standalone vendors pull these critical processes into a third cloud, which struggles to work effectively alongside CRM or ERP solutions.

The Continuous Approach: Back to Common Sense

At Continuous, we challenge this status quo. We believe that the best way to solve the recurring billing problem is to go back to what was previously common sense: there should not be a third cloud in between CRM and ERP.

Instead, we advocate for enhancing the core applications that B2B companies already rely on—CRM for sales and ERP for finance—and supplementing them with a powerful calculation engine that integrates with customers’ internal platforms. By doing this, we enable a truly unified quote-to-consumption process that is:

  • Easier to maintain.
  • More flexible as pricing and packaging needs evolve.
  • Less expensive to deploy, reducing both software license and integration costs.

Conclusion: Challenging the Status Quo

The release of the Gartner Magic Quadrant and Forrester Wave reports highlights how deeply entrenched the idea of standalone billing systems has become. But as businesses increasingly adopt complex pricing models and usage-based billing, the limitations of these systems become more apparent.

At Continuous, we believe there’s a better way—one that embeds billing awareness directly into the tools businesses use every day, rather than introducing another layer of complexity. By rethinking how billing should work, we can simplify the process for businesses and create a more efficient, flexible future for recurring billing.

Ready to simplify your sales and finance processes?

Stop juggling fragmented systems and costly integrations. At Continuous, we unify your sales and finance workflows by building on the trusted CRM and ERP platforms you already use.

If you’re ready to move beyond the limitations of standalone billing systems, let’s talk. Explore how Continuous can streamline your quote-to-cash process and help your business scale with confidence. Find out more today at: Product | Continuous Technologies.

Should You Nix Time-Based Trials? If You Have a Usage-Based Product, the Answer is YES!!

Free Trial graphic

This article is for product, growth, and revenue leaders launching usage-based products. It explains why time-based trials underperform and how usage-based trials improve conversion, pricing confidence, and customer experience.

TL;DR
- Time-based trials often expire before users experience real value.
- Usage-based trials align better with consumption-priced products.
- Customers learn the metric and can forecast real production needs.
- Trial usage data provides early insight into feature adoption and pricing fit.
- Usage-based trials control infrastructure cost while improving customer experience.

If Henry Ford had said to customers, “Here are the keys to your brand new car, go out and take a spin” would he have sold more cars? 

Of course he would.

And this is why so many companies offer free trials today.

Free trials can be a great way to provide prospective users with hands-on experience. Because, let’s face it, most buyers are risk averse. We want to know first-hand what we are getting for our money.

For companies, trials also help provide valuable feedback on target buyers, pricing, key use cases, what’s working and where users are falling down. And they hold the promise of landing new customers faster, without a lot of hand-holding and associated costs.

But what’s the best way to go about conducting a trial? After all-we know that SaaS trial conversion rates are incredibly low with 66% of Saas vendors reporting Free Trial conversion rates of 25% or less.

Well, for one, organizations need to make sure their service or product is ready for a trial. And by ready, I mean that it is something that customers can easily get, understand, use and see value from.

But another, perhaps equally important thing companies can do to drive more attach to their trials is to look at how they are setting these up.

Typically most companies look at time-based trials and usage-based trials. Time-based trials allow you to download and use a product or service for a fixed period of time. Usage-based trials don’t restrict your time, but they do put a limit around how much of the product you can use.

There are pros and cons to each approach, but if you are a company with a product or service that is being sold on a consumption-basis, you should seriously nix going with time-based trials and opt for usage-based trials instead.

Here are four reasons why.

  1. Time-based trials rarely work- How many times have you downloaded a time-based trial with the best of intentions and found you just can’t get to use it in the time allotted? This is particularly true if the trial requires any set up, 3rd party integrations or back-end approvals with other teams or users.Time-based trials are meant to create a sense of urgency. But typically that urgency is only felt by the company offering the trial. The person using it is usually on a completely different timeline.So, they have two choices–they can let the trial lapse-which many do. Or they can renew again and again for as long as it takes. But in both cases, your company is no closer to making a sale or getting the feedback they really need.
  2. Usage-based trials provide an easier transition for customers to move from trial to production for usage-based products- If you are planning on putting usage-based pricing in place for your products or services,then, usage-based trials will make it easier for your customers to understand and predict how much of your product or service they will likely need when they move to production. It will also get them more familiar with your metric and will help them put a business case together to support moving to the next phase.
  3. Usage-based trials can serve as an early indicator for the success of a new product or consumption-based  pricing model– Curious about what features are being used? Usage-based trials can give you real-time visibility into which capabilities or features are most widely adopted. These trials can also be fantastic for companies who are introducing consumption-based pricing into the market for the first time-especially if they are using a brand new metric.

For example, one organization wanted to launch a new data access governance product into the market. They thought going with column-based pricing would be the optimal approach. Unfortunately they had no data on how many columns their customers would need and if this type of pricing would fly. Introducing a usage-based trial gave them a window into usage and helped them understand where their customers were getting hung up and whether or not their new pricing model would fly. 

  1. Usage-based trials allow you to minimize costs and maximize customer experience– If you have a new product or service with metered pricing, you likely have to account for some costs on the backend. These infrastructure and hosting costs can quickly add up and will likely be difficult to predict with time-based trials. Going with usage-based trials helps curb costs and ensures organizations can predictably plan and support customers to ensure they have the best possible experience. And as PwC points out, experience is everything. In fact, if you focus on customer experience, you can expect to get a 16% price premium from your customers.Usage-based pricing makes this easier. It ensures companies have the right back-end infrastructure in place to support customers with the best possible experience throughout their trial. 

In the End

Trials are a great way to bring new customers into the fold and secure feedback on products, pricing and services. But as the old adage goes,just because you build it, doesn’t mean customers will come (or use your product). Making sure your trial is is easy to use and adopt is key to driving adoption and conversion. But so too is structuring your trial for success. And this often means-throwing time-based trials out the window in favor of usage-based trials–especially when it comes to usage-based pricing and products.

Looking for an easy way to run usage-based trials with your customers? Be sure to check out Continuous. Continuous is the only solution designed to help you launch and grow usage consumption pricing models on the Salesforce platform. Find out more today at: Product | Continuous Technologies.