Problem Reporting/Tracking

Gather common data

• Comparable forms which are set to gather common data
  OR
• Separate email aliases, as we have now, which are set to push email to a common tracking system.  The tracking system would then ideally give IP, DNS, Browser/OS, Referring URL.  Are most tracking systems set up to be able to get this information, or will we need to use a form to gather the data and send it along to a tracking system. 
• If permissions are not sent to the tracking system, we may need a procedure to look them up.
• Cornell is revamping "feedback" forms as part of Discovery & access initiative.  Opportunity to influence what is gathered from users here as most "feedback" is a troubleshooting issue.  How to handle non-affiliated users?

How do we ingest and manage issue reports?

• Ingest problem into common tracking system (e-mails or actual issue management system)
  • Pros/cons of options
  • Decision to pilot X?
    • Proposal to Steering
    • What variables to account for: number of user accounts, desired premium features,...
  • How did X work?  What needs to be changed?  Should we try a different system or will X work?
  • Auto-response, excluding personal details and/or copying others
  • Database?
  • Ability to attach screenshots - during initial submission and as parts of responses

• What changes at each CUL required?  i.e. Cornell does not gather some of the user info that Columbia does via form.
  • What info is most useful or essential?  IP/DNS, patron permissions?, Browser?, Referring page

Solving and Responding to Problems

Access to each others systems and information

• Ordering/Payment info - Voyager, EBSCOnet, etc.
• ERMs
• Access to one another's e-resources from "on-campus" (VPN) and "off-campus" (remotely) -
  • Our work is considered "doing the business of XXX University"? Right?
• Is there a need to inform vendors that this group may be working on each others issues?
• Will remote desktop cover Voyager access well enough?   Is there something better?

Begin joint troubleshooting on (goal:Spring 2014) - Target Date: XX/XX

• Common types of issues:
  • Site down/deficient
  • Site requires particular action or browser
  • Browser problem
  • Payment problem
  • EZ-Proxy
  • URL changes
  • Abuse/excessive downloading
  • User permissions and exceptions - does user have valid permissions?  Is there some other block on their NetID/Uni?
• Policy vs. Technology workflow decisions?

• What issues immediately go to home institution?  this list needs to be well-defined, as it can cause political headaches if handled incorrectly
• What can be handled jointly?
• What must wait until X system is better integrated?
• Need to assign point people at each institution to take questions from staff if we run into gray areas about who handles what problems - who and how to escalate or route.
• Define schedule

Training and Transition

Common responses and procedures - wiki?

• Get current information organized in similar way
• Merge as appropriate and/or create common dashboard
• Proper permissions for access
• Any vocabulary to sort out?  Uni/NetID

All staff looking at each others issues - milestone - how long does this need to go on before we move to next phase?

• Period of training/adjustment for each CUL as staff adjust to the new tracking systems. (This is a public service; it should be done well!)
• Able to respond to each others lists & assign issues within the tracking system.

Phases

• Team looking at reports - currently happening
• Team responding to lists/each other, if they have useful input - currently happening
• Team researching and responding to issues - next step
  • Look for - do we have access to the right information, does that access work well?
• Repeat these steps with broader troubleshooting staff -

Possible Issues to Address

• Union issues?
• Privacy issues?  includes staff - are we violating any privacy concerns at each institution; also includes any third party systems we might use for tracking - can we purge/anonymize patron data
• Vendors working with one CUL on the other's behalf, i.e. we're no their "contact of record"