All These Different Channels - How do we manage?

First, let’s discuss the all important email and avoiding direct-to-agent emails. It seems that with the advent of all the other social technologies email is still the #1 conduit for requesting help. Why not, it’s easy, unobtrusive and disconnected. A modern service desk should be oriented in such a fashion that we avoid direct agent-to-customer communication. Instead it should be Service Team-to-customer. Working in this model avoids any confusion surrounding vacation schedules, termination, availability/workload or skills based routing (let the system do it not an agent). This is a key factor in providing a scalable service management offering where the service management framework load balances requests and aggregates all of the information onto the correct request for a concise / cohesive picture of the customer’s issue and what has been done and by whom. At the end of the day your ensuring your customer receives the best possible service based on your staffing and workloads.

I’m sure many of us have been in the situation where a corporate/departmental wiki has gained some traction and we’re now stuck supporting it. Many times these wikis which are collaborative peer-to-peer service tools contain a "boat load" of information. This is out-of-band information that we need to capture and publish to our end users. Be aware that this disjointed access to information for the end users and your support staff will lead to the ‘oh hold on a second’ agent response which infuriates end users. Channel independence helps avoid this (IncidentMonitor has it’s own communities which are natural language searchable, can be facilitated by the service desk and provide a peer-to-peer communications medium).

Now Let’s talk about walk-ups or fly-bys. This is quite common and understandable within corporate environments. An application should allow you to define common types of requests for single click creation. Further more it should support an emanation property so you know which channel the request was created through (in this case the emanation could be fly-by 😉 ). What this does is aid in your statistical analysis of the service desk. As an example let’s suppose you correlated your fly-bys to survey results and your survey results were quite favourable. You may think about having someone walk the floor (at periodic intervals) with a tablet solving issues and logging requests – kind of a roaming genius bar. All in all it is of utmost importance that these types of requests are captured to ensure we understand how busy the service desk is – without them there are holes in our workload. We must be aware that these types of requests will always happen we should be ready for them with templated requests for single-click request creation on any device.

So remember the next time someone flies-by your desk and says hey can you help me? Say, certainly let me just create this request for you – OK, done”.

If you are looking to purchase an ITSM tool or are an existing client of ours just ask how you can improve the management of your out-of-band data with Channel Independence.