Josie Sephton, originally published on The Register
Critical to any new implementation is support. But if the implementation is designed to fit in with the way we work already, then the only issue is how it works in the context of the organisation. So for example, a replacement customer relationship management (CRM) system may not change the way a company deals with the whole customer-relationship area, as much as refine and improve it.
Unified Communications (UC) is different, in that it is a new system which brings with it new capabilities. Because of this, businesses will only really see significant benefits if they change the way they do things.
Take for example a technical call centre that handles customer queries. In a non-UC environment, for calls that can’t be handled immediately, details will be taken by a call centre operator, and followed up on an iterative basis with the relevant technical support experts. Once the query has been resolved, the customer will be contacted by the call centre operator with (hopefully) a solution to their problem.
Coming at the same issue with a call centre that is UC-enabled will involve a completely different approach, with the call centre operator assessing the problem, and then reaching out to a number of experts simultaneously, based on suitability and availability. Depending on the nature of the query, the call might be handed directly to an expert to resolve, or be dealt with by the operator directly, based on feedback from the expert.
The whole process will be geared towards first-call resolution, in a way that wasn’t possible before. While this is a rather obvious example, as there would be little point in putting UC into a contact centre if processes within the centre didn’t change, it does illustrate that the way processes – or indeed communication and collaboration – are dealt with need to be approached differently.
But this alternative way of doing things can lead to an added level of complexity from a support perspective, moving it from dealing with just technical issues to include more process-based help. Moreover, it is important not to underestimate how critical this process-based support is, particularly in the early days of a UC implementation. The essence of UC is that it can enable people to work differently. But they will only make this behavioural shift if it is easy for them to do.
Most people in a company, while not necessarily resistant to change, are unlikely to be real proponents of UC – they probably didn’t even see the business case for it. While they will probably be willing to give one-click-to-call videoconferencing (or whatever) a go, if they hit any sort of roadblock they will stop; and like the proverbial donkey, it will be very difficult to get them going again.
The take-away from this is that if it isn’t ‘in-your-face’ easy, or if issues can’t be resolved quickly, then the anticipated benefits of UC – around improved collaboration, process streamlining, reduced travel costs etc – could disappear before they’ve even materialised.
The issue of getting the right skills and processes in place from a helpdesk perspective was discussed in a recent article. Building on this, it is worth considering being proactive about scenarios that may arise, in a very specific way. So for example, for someone setting up a webconference meeting, what process will they need to follow? Will the process change depending on where people are located – for example for home-based staff? And what resources (eg online help) are available if things go wrong?
The more of these ‘self-help’ guides that exist, the more people will be likely to embrace the different aspects of UC. Some staff can be resistant to calling the help desk, so the more we can prevent things getting that far, the better. On this point, it may be useful to think about nominating and even training people across different physical locations to provide local embedded support. This already happens in many companies with things such as Outlook or Windows (where Ken is the man to ask in Marketing when you get stuck).
On the flip side of embedding a UC culture is making sure that it doesn’t disrupt people to the point of distraction, or worse, rejection. UC by its very nature makes people more available. But that doesn’t mean that they can be interrupted at will. For someone trying to deal with an important deadline, an interruption, say through IM, can cause a very unwanted context switch that is hard to recover from; that can turn out to be very costly, both to the individual and the company.
So as well as teaching staff how to use UC, it is probably as important to teach them how not to use it. This means putting together clear guidelines around business etiquette, and how to behave with UC.
It may also be worth including pointers on how to respond to inappropriate requests, such as requests for group meetings that could be dealt with in a one-to-one, particularly as many situations will be new to most people, and they will be looking for guidance on what they should and shouldn’t be doing. The knock-on positive from this is that it could help people deal with their natural reluctance to say ‘no’ when ’no’ is the right word to say.
Getting people working with UC in a proper, sustainable way is more than making sure that the helpdesk is properly staffed, but requires an all-encompassing approach that covers as many of the bases above as possible, and probably more. If you have had experience in driving this cultural shift, or even if you are wondering just how to go about it, share your thoughts with us.