So you need to develop a workflow to resolve an issue but you are not sure where to start?  The following is an 8 step strategy for defining how to resolve an issue.  As long as your workflow encompasses these stages you are probably good to go.  There are always exceptions but these guidelines are a good starting point.

Identify the issue – You need some process or tool that provides the capability to identify what issue you are trying to resolve.  This could be customer focusing but don’t forget about your own employees.

Classify the issue – Ok so what sort of problem are we dealing with?  Is it a software bug, an enhancement request, a customer question, or a flat tire on a school bus?  Classification allows you to determine which workflow should be assigned and directs the issue to the appropriate group or process.

Rank the issue – All issues are not created equal. Say it with me, “All issues are not created equal!” Now that does not mean that any of them should be ignored but it does mean that a problem that has caused your sales to plummet 80% should have more weight than a problem regarding the soda machine in the cafeteria.  Develop a simple but yet flexible weighting scheme a lot of software companies will use a critical, high, medium, low scale while a lot of retail organizations may choose a numerical scale such as 1-10.

Assign roles and responsibilities – This is an important step that’s often overlooked, a good example is when you send an email asking a question and you put ten people in the To: list of the email and label the subject “can you please do this.” Don’t know about you but this doesn’t usually yield a lot of productivity for me, typically I get no responses.  You have to develop a process of accountability with each workflow, make sure each person associated knows what he/she is required to do as part of the process.

*Note – Talk to the team members they know their jobs and where they can best help, maybe you can streamline the number of people required.

Assessment – The team on the other end needs to know what to do with the issue, are they supposed to have a meeting to discuss the best course of action or simply pray to the senior management and await a sign from above.  I have seen both methods work but I typically recommend the more structured path to start.

Recommendations – The team should be instructed to provide a resolution or several possible resolutions to the problem with some pros/cons of each.  From those recommendations a business decision would be made of the best path. 

*Note – The assessment and recommendations stage can sometimes happen at the same time assuming that a representative from all responsible teams is present.  For software developers that might be development, marketing, and sales.  For a municipality that might be someone from city planning, finance, and other relative departments.

Call to action – Once the decision has been made there has to be a way to kick off the work.  This is usually a transition from one stage of the workflow to the next or in technical jargon a workflow state change.  This could be a simple email or as elaborate as your process requires but the point is to make sure all the relevant data and expectations are communicated clearly.

Closure and communication – Alright were done, so what now?  We need some step here to notify the relevant stakeholders of the completion.  In a lot of cases this would just be an email but in others it will be the starting point of your next workflow.  For example the issue might have been a problem with our product documentation so we have fixed the problem but who is responsible for posting the document to the web or reworking the product CD image so that the proper revision is available.  For some organizations this is someone’s job and a workflow is not required but for some larger companies this is another process altogether.