Trapdoor In The Sun

Alan Shanahan, Technician & Consultant

Leave a comment

Help, The Internet Isn’t Working

Please Help Me

“The internet is not working.”
“My computer isn’t working.”
“That program doesn’t work properly.”.

If you’re asking someone for help and you think this is useful information, then you really need to try harder. Most of those who have spent time supporting others will have heard lines similar to these at least once. It’s the equivalent of someone throwing their arms in the air and say “I don’t care how you do it, just fix it”, and it’s hard to take. This is bad enough when it comes from self-confessed, even proud, Luddites. But when it comes from other technicians, it is hard to forgive.

Often it’s because they have no experience of supporting users themselves and cannot perceive of the viewpoint of the person coming to their rescue. It screams loudly “I am not prepared to invest a moment into this, I just want it to work”, and much of technology just isn’t like that. If it’s man-made, it’s fallible and things go wrong.

Consider the first phrase above: “the internet is not working”. Apart from displaying a high degree of ignorance, it isn’t helpful in the slightest. You can glean from that phrase that someone has a problem browsing the web. Because the “web” and the “internet” are the same thing, right? There’s the first problem. Let’s assume there’s a problem browsing the web; how does the problem manifest itself? Is the web page slow to load? Does it load at all? Is there a visible error message anywhere? Before wasting your support person’s time, look closely at the problem. If the web browser says “HTTP error 404”, pass on that information. What web page are you trying to access? Pass that information along. What web browser are you using, Internet Explorer, Chrome, Firefox? Tell the man! It’s all useful information. Are you able to access another web page, one you know works, e.g. Let him know. Is your WiFi connection active? Can you access any other internet services, e.g. email? Can you send messages? Can you receive? This is all useful information and accelerates your support person’s ability to resolve your problem.

Where To Start

From the support point of view, it’s all about having a decent starting point. A succinct, clear description of the problem, some supporting information. From there, it’s a game of elimination. There are many components in this problem; the technician has to think about “the chain”. What is the chain?

Computer -> browser/email client -> firewall -> wifi, if any -> cables, if any -> router -> incoming cabling -> ISP -> DNS servers -> web server

This is a simplified chain to make the point. Look at any one of those points of failure and think about how many possible faults there are. The number is quite large. It needs to be reduced. Giving additional information like “I cannot access my email” or “I can see the BBC news web site but site X pages aren’t loading” is very useful. It shows that the computer, browser, connection, router, incoming cables, ISP and DNS servers are all working and that the problem may lie at the web server side or email server of things. The techie asks “what URL did you type”, “how are you trying to access the web site” or “show me your POP3/SMTP settings” and discovers that the user has typed in the wrong URL or has a misconfigured email client. Without this extra detail, the user has to check each component above until he discovers the point of failure. Each link in the chain could force many questions and take a lot of time.


The central message of this post is not just for users of technology, it’s for designers too, at all levels. Give users the visibility they need to help you to help them. Consider how they have visibility of your system and how they can extract useful information from it to help you support them. Everyone stands to gain from this.


1 Comment

The Subscription Continuum

A New Opportunity, A New Industry

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 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:

  1. system agility
  2. the ability to take advantage of new software releases
  3. 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.

  1. People use the word “subscription” but haven’t thought about what the word really means
  2. In a new systems environment, new tools, metrics and controls will apply
  3. 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 thinking Subscription but practicing Transaction? 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.

The new metrics are touched upon in this blog.

Old numbers, metrics and measures still apply but a subscription business needs these new metrics to plan ahead successfully.

Read Denis Pombriant’s blog post which also makes reference to new metrics vs. the ERP mindset.

3. What Is The Preferred Solution?

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

  1. education (in how Zuora works out of the box)
  2. simplicity (in your product offerings, payment options, pricing)
  3. flexibility (re-thinking how you manage your sales accounting)

You don’t have to re-invent the wheel.

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.]