Save Money With a Good Leavers Process
One of the interesting things I have come across a number of times is a quirk that causes companies to pay money for services they don’t need.
The most extreme example of this is an establishment that was paying for 230% more telephone users than they actually had. That’s not a typo - they were paying a monthly fee for each of 2,300 telephones registered on their system. After a thorough survey we found they only needed 1,000 telephones.
This example sounds extreme, but it’s not the only one - how can this be?
My thinking is this stems from the asymmetrical joiners and leavers processes.
When a new person joins a company - there’s a push to get them registered on the systems they will need, get them signed up for induction and other training and get them a telephone.
When someone leaves there is a process to have all their accounts switched off, but a lot less effort goes in to this - there isn’t someone sitting at a desk with nothing to do until this happens. The leavers process is largely about security and having access switched off and not so much about reducing spending - and stopping the subscription for the telephone (and, possibly, voice-mail service) is often forgotten - and once forgotten may never be discovered. All it takes is this slight imbalance to exist between the joiners and leavers processes for a while and telephone subscriptions fall through the net.
For many older systems where the hardware is already bought and operations costs are based on actual effort required this may not be a problem, but for newer cloud services and anything charged by number of registered users this could be a problem. And a new cloud service provider hasn’t got a great incentive to reduce your monthly outgoings.
This was complicated in days gone by because costs could be avoided by leaving a phone on a desk in place for the next person to sit there and so it was easier to just leave it, but today physical phones are being replaced by software applications - so there’s nothing to be saved by stopping an account on a leaver’s last day.
Note also that when a phone system is replaced it’s often tempting to simply download the list of users from the old system and upload this to the new system. By doing this you could find yourself paying for service for users who left before the current system was installed.
To address this I’d suggest two tasks.
First get a report off your system of all the users’ names, ideally grouped by department. Firstly, how does the quantity of subscriptions compare with the current head-count?. Ask managers or to check the names. Staff members who have been in the organisation a long time may be able to shed more light and you may get responses like “Mike Smith, I remember him, he left about five years ago”. This exercise will give you an idea of the scale of the problem. It may be enough to just find the names of the people who have left and cease their services - if the problem appears bigger it may need a full-on survey. Consider also how much your service costs per user per month and, as in this example, how much 60 months of that adds up to. This could be a project that pays for itself!
Second review the leaver’s process. From the first exercise you will know how much of a problem you have. If it’s only a few falling through the net or, it appears to be a number of cases within a limited time frame in the past then there may not be a significant problem. If the problem is happening and happening now then the team responsible for the leavers process will need to update this process to avoid the financial loss. They could explore ways of automating the process.
If you’re planning to replace your current system it would be good to have a proper survey of all your users so that you know that you are only paying for the service you need. Do this at the outset so you get the right pricing for your actual requirements and don’t commit to a value of business that is too high.
One final note - don’t forget voice-mail or any additional service that may have been subscribed to.