In the world of pricing, I have found that people tend to use the terms “volume pricing” and “tiered pricing” interchangeably. In the Zuora world, they have very specific meanings. The differences are subtle, but have a financial impact. So it’s important you understand what they both mean and make the right choices when setting up your product catalog.
I find that most things like this are best illustrated by example. Below, I will show both Volume and Tiered pricing setup for an item. The numbers on each line are identical, but the calculations arrive at different numbers.
Let’s assume a customer places an order of a quantity of 35 in both cases.
Volume Pricing:
01-10 = 100 per unit
11-20 = 90 per unit
21-30 = 80 per unit
31+ = 70 per unit
Cost Breakdown:
All units cost 70 each.
Calculation:
Total cost = 35 x 70 = 2450
Tiered Pricing:
01-10 = 100 per unit
11-20 = 90 per unit
21-30 = 80 per unit
31+ = 70 per unit
Cost Breakdown:
First 10 units cost 100 each
Second 10 units cost 90 each
Third 10 units cost 80 each
Last 5 units cost 70 each
Calculation:
Total cost = (10 x 100) + (10 x 90) + (10 x 80) + (5 x 70) = 3050
As the examples above show, Volume and Tiered pricing are not always the same, especially in the Zuora world.
Introduction:
Are you preparing to move to another subscription billing and finance platform for your subscription business?
Here’s a question or two: do you know how your business gives sales discount to your customers? I mean really know? If you were asked to define the rules, would you be able to do so precisely? Is it possible your sales people are selling some goods or services at a loss in order to land a deal? Is your discounting “system” open to abuse? Are some customers benefitting from excessive discounts, based on old deals, to the detriment of the overall business?
In short, are you in control? Can you run a report to get an accurate, current picture of your discount situation?
You know that you certainly should have full control and visibility of this aspect of your selling. In reality though, your IT systems may very well be based on legacy code, with lots of history and undocumented revisions; with many twists and turns, rules and exceptions, some old, some newer; possibly more which only some of your IT or Sales people are aware of; maybe some that are no longer part of your business rules but are still active in your code base.
System Replacement:
What if you need to implement a new selling or billing system: how would you fare out? Would the transition be painless or would you likely incur a substantial cost to analyse or reverse-engineer your discount rules?
So far I’ve asked a good many questions; the aim is to give you an insight into the difficulties posed by those helping you with the transition from the old to the new. And, perhaps, to make you think about a neglected area of your business that is sitting in a mystical black box. You can use the lists and notes below as a checklist to help uncover the hidden depths of your discount business rules; rules that will be used by implementers/analysts/techies when you make that transition to a new system.
Types of discount:
The list below indicates several types of discount that I and my colleagues typically encounter during client discovery sessions:
Customer discount – based on special terms, often a percentage discount, applied “across the board”
Agent discount – given to entities who purchase on behalf of their client companies
Quantity discount – applied based on volume purchases; In the Zuora world, there are two flavours of this, Tiered and Volume pricing
Vouchers – offer codes, unique or public voucher codes; time limited; one per customer/order
Special Offer discounts – product introductions, promotions, final remaining stock, loss leaders, marked-down stock, etc.
Discretionary discounts (sales) – for example, a salesperson saying “thats 1050, let’s make it an even 1000”; another less common use case would be where discretionary discounts are given to effectively pro-rate discount for partial subscription periods e.g. “we normally charge for the full year regardless of when you start but we’ll make an exception this time”
Legacy discounts – discounts that were negotiated a long time ago, that “linger” and may need re-alignment or re-negotiation
Region discount – discount applicable to a geographical region or market
Package or Bundle discount – a discount may be applicable when a particular set or combination of products are bought
Complaint – perhaps you offer discounts to customers to “keep them sweet” when they encounter poor product or service quality; sometimes known as a rebate
Group – discounts applicable by virtue of belonging to a group of companies, or having a particular parent company
Which of the above apply to your business? Do you use other discount types not listed above?
Now ask yourself, in relation to all of these: do you use percentages or fixed amounts? Both? Either? What are the specific rules? Build examples in Excel or on a whiteboard to help deduce the rules.
Particularly in the case of discounts amounts, when applied to a specific customer order, how do you decide on apportionment of discount values between products or distinct line items on the order?
Your rules may start to look complex now but we’re not finished yet!
Considerations and questions:
Once you have taken the initial steps to enumerate your discount types, the next step is to understand how they all fit together. At some point, it may be necessary to define a formal algorithm for an all-in-one discount calculation. The following aspects need to be considered:
Sequence – usually, the sequence in which discounts are calculated is important; mathematically, the calculation may not be commutative
Dependency – in order to qualify for discount A, do you need to qualify for discount B?
Mutual-exclusivity – to qualify for discount A, you must not already qualify for discount B; OR if you qualify for discount X, you cannot have discount Y
Compounded or additive – if discount A is 10% and discount B is 15%, does this add up to 25% discount? Or is it 23.5%? If you need to know how I arrived at that last figure, see the example at the bottom of this article **.
Thresholds – what happens if you give someone a discount worth 500, but they order 200 worth of goods or services? Or if the sum of their discount percentages exceeds 100%? Rules to cover these situations should be considered as part of your algorithm.
Approvals:
In many cases, there is an approval step that must happen in order to allow the order to progress to billing, fulfilment or whatever the next stage in your sales process. Firstly, you should identify entry criteria for approval: there may be more than one set of entry criteria. For example: “if discretionary discount exceeds 10% on any line item, use Approval Process X; if any line item has 100% discount applied, use Approval Process Y”. And so on.
Each approval process has a defined set of steps and may have more than one possible path through it. The ultimate outcome will be either an Approved status or a Rejected status. Here are some questions to help drive out your approval rules, and you should consider these questions in light of each of your defined approval processes:
Who should approve?
Should more than one person approve?
Does approval require unanimous approval from two or more people?
Are the approvers specific people or specific roles? The latter is preferable; consider the absence of key persons.
What thresholds apply?
What conditions apply?
Can you flowchart your approval process(es)?
Downstream Systems – Additional Questions:
So far we have only thought about the mathematical rules around the discount calculation. You need to also consider the bigger picture, in the context of the full implementation and how discounts play into the full ordering business process.
How do your discounts appear on invoices and quotations? Are your customers aware of the discounts they have received or is everything rolled into a derived line total?
How do you report discounts? Do you have the granularity you require for all discount types? Are these reports accurate and always up to date?
How do you control and audit discounts? Is the business operating within business constraints without tying the hands of your sales staff?
Where, in the life-cycle of the customer sales order, does the discount calculation belong? How and when are discounts calculated? Is the calculation automated or manual? what triggers a discount calculation? Do your users have the benefit of being able to view “what if” scenarios?
If the order changes, what effect does it have on the discount calculation? Is it a repeatable process?
Do you supply some products or services to which discounts do not apply, ever? Top-selling items, low-margin products and fixed costs such as shipping may not qualify for discounts.
How do you test and verify your discount calculation process? During the development phase? After it’s in production and affecting your business? Can you see the full audit trail for a complex discount calculation? Read my post on Auditable Programming for more details on what I mean.
To what type of charges do discounts apply?
One time charges? Examples are: setup fees; hardware provision at the start of a service provision period (mobile phones, for example); non-refundable deposits.
Recurring charges: and for how long? X charge periods or indefinitely?
Usage charges: for pay-as-you-go or included unit selling scenarios.
Conclusions: Why Would You Bother To Explore The Above?
That’s a lot to take in. It begs the question: why would I spend time and money to analyse my discount rules?
To understand how your business operates more completely
To understand how your discounts are (or are not) audited
To prepare for system change
To plan how to improve your business by simplifying processes and rules
To understand how you can have better visibility into your discounting strategy
To quantify whether it makes sense to retire some of your discount baggage; reduce your build, testing and maintenance costs as a result
When building a new system, understanding when the system will work as standard and when it needs customisation
Some final words of advice: when you’re moving house, you don’t have to take all your old furniture with you. Prepare your business for system transformation by making it leaner so that you can adopt new technology more easily.
** Example: Calculation of compound discount; think of it like this: “you can have 15% discount on the price that was already discounted by 10%”. In our example, discount A = 10%, discount B = 15%.
Discount A = 90% of the list price = 0.9 times list price Discount B = 85% of the list price = 0.85 times list price 0.9 x 0.85 = 0.765 times list price = 76.5% of list price = 23.5% discount
From time to time, you will come across a scenario where one structure will need to be copied to another, and there’s no option but to do it “the hard way”, as in the example below. But do you want it to look good?
Here, I’m going to take a look at the condition part of the if statement. In particular, how best to write a complex condition to allow for readability and easy code maintenance. Sometimes even just a small number of ANDs and ORs can be easy to write but difficult to untangle later. Add in some brackets for changes in operator priority and the picture becomes even worse. I will refrain from filling up this post with words because I think the example below will provide most of the colour and information I’m trying to impart on the topic.
When you substitute the conditions for real-world variables, function/method calls or complex structure sub-fields, the results can be less than legible. But, apply a little indentation and split your conditions up and you suddenly have some clarity.
One of the new phrases you will have heard lately is the “Subscription Economy”. If you haven’t, where have you been? You’re kidding, of course you have. Certainly, one of the main proponents of the whole movement is the California-based Zuora; their cloud-based subscription billing system is leading the way in the industry and they’ve landed some prestigious and lucrative accounts in their short lifetime.
What they have also succeeded in doing is placing a spotlight on the area of subscription management; they’ve pointed a finger at the inadequacies of competitive products and helped to pull a new industry along in its wake. From a Salesforce.com heritage, they’ve designed a product that manages all the nuances of selling your product, allowing your customers to add more products; to downgrade or upgrade their subscription to, say, the Platinum or Bronze edition; or to cancel their subscription whether still in or out of contract; and for them to be invoiced correctly, according to your pricing and billing rules, and all the complexities that go with charging for partial months (or proration, as it is termed by Zuora).
Two industry verticals that seem like a ready fit for this type of product are Telecoms and Media (of course, there are many more); typically, their products are sold on a continual basis; often, there is a regular product “delivery”, coupled with a regular payment. The shifting patterns of product offerings and industry change mean that businesses operating in these circles need to be able to move rapidly when launching new products; and it’s not unusual for many different versions of a product to be made available through the various sales channels.
The Reality Of Accounting
But this flexibility brings new challenges. Many CFOs today come from a static environment where accounting practices and rules have not changed, literally, in decades. OK, they’re using accounting software to carry out bookkeeping exercises and to generate management and statutory accounts. The tools have changed but the rules and methods have not. But, what we tend to see quite often with our customers, is that a certain perspective on accounting systems accompanies this. And when we analyse the requirements of our customers, what they want can be boiled down to something simple: the porting of their old systems to new systems. Sadly, this brings baggage with it: significant cost, long project timescales and ultimately a huge amount of customisation (often tying the customer to a fixed version of the packaged software underpinning their new system). What is lost is considerable:
system agility
the ability to take advantage of new software releases
the ability to move forward with a small software maintenance footprint
In short, you may end up with a stifled product feature set due to excessive customisation
How can we address these problems? When you move house, you don’t take along all of your accumulated tat and clutter; you use the opportunity to dump the stuff you don’t need. Therefore, what businesses need when implementing new systems is a sort of “mental skip”. Thought processes and indeed business processes often need to be realigned to take advantage of the new technologies on offer; otherwise, what’s the point? How you handle such change is the subject of another discussion in its own right, and I’m not going there today. But the point remains.
An Example
I would like to look at specifics now: let’s say your business sends invoices to its customers regularly, but sometimes it has to issue credit notes; sending the wrong product, or it arrives late, or is damaged; someone cancelling due to poor service delivery; there are many reasons why you might issue a credit (with an accompanying refund in some cases). In business jargon, there are many use cases. Under a traditional accounting system you would initiate the issuance of the credit (and possible refund) through your standard process: there would be some validation, probably an approval process, then you would need to create the transaction in the accounting system, along with the necessary paperwork and reversal of any fulfilment aspects of the supply.
The Finance department would usually have ownership of the financial aspect of the transaction; and this impinges greatly on the process, regardless of the solution. I don’t mean that as a negative, it’s the necessary reality. They usually have audit and control responsibility and they rightly take that very seriously.
But then they start to impose the “old” process conditions on the “new” system; for example, only a full credit will be acceptable, and a new invoice will be issued to cover the “delta” i.e. what the customer actually bought vs. what was returned/refunded. Perhaps they need a 1:1 match between the credit and the original invoice.
The problem with this is that, in a Zuora landscape (or, more precisely, a subscription landscape), it doesn’t work. Not without customisation. Zuora works on the basic premise that you start with version 1 of the sale (or subscription, really). Any change after that will give you version 2, version 3, ad infinitum. It uses its own mechanism, known as an Amendment, to manage changes.
Why Does This Problem Occur?
Now that we have a specific example, we can start to look at why this is the case. I have some theories, and I think they’re correct. I’ve seen it with several customers.
People use the word “subscription” but haven’t thought about what the word really means
In a new systems environment, new tools, metrics and controls will apply
We cannot lose sight of the fact that the accountant’s view of the system (and his requirements) are still valid and important; but when we port old systems to new systems blindly, ultimately it is the solution that is flawed. It just doesn’t match the reality of subscription management.
I will address the three points above in turn.
1. What Is A Subscription?
It’s an interesting question, and one that I think has an easy answer: “A Subscription is a sale where there is a recurring element to the provision of (and, usually, the payment for) goods or services.”
Contrast this with transaction-based selling, where you sell once, the customer pays once, and the process is complete. And ask yourself the question: are you thinkingSubscription but practicingTransaction? Is there a finite start and end date associated with the deals you are labelling as Subscriptions? If so, I would dare to venture that this is not a true Subscription. Perhaps you have to go through a defined renewal process to re-engage with the client, and to effectively re-sell to them.
2. What New Tools, Metrics and Controls Will Apply?
The answer to this is a little more complex. But once you have gotten your head around the first question and resolved it internally, it starts to become clearer. And your business may have to adapt to a better, more efficient way of carrying out the business of selling so that it can take advantage of new tools and build new measurement metrics. The controls will follow once the process is optimal.
There are several components that go to make up the preferred solution. But they will always have the following characteristics:
Little or no customisation
A good product fit
An optimal business process
All of the above are ideals, and are usually hard to achieve fully. But we should always strive towards them. They are laudable aims for any new systems implementation project; they usually yield faster returns, better adoption and enhanced product trust. There’s a bigger discussion to be had around topics such as process mapping, business process re-engineering, change management and operational culture, but I cannot do them justice here.
The Nub, Gist And Central Point
By now, you may be inwardly urging me to make my point. And rightly so. It is this:
In a subscription-based Zuora systems landscape, you can make best use of their product by re-thinking how you sell and account for sales. Rather than a collection of discrete transactions, I will coin this phrase: the Subscription Continuum. Your business interacts with your customers on a regular basis and your transactions are regular also. But there’s another point to consider: the customer may be engaged in several subscription “streams” with you; if they are buying several products from you, they may have several subscriptions running in parallel. They all form part of a continuum of transactions, in fact real subscriptions. This mindset change may appear trivial, but it is huge.
More to this point, let’s take the case where a customer has purchased several subscriptions from you. Assume that Product A, Service B and Product C were bought at different times and their monthly payments may or may not have been aligned to the same date every month, depending on your business practices. You don’t really want to issue three invoices per month to the same customer, do you? Perhaps you do, but you have that flexibility too. Maybe the customer upgrades from Service B Basic to Service B Gold, so he has to pay a little extra every month, but for his first month he upgraded mid-month, so you need to calculate a pro-rated additional amount to charge.
What I’m trying to demonstrate here is the level of complexity possible in the subscription world. And I’ve only really touched on the possibilities. You don’t really want to get into the position of having to re-engineer your software to cope with these possibilities. It’s a complex calculation when you get into the intricate workings of a Rating and Billing Engine (RBE) such as Zuora. The keys are
education (in how Zuora works out of the box)
simplicity (in your product offerings, payment options, pricing)
flexibility (re-thinking how you manage your sales accounting)
This article deals with the humble if/then/else statement, specifically the executable part of the statement. As before, I’m writing in Apex code, so there may be minimal syntactical differences between this and similar, related languages e.g. C & variants, Java, etc.
We can start with a simple, common binary use of the if statement:
if (a == b) runSomething();
else runSomethingElse();
Figure 1, above, is a simple case of “if a = b then run something, otherwise run something else“. It looks perfectly fine.
if (a == b)
runSomething();
else
runSomethingElse();
Figure 2, above, is almost identical to Figure 1 except that the executable part of the if and else clauses are on separate lines and indented. A little better. More readable, perhaps, and functionally identical.
if (a == b) {runSomething(); } else { runSomeThingElse(); }
Figure 3, above, has expanded on Figure 1. The addition of block braces around the executable sections serve to demarcate the runnable parts of the code.
if (a == b) {runSomething(); andSomethingElse(); } else { runSomeThingElse(); andRunAFourthThing(); }
Figure 4, above, is an example of where the programmer has added some extra method calls into the two executable blocks. This would not be possible for Figure 1 and Figure 2 above without the addition of braces.
if (a == b) {
runSomething();
}
else {
runSomethingElse();
}
Figure 5, above, is where we FINALLY come to the version that I’m happy with. The if and else clauses are on their own lines, block braces surround the executable sections of both clauses and indentation completes the picture.
if (a == b) {
runSomething();
andRunSomethingElse();
}
else {
runSomethingElse();
andRunAFourthThing();
}
Figure 6, above, is a clear illustration of how easy it is to add two method calls without upsetting any of the surrounding lines of code in Figure 5. No braces need to be added because they are already there. The value of this style is that you may wish to add multiple lines within any of the code blocks; this makes it very easy to do and retains code legibility.
As ever, please feel free to post your comments, whether you agree with me or not.
Style, in any artistic or professional endeavour, is impossible to quantify, define or measure. It’s highly subjective and can often be controversial. So I’m going to push my own opinions in this, the first of several posts on the subject of coding styles. They won’t be complex articles, merely a look at what I think is poorly-written code versus how I believe it would be better presented. There will be no attempt to discuss whether the code in question is inherently “correct”; merely that it looks difficult to read and is hard to maintain. The aim is to turn both of these problems around, thus making the code easy to read and maintain.
In cases where there may be several variants, I will present them, and give a synopsis of how “stylish” I think it is.
Your comments, as always, are very welcome on this topic.
Example 1, SOQL Queries in Apex:
Let’s start with a common code segment whereby a SOQL Query is run and the resultant record set is returned into a list data structure.
List<Custom_Object__c> lstRecords = [select id, field1__c, name, number_field__c from custom_object__c where name like 'Smith%' order by lastname, firstname limit 100];
Figure 1, above, shows how an “undisciplined” programmer might put together a code segment that retrieves a record set from a SOQL query. In an IDE or other editor, this might well appear as a single line and you would have to scroll right to see the full detail.
List<Custom_Object__c> lstRecords = [select id, field1__c, name, number_field__c, an_additional_field__c, and_another__c from custom_object__c where name like 'Smith%' order by lastname, firstname limit 100];
Figure 2, above, would show the result of adding two additional fields to be retrieved by the query. Not very pretty.
List<Custom_Object__c> lstRecords = [
SELECT
Id
, Field1__c
, Name
, Number_Field__c
FROM Custom_Object__c
WHERE Name LIKE 'Smith%'
ORDER BY FirstName, LastName
LIMIT 100
];
Figure 3, above, is how I would put this snippet together. I find this more professional-looking, much easier to read and far easier to modify. The following improvements have been made:
the outer data structure is separated from the inner SOQL statement
code is indented in a useful way
keywords are uppercase for readability
query clauses are split onto separate lines
fields are also split onto distinct lines and vertically-aligned to enable simple editing
field names have been retyped with appropriate letters in uppercase
You may not agree with the word “improvement”; please let me know if you don’t, and the all-important reason why.
List<Custom_Object__c> lstRecords = [
SELECT
Id
, Field1__c
, Name
, Number_Field__c
, An_Additional_Field__c
, And_Another__c
FROM Custom_Object__c
WHERE Name LIKE 'Smith%'
ORDER BY FirstName, LastName
LIMIT 100
];
Figure 4, above, shows the result of adding the same two additional fields as in Figure 2. The results speak for themselves.
More code examples to follow soon. Why not follow the blog to get email notification of new posts?
Acronyms used above:
SOQL = Salesforce Object Query Language (a proprietary variant of SQL)
IDE = Integrated Development Environment (e.g. Eclipse, MS Visual Studio, NetBeans, JDeveloper, Xcode, etc.)
This is aimed at Java and C# developers who want to move into cloud computing and create demand for their skills.
One thing I regard as vital is to constantly keep an eye on your career progression. My aim is to make myself just that little bit more employable every year. It’s tough to combine this with a busy work schedule, but just because it’s tough doesn’t mean it’s not worthwhile.
The last year has seen huge growth and even bigger projections for the future of Cloud Computing. The trends are all upward, there’s no doubt. Gartner’s recent report states that the areas of “social, mobile, big data and cloud” will experience growth as they are championed by new IT leaders. Forrester predicts patterns of growth that are also encouraging. Most pundits and industry commentators agree and many of the big players are positioning themselves along these lines.
Along with explosive sales in mobile and tablet devices, it’s clear that mobile applications (particularly those that are cloud-based) will feature strongly in a global IT context for some time to come.
Add social media to the mix and it’s clear that Salesforce.com (with its Force.com platform) has its bases well and truly covered. They’ve got Chatter; Facebook and Twitter integration is covered; Touch is their technology stack for mobile; mobile apps proliferate.
And at their heart SFDC are “Cloud”. They are pioneers in the arena, that’s an undisputed fact.
Getting down to nuts and bolts, if you’re a developer with Java or C# skills, there’s a definite path you can take to sharpen your skills to become a certified Force.com developer. If you have designs on such a career path, my advice would be to follow these lists:
Application & Configuration Skills:
Get yourself trained up on the (Sales Force Automation) SFA application and, optionally, get yourself a certification
Understand what Account, Contact, Opportunity, Pricebook, Product, Case, Lead are, and what they do
Understand how to use Reports & Dashboards
Preferably, attend at least one of the Salesforce Administrator courses
Learn how to configure custom objects, custom fields, page layouts, field sets, formula fields, validation rules, custom buttons & links
Learn about Security, Roles & Profiles, field-level security
Get acquainted with Workflow and Approvals, what they are, what they can do
Learn how to import data with the Data Import Wizard
Learn what SFDC API usage limits are and understand how they may affect any application you design
Learn the new coding paradigms for bulk processing (a large topic but here’s a useful starter blog post)
Understand Lists, Maps, Sets and when to use them to handle batches of data
Understand Test Classes & methods
Learn about Apex Batch and Scheduled jobs
Learn how to use the SFDC SOAP and REST APIs and Workflow Outbound Messaging options
Learn how to extend the API with your own custom web services
Understand how to process inbound emails in Apex
Use Eclipse and the Force.com plugin to maintain Apex & Visualforce code and to examine the database schema
Learn how to debug code and troubleshoot using the various tools on the Force.com platform
Understand all the places (or “hooks”) where you can plug into the SFDC application to customise it
Gain at least a cursory understanding of SControls (deprecated functionality) in case you need to modernise or maintain old applications
Understand how to use the Apex Data Loader
To help you on your way with the above, here is a link to all SFDC documentation (pay special attention to the Apex and Visualforce reference docs)
You can also take your existing skills with you, and these will be invaluable:
Database and application design skills
Data Migration skills
Data Integration knowledge
Service-Oriented Architecture (SOA) and web service knowledge
Industry vertical expertise
Test-Driven Development (TDD) strategies
Source code version control tools and techniques
Multi-developer, multi work-stream development
Application testing strategies & methods
You can acquire all the training resources you need with little or no cost, but you can also accelerate your ramp-up time by attending SFDC formal training courses.
Anecdotal evidence would suggest that there are at least some Java developers out there who have a reluctance to extend their knowledge into the Force.com arena, primarily because of the more restricted nature of the environment. However, if you take the plunge, the rewards are there for the taking and you’ll join a growing army of technicians with niche skills.
Don’t be too quick to assume, however, that because you can instantly read Apex code (which a Java or C/Whatever coder can), your transition will be instant – there’s a little more to it than that. Most who took that path with that outlook fell foul of platform differences, a.k.a. the famed Governor Limits. But, learning the How, When and Why of these limits will help get you to the next stage in the transition process.
Trapdoor In The Sun 