These phases can then be segmented further as illustrated in the diagram to the lower left.  It is important to remember that the size of the organization will likely have a sizable impact on how many different people are involved in this process and how drawn out it is in its execution.

Regardless of whether we assume there is some sort of customer care ticket tracking software, there needs to be some productive interactions between support staff and the concerned end users.  This can be done over the phone, face-to-face, or maybe online.

One hopes that these interfaces are all going to help create interactions that further a support group's efforts to render assistance.  At this point it can also be important to try and do some filtering and discernment of the real difficulties the end users are encountering.  End users can have unusual understandings of what is wrong and how things might be improved.

After this, there is very likely to be at least one knowledgeable classifier who can at least fairly well determine who should handle the incoming ticket.  This may be done by a person or to some extent by a ticket processing system.  Though the more automated this process is, the more the system needs to rely on the ability of the users seeking assistance to give particular indications about the nature of what they're looking for.

Some typical classifications will relate to software, and particular types of software, more common types of difficulties, network troubles, troubles locating things on the networks and etceteras.  There is likely to be some real needs for staff and end user interactions for all but the most obvious issues.

At some time while this classification is being done there also needs to be some sort of recording of certain essentials for later reference.  This needs to be done in an adequately systematic way to enable the process to continue and to facilitate future efforts to improve these processes.  The people or systems doing things such as classifying and recording need to be capable of adapting to end user inputs and clarifying confusing ones.

In order to be really thorough, the next step really should involve someone trying to reproduce the problem in order to ensure they really understand what has happened.  If it cannot be reproduced then it is very likely there is some sort of miscommunication or misunderstanding going on.  This also helps verify when the reported issues are resolved. Unfortunately, it is not always possible to be this thorough.  But it is important to make serious efforts to validate one's understanding of the reported difficulties.

Around this time in the process the issues are likely to get handed off to someone to try and handle them.  This person is often called an SME - Subject Matter Expert.  This expert should propose and select potential solutions.  It is always important to consider past experience and start with more viable approaches.  These need to be attempted and possibly implemented by someone with the appropriate skills that Limocelli calls a craft worker.  It is very likely that all of these steps will be executed by the same person, though not necessarily.

Finally, after all of this effort has been expended it is essential to verify its usefulness and effectiveness.  This needs to be done both by the system and the end user.  This also helps ensure that the end user understands what they should be doing to get particular things to work.

It is my view that Limoncelli presents a fairly clever characterization of some of the things that are likeliest to go wrong in this process.  I reproduce much of this in this next outline section.

• The Ogre - Grumpy, caustic personnel prevent the process from really ever getting started.
• The Misdelegator - The system or person that routes and/or discerns the difficulties misunderstands or misappropriates the handling.
• The Assumer - One of the most difficult things to remember is spelt "assume makes an ass out of you and me".  Active listening is likely to help, but even then it can be way to easy to assume that one, some or all of the sources involved either know or don't know what is really going on.
• The Non-Verifier - It is terribly important to verify understanding of what is really occurring.
• The Wrong Fixer - It may get handed off to the wrong person.  A fixer may not be able to admit they don't really understand or really aren't capable of handling the end user's complaints.  There are all kinds of scenarios for this.
• The De-Executioner - No real excuse for incompetence!  This may require more than training, but training should help.
• The Hit and Run Help - The expert may be way too sure of their approach.  Or maybe they are way too unsure of their approach and need to cover up.  Whatever the cause, the assistance is rendered ineffectively with little or no effort to verify or interact.
• The Closer - Maybe the person rendering assistance is way too caught up in closing the ticket, thus demonstrating a very short processing time.  Maybe the organization's performance assessments help lead to inappropriate solutions efforts.  Maybe someone is really just sloppy.  Regardless of the internal motivations, efforts at effective solutions and verification must occur.

May times, at very many sites, all of these efforts are handled by just one person.  This is a reality for many organizations.  Adequately staffed capable people are essential.

The Icing.  It is important that the people involved in processing and delivering customer care have effective training.    It is also important to improve all of the steps of the process.  Increasing end user familiarity with the processes and helping end users improve their own self reliance and interactions can greatly improve the customer care experience for everyone involved.  It may well reduce the workload of the end user service groups.

It is likely to be essential that the managers of these processes track historical data to determine a variety of things such as the following.

• Are the same issues being reported over and over?
• Are many customers reporting the same issues?
• How many questions are in particular categories?
• Can some of these issues be developed so that end users can render self service?
• Who are the most frequent customers?  Why?
• What are some of the most time consuming requests?

It can be very worthwhile to determine what end users are the most capable of rendering their own self assistance and those that can give the  most knowledgeable inputs about these processes.  This can help in a large variety of ways.