Help Desk Measures

Background

In May 2009, the reorganization of CSS lead to a revamping of responsibility for process measures, namely to export more of the responsibility for collection to the relevant manageriate, as well as more belief in their meaning.  This forces a renewed attention to documenting the tools and processes used in collection and analysis, as well as a reconsideration of what exactly is getting collected and reported.  The Help Desk is first.

Near-Term Goals for Help Desk Metrics and Reporting

• increase local responsibility for the act of measuring.  (Rob practices letting go; Barbara Johnson takes more responsibility; both work more collaboratively.)
• increase local ownership of the meaning of the numbers.

Components of how this will look...

1. Position the collection and reporting tools for easier collaboration. 
   Rob's laptop now owns all the files; yes, backups are made.  A shared filesystem would be a better idea -- the Help Desk does not run a fileserver, Barb G says, so we'll rely on AFS until they do.  Quota is a concern.
2. Switch from RT-export to Warehouse-export for dashboards and for monthly case-analysis. 
   Resolve to just live with the reduced reporting capability for certain variables, and enjoy the enhanced reporting of certain others (that the help desk arguably would find more useful anyway).
3. Document / Diagram the locations, paths and processes where data is generated, recorded, reported. 
   Draw arrows and make labels.
4. Redefine Metrics and Measures with buy-in from current HD Leadership
   Play out the Measures Architecture model for all the variables reported on. 
   Help Desk Measures Inventory will help us here.   Let it document what the Warehouse report can do for us.
5. RT-to-Warehouse-ify the client satisfaction survey process.
   Looking to achieve a one-click in Brio extraction of the ticket data, then paste the whole schmiel into Excel and it autoparses the tickets by relevant queue, generates the scripting statments that will send the appropriate emails.  This methods lets us sustain the differentiated surveys, which is an asset of the process as we can customize the survey form to the line of business.
   

Goals

By the end of FY09 (end of June, 2009) the weekly surveys for all IS&T queues should use one extraction engine based on the Warehouse ticket report.  Ideally there is one survey web form.  The survey spreadsheet will know queue the ticket came from and use that to drive the reporting out in a series of cascading pivots.  Hmmm -- I can build that part first. 

By the end of FY10 Q1 (end of August 2009) a new help desk quarterly reporting metrics engine will be driven by the RT-to-Warehouse reporting path, will be well-documented and broadly shared with Help Desk staff, and perhaps largely operated by Help Desk staff. 

By the end of FY10 Q2 (end of December 2009) the rt-ticket-transaction-detail report would be used to track new behavioral characteristics of the help desk, in particular the pattern of escalation  from the HD to others, and histograms of the interactions in a ticket like the number of emails exchanged.

By the end of FY10 Q1 (end of August 2009) the client satisfaction survey engine will be optimized such that a common survey process is used for as many queues as possible, with Excel managing the division of results by queue and issuing special reports, much as the "etc surveys" sheet works now.  This should save important amounts of time each week and ensure a more broadly applied feedback mechanism.