Trapdoor In The Sun

Alan Shanahan, Technician & Consultant


1 Comment

Preparing Your Discount Rules For The Subscription Economy

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

Advertisement


Leave a comment

Developer Maturity

Thirty-odd years ago, I wrote my first lines of BASIC code on an Apple II computer donated to my secondary school by some local businesses. We were the first of our school and, to some degree, our generation to have access to such a device. I was hooked from the word go. All these years and a few dozen jobs later, I can tell you I’ve seen the full spectrum of good and bad in the world of programming; I may even have contributed to the bad side, but I live in hope that most of what I produced was leaning towards the better side of things.

But I can see definite steps in my progression in those intervening years; let me focus on programming itself, or “development” as the industry likes to call it. Today, I have a very different mindset to that of my teen years. My young naive self revelled in the idea that you could type an arbitrary set of instructions into a machine and it could do the most marvellous things. Coding was an end in itself! It existed just so that beautiful programs could be written and run. I had a lot to learn.

Then I started working in the real world. My programs were now being used by real people, in a real business, every day. There was a huge amount of job satisfaction in that idea. Everything changed. My “hobby” was now something to take seriously and it had to perform to a new standard. But I didn’t fully realise that and I still saw programming as an isolated pursuit with its own intrinsic value; in my mind it was a primary activity with its own purpose rather than an enabler. This illustrated an immaturity in terms of my business viewpoint.

Many years later, I’ve managed programmers and development teams. Still doing that. I’ve designing solutions for customers that are implemented by these teams. I’ve seen and reviewed a lot of code. In that sea of code, the full spectrum of quality exists. Some bad practices can have a subjective slant to them, but other bad practices are just plain bad. I’ll tackle the subject of quality later, it’s just too big to even contemplate here. But one point on quality is worth reiterating here and now: quality is everyone’s responsibility. I won’t explain that further, I believe the words do that for themselves. You own quality. You own problems created by your programs, no matter how trivial. At least to some extent. You owe it to your team to properly ring fence and test scenarios your programs are supposed to handle. You owe it to the customers who are paying for your development efforts.

And what I have seen is a set of behaviour patterns that seem to be repeating.

Firstly, there is an obvious disconnect between some programmers and the end user they are programming for. Think about users. Someone will sit in front of a screen and use your programs. They are real people, no matter how distant they are, or how imaginary they seem.

Another misalignment I’ve seen is that some programmers don’t conceive that data represents real world things. Financial data represents money, real money, not imaginary money. This is important to customers. It’s their money, the life blood of their business, which would simply curl up and die without it.

Polish! Polish your code. Polish the user interface. Try to break your programs. Keep trying until they no longer break.

Open your mind. Let go. Don’t be afraid to rework what you’ve written. The best writers and authors do this regularly; that’s why they’re the best. Coding is not an end in itself, it’s a means to an end: the business aim is the end. Code is just an enabler.

Do these things…

…and you’ll be all grown up.

[Note: I’ve emphasised “some programmers” in this piece. I’ve worked and continue to work with many superb developers. It’s worth mentioning.]