In a previous post I examined what a bill is, but that leaves us with the question of what a bill is for. To really understand how to best design a bill and how to best architect the underlying people, processes, information and technology needed to deliver that bill we need to understand why we are doing all of this. We need to understand the real purpose of a bill.
My belief is that the most important purpose of a bill is to get the customer to pay the service provider what they owe. It does that by giving them a range of information, and we can make it more or less successful by how well it conveys that information. For instance if it is unclear what the charges are for, or how they were arrived at, then people will be less likely to pay their bill (without querying it). We have then undermined the fundamental purpose of the bill. Thus, most of what we regard as “the purpose” of a bill is merely a means to this end: to communicate the charges accrued since last bill, to clearly communicate what the customer owes, to convince them that we have correctly calculated their bill. They are just ways that we convince the customer that they should pay the service provider that amount (and pay it now, please).
We might use the bill for other aims – to help us market for instance – but that shouldn’t distract us from this primary goal: getting the customer to pay!