The choice facing software companies has been really two-fold. Either buy a modern service desk system or use the service desk module of the market leading agile development tool (no prizes for guessing which one we mean).
We don’t have any statistics to back us up, but our suspicion is that the majority opt for the standalone system. There are a number out there with richer functionality than the service desk module we refer to above.
Either way, in effect this architecture divorces your bug and incident management processes from the rest of your data and operations. The advantage of this choice is easy to understand. You can buy any system you like and it will be relatively easy to install and operate.
The disadvantages, on the other hand, are many:
- You have to model and keep up to date another customer master table and associated contacts. Also, as service desk systems don’t really care about money, the counterparty model may be a simplified version of the rich one you need for your contracts
- Recording time may also be problematic. If you are using a timesheet system across your whole organisation (and it makes sense to do this), forget about recording service desk time by customer. It’s of course still possible to do, but many small timesheet bookings taken out of context are unlikely to have any meaningful degree of accuracy over time. They will be useless for analysis, other than in the most high-level sense
- Are you doing support after a customer has cancelled their support agreement? Service desk systems may have some limited degree of contract modelling, if you can be bothered to use it. The problem is remembering to keep it up to date, reliably. You won’t be the first company to provide free support, nor the last, so maybe that doesn’t matter
- While contracts are hard, assets are near to impossible to model accurately in a parallel system correctly. So, if an aspect of your support load covers physical equipment, don’t expect it to be right, or the coverage list up to date
- Then there is development backlog work: you will have to remodel a customer feature request that may have been reported as a feature request in a separate system for backlog management, and then remember to close it once released. All of which is perfectly possible and also very difficult
- Lastly, that’s another system to pay for - they can be quite expensive
So, if there are so many drawbacks, why is this the most common model adopted?
The answer is simple, there was no practical alternative. PSA systems with integrated service desk were not good enough for ISVs in so many ways; everybody simply had to live with this very poor compromise.
0 Comments