Access Problem Solving (digprob)
Communication Basics in Solving Access Problems
UNDER REVISION 090713
Broken list / Broken icon | Licensed notes field | Major vs. Minor problems
See the Problem Solving Primer for more detailed procedures.
Broken list / Broken icon
For ongoing major problems, an announcement should be sent to the broken list in addition to the person who informed us of the problem.
Resources should not be marked broken in Vera unless you are fairly certain the problem will continue throughout the next day.
If you mark a title with the Broken Icon, be sure to also add a Title Note to explain the problem and how long you think it might take to fix it. Be sure to date your note (no need to add your initials).
Licensed notes field
Record notes about steps taken to resolve problems in the licensed notes field, particularly if ongoing. Record notes in the package-level record if the problem affects an entire package.
Remember to date (include year!) and initial all notes (e.g., 060927 kam)
Major vs. Minor problems
Major Minor A large database or a set of databases
A small database
An entire ejournal package
A single ejournal
Dead-ends, no functionality, from on campus
Limited functionality ("some" content missing; slowness) or dead-ends from off-campus (often a minor licensing issue or certificate problem)
Relaying major problems
Extremely large, urgent problems should be followed up by individuals in all subsequent shifts until resolved, rather than being addressed only when one particular person is available. While the problem is still "owned" by the person who first worked on it (or someone to whom the problem was explicitly delegated), in these cases, it is expected that during time periods when that person is not in the Libraries, someone on each shift should check on the situation to see if there is any update or any needed action that they could perform to keep the problem resolution moving forward. Often, this might mean a call to the vendor to see whether the situation has changed, and an update message to the broken list if there is news to report.
The person who is owning the problem should tell members of digprob in an email message to digprob-admin which shifts will require this kind of supplementary support. [e.g. "I am working on the problem with all of the CSA databases, but won't be in Friday. Can Kim and Marilyn check for any relevant updates and report to the broken list, since this is a very serious problem? I will followup when I am back on Monday."]
Relaying minor problems
Problems that are initially reported during your shift belong to you. You are expected to be the specific contact person for that particular problem until it has been resolved.
If you are unable to address a particular problem for any reason (e.g., it can't be resolved immediately and you are going to be out or very busy for the next few days) ask for help via digprob-admin. If someone can help out, that person will "steal" your ticket and take ownership of the problem for you.