[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference kernel::csguk_systems

Title:CSGUK_SYSTEMS
Notice:No restrictions on keyword creation
Moderator:KERNEL::ADAMS
Created:Wed Mar 01 1989
Last Modified:Thu Nov 28 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:242
Total number of notes:1855

170.0. "Live Call Handling Topic." by KERNEL::ADAMS (Brian Adams CSC-Viables '833-3026) Thu Apr 07 1994 09:17


	From the experience of the first day's operation, we need to 
	have some guidelines to cover how the "Live Call Handlers"
	work, within the group. These are _NOT_ set in concrete, and 
	anyone can propose changes, for group approval.


	1. The selected persons will still diagnose calls, but not to
	   the point where that diagnosis in any way prevents them being
	   able to take live calls. eg. Background bugcheck or error 
	   analysis might be possible.

	2. When already working on a call, they will make a decision on
	   any new call, as to which one to pass to a colleague. Where 
	   possible this should be on a skills basis first, then by
	   whoever is free to take the call.

	3. The "live" persons will _not_ swap for lunch with each other.
	   The person with whom they swap, will become "live" whilst 
	   covering the lunch period.

	4. If you are not available for any day that you are selected to 
	   be live, then you must arrange a mutually agreeable swap.
	   The selections for the next few weeks have been made purely on
	   indicated availability, and are highlighted on the rota.

	5. Any person, not otherwise busy, can and should at any time,
	   be ready to take live calls, especially at busy times.

	6. Remember that "Live Call handling" does not necessarily
	   imply "Live Diagnosis". There may be cases where the customer
	   may ask for this to be done later, or the nature of the call
	   may dictate this.

	I will put this mail as a new topic in the notes file, so feel 
	free to comment/voice your opinions/suggest improvements etc.

	Regards
	Brian Adams.


    
T.RTitleUserPersonal
Name
DateLines
170.1KERNEL::WRIGHTONI'll call you back later, alright !Fri Apr 08 1994 06:1784
	
	As I'm on nights this week I've missed all the discussion about
	this issue, so this is probably covering old ground and things
	that have already been worked out. I am not offering any 
	alternatives, just trying to understand what's happening.


	1) I heard that "we weren't going to meet the live call handling
	   goal". What were the figures ?? As the phones only changed
	   within the last few days, is that long enough to draw
	   conclusions ?

	2) Why didn't having one line for all calls work ?

	3) What other alternatives were discussed before coming to the
	   plan in .0 ?

	4) What are we trying to achieve here ?? Are we attempting to 
	   bend the stats or to increase customer satisfaction. Can 
	   someone find out EXACTLY what questions 1 and 3 are in the 
	   SQR FY94 (see the goal sheets item #1) coz those are goals
	   that we actually being masured against.


	Commenting on .0 .......


>>       1. The selected persons will still diagnose calls, but not to
>>           the point where that diagnosis in any way prevents them being
>>           able to take live calls. eg. Background bugcheck or error
>>           analysis might be possible.

	?? Cut off point ?? While these selected persons are talking to
	   the customer and deciding how far to go with the diagnosis,
	   who is taking the live calls ?? And while they're calling the 
	   customer to discuss the "background bugcheck", who is taking the
	   live calls ??



>>	  2. When already working on a call, they will make a decision on
>>           any new call, as to which one to pass to a colleague. Where
>>           possible this should be on a skills basis first, then by
>>           whoever is free to take the call.

	?? Are they going to attempt to pass the customer live or tell the
	   the customer that we'll call them back. If the latter is the
	   case is this progress or stats manipulation ??



>>        5. Any person, not otherwise busy, can and should at any time,
>>           be ready to take live calls, especially at busy times.

	?? Thats pretty radical, maybe we could try that all the time.




>>	  6. Remember that "Live Call handling" does not necessarily
>>           imply "Live Diagnosis". There may be cases where the customer
>>           may ask for this to be done later, or the nature of the call
>>           may dictate this.

           If Live call handling doesn't mean live diagnosis, why not
	   get all the calls taken live by someone non-tech (Angie ??)
	   who will accept the NICE call live, tell the customer that 
	   we'll call them back and then stick it in the queue ;-)
	   


	If I was a customer I'm not sure I'd be happy with a kind of 
    	"... I will spend two minutes diagnosing and if I'm not getting 
    	anywhere, then someone will call you back and spend time asking 
    	you the questions I have already asked you" 
	
    
	I love playing the stats game, it's so flexible, you can
	achieve any result you want, sometimes even get conflicting
	results at the same time.	   
			

    
170.2As I was saying to Dave !!KERNEL::ADAMSBrian Adams CSC-Viables '833-3026Fri Apr 08 1994 09:2863
    
    	As I've already spoken to Dave on the points that he raised, I'll
    	reply here, but that doesn't stop anyone else commenting as well.
    	Remember, this was an attempt to provide a "Band-Aid" fix to a 
    	problem that was seen to need fairly urgent action. Nobody has 
    	said it is right, or the best answer, it's just a trial to see if
    	it meets the requirements. With constructive comments and
    	suggestions, we can improve it and maybe even get it right.
    
    	So to Dave's points;
    
    	No figures were available. By the time they were, it might be too
    	late. Even though these were not specific to the bonus, it was 
    	felt that we should take steps to avoid the possibility that a goal
    	might not be met.
    
    	The one phone line might work, this augments that idea, for
     	reasons as above. Response are now aware that there is a 99% 
        possibility that the hunt line will be answered, rather than
    	the much lower possibility that previously existed.
    
    	No other alternatives were proposed during the discussion, which
    	although relatively brief, had general agreement of those here.
    
    	There were two goals, customer satisfaction plus an attempt to
    	prevent the loss of a bonus.
    
    	
        Re comments:
    
       The one criteria for doing the diagnosis yourself on a live call
       is "Will my work on this call, impact my ability to handle calls
       live ??"  If the answer is no, then go ahead.
    
       There are two issues here that we do not want to see.
    
    	(a) The live call handler just farming calls to the rest of the 
    	    group, after just a quick chat with the customer.
    	(b) Customers being handled live, and then having their calls 
    	    queued as before.
    
    	We want the customer to see something by way of progress, in that
    	once he has actually got his call logged by Response, he then gets 
        to speak to an engineer straight away, to have his problem
    	discussed, up to the point that diagnosis can begin.
    
    	The live call handler must make a decision;
    	(i) Should he discuss the problem with the customer and make the
            diagnosis himself ??
       (ii) Should he discuss with the customer, then have a colleague do
            the diagnosis ??
      (iii) Should he pass the customer 'live' to a colleague, to discuss
    	    and diagnose ??
    
    	Whichever option is chosen, we get away from the old scenario,
        where the customer waits to log his call with response, then is
    	told that his call will be queued and he will be called back
    	sometime later. One small step - maybe - but progress all the
    	same.
    
    	Also, because the customer will be spoken to live, by an engineer,
    	we should see the demise of the "P1-Call - PANIC" situation.
    
170.3Paperless logging system due shortlyKERNEL::PETTETNorm Pettet CSC BasingstokeTue Feb 21 1995 09:0912
    One of my actions, from the Unit Meeting held last Friday, was to
    organise a call tracking logging system to track requests, logged by 
    response, but not passed LIVE to the systems queue. I've configured a
    command procedure but I decided I didn't want my account filled up with
    mails so I have requested a mail account from IS. As soon as this has
    been setup Shane, Paul, Brian Anthony & myself will have access to it.
    I will give details on how we identify & log LIVE calls not passed to
    the SYSTEMS group shortly.
    
    	Watch this space...
    
    			Norm
170.4procedure in placeKERNEL::PETTETNorm Pettet CSC BasingstokeWed Mar 01 1995 16:0018
Chaps,

	In order to track, when a request is routed to SYSTEMS queue without
the phone ringing or not ringing long enough (2 rings), I have written a
command procedure. To invoke it type @RDC$COMMON:LIVE.COM. or add the
following to your LOGIN.COM and just type LIVE 

$ LIVE :== "@rdc$common:live.com"

	It will mail you & Shane the details, when IS have sorted out a new 
account the mail will goto a dedicated mail account.


	Any problem let me know


		Norm