$ubscription management in SaaS Sales
Next up, subscription billing services! While an integrated marketing, CRM, and analytics platform would help enable customers to successfully use the service, the subscription billing piece is critical for easy on-board, renewal, and upgrades. I will provide some general info on subscription billing and how it applies to the SaaS sales front.
Billing for a subscription service basically comes down to a make, buy or ‘assemble’ decision with four main components. Different vendors may provide all components or partner will complementary services:
Payment Gateway: the service that performs the actual billing of a customers credit card
Merchant Account: an account into which credit card payments are initially deposited, and back out of which any chargebacks are taken; the merchant account is separate to the company’s bank account (which in turn can be referred to as the ‘settlement account’)
Payment Method Details Collection: the service that collects and stores credit card details and uses them to initiate charges via the payment gateway. As this component handles and stores payment method details it must be PCI Compliant.
Recurring Billing business logic: the code or service that handles subscriptions; the main task of which is to trigger the payment gateway to make charges every billing period. Usually also responsible for handling payment failures, reminder emails, payment holidays, cancellations etc.
The different subscription options/plans you offer, is arguably, one of the most important aspects of your business model. Positioning and pricing will shape the sales process and how you build out your team. The most successful implementations I have worked with involved low cost product where customers could afford to pay recurring subscription with CC, and also low maintenance, meaning few levers which influence pricing.
Here are some questions to consider. I’ve ran into issues with all of these points for one reason or another, so it’s important to understand your subscription plans and exceptions:
are there limits or constraints associated with subscriptions (such as number of users, or other usage metric) that need enforcing in the code?
is it even worth enforcing these limits to start with?
will your subscriptions be on a 1:1 basis, or will you also be dealing with MSPs who’ll want to manage their own subscriptions of your service?
what is the impact on the UI for subscriptions of different levels? e.g. do you hide unavailable options or show them but with an up-selling message when clicked?
subscription period: annual pricing as well as or instead of monthly?
special deals for charities, open-source projects, academic institutions?
is the product purely subscription based, or are there add-ons outside of the recurring charges?
Ideally, your Subscription Billing Platform would manage the entire subscriber lifecycle for all recurring revenue models as a company grows and expands its business. Because your go-to-market strategy will inevitably shift - with ongoing price and plan changes to help scale your business - companies need the flexibility to adjust their monetization strategies as often and aggressively as they see fit. A subscription billing service will bring the front and back office together to effectively manage the complete subscriber lifecycle, and offer seamless customer experience throughout the customer lifecycle. See how Aria and Zuora does it.
One of the services I sold had delivered the product through SaaS delivery model, with a 30 day trial process. A customer would go to our website, sign up for a free 30 day trial, and then choose to upgrade before the trial ends or let the account expire. The customer may pay via credit card through a customer facing CC portal, and (s)he may manage the account subscriptions via the accounts tab. The accounts tab gives visibility into how much usage per pricing levers (e.g users, projects, tools), current subscription, billing cycle and different plans for upgrading/downgrading. The customer was notified whenever usage threshold was triggered, and the sales, marketing, support, and finance folks were also notified for follow up.
With a well managed and implemented integration platform, you will have more visibility into your customer base, more control over how you manage their business and the added ability to quickly adapt to changing market conditions. You can shorten the time to bring new products and services to market, optimizes your plan and pricing strategy and maximizes revenue and customer loyalty.
Here’s a few scenarios, in which all activity monitoring and notifications are automated from the automated sales platform:
Customer is on a plan which allows 5 users, 5 projects. If a customer already has 5 users but tries to add another user, the customer receives an error notification & is prompted to upgrade for the next tier. The account manager receives a notification about the customer attempting to add another user, and follows up for an upgrade as they are notified or around renewal dates.
Customer is on the same plan, and as the customer is approaching user/project limitations, e.g 4 users 4 projects, the customer receives notifications about approaching usage limit. The customer is prompted to upgrade, and the account manager follows up.
Customer has not set up any users or projects—the customer is sent resources to enable usage, and the account manager reaches out for assistance. This “ideal usage” model can be used to monitor and enable customers in a trial or freemium model.
I’ve had experience with Zuora. Email me if you want to get into nitty, gritty implementation details or problem solving. I’d be interested to hear your feedback and ways you’re using these tools: Zuora, Vindicia, Chargebee, Chikpea, Monexa, Chargify, Recurly, Evant, Aria, Saasy.
Some other reads for evaluating online payments services: