It’s a common practice to categorise clients (or prospects) using an A/B/C rating (or similar).
This practice may be common, but it’s rarely sensible!
Organisations typically apply such a classification in an attempt to prioritise the allocation of sales resources (field or phone) to relationships under management.
If those resources are abundant, this method may possibly be workable.
If, however, those resources are constrained (finite), then things go pear shaped!
The fact is that A relationships do not all have identical value. The same applies for B’s and C’s.
If finite sales capacity prevents (say) an internal salesperson from phoning all A clients simultaneously, then it’s necessary to index all these clients in descending order of value (where ‘value’ is the expected Throughput contribution from the allocation of this client to a unit of the salesperson’s time).
This means that we now need one classification for each relationship under management — and there are only 26 letters in the alphabet!
Worse still, the value of allocating a particular client to a particular salesperson tomorrow may differ from the value today. (For example, let’s say the client purchases product x which happens to be in stock today, but will be out of stock tomorrow.)
This means that we need to be able to index relationships dynamically. And we cannot do this with an arbitrary categorisation method.
The solution is to determine the drivers of value from the client’s (or prospect’s) side of the fence.
If we were selling software in an enterprise environment, these may be things like:
- Enterprise database (Oracle, MS SQL, Unix, etc)
- Number of seats
- Age of current application
You then need to determine the drivers of value from your side of the fence.
Maybe stock levels or service capacities. Maybe cashflow requirements.
You can then design a formula that crunches these variables and provides you with a number that indicates the *relative* value of that relationship. All relationships can then be indexed using this number.
The result is a list of relationships (say, clients) indexed in descending order of expected Throughput contribution (if that relationship is applied to the *next available* unit of sales capacity.)
This list should be re-indexed regularly.
The list can also be used to calculate the ‘opportunity cost’ of not calling those relationships that remain unallocated — and to determine if this opportunity cost is greater than the cost of another salesperson.
The A/B/C categorisation method may be simpler, but it’s based on an assumption about reality which is, more often than not, wrong.
