Organization Monkey

http://0-sq4ya5rf2q.search.serialssolutions.com.linus.lmu.edu/?&url_ver=Z39.88-2004&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.atitle=Review%3A%20Analysis%20of%20the%20evolutionary%20convergence%20for%20high%20performance%20swimming%20in%20lamnid%20sharks%20and%20tunas&rft.auinit=D&rft.aulast=Bernal&rft.date=2001&rft.epage=726&rft.genre=article&rft.issn=1095-6433&rft.issue=2-3&rft.spage=695&rft.title=Comparative%20Biochemistry%20and%20Physiology%20Part%20A%20Molecular%20and%20Integrative%20Physiology&rft.volume=129A&rfr_id=info:sid/www.isinet.com:WoK:BIOABS&rft.au=Dickson%2C%20K&rft.au=Shadwick%2C%20R&rft.au=Graham%2C%20J

there’s an extra “a” in this url that is causing it to not resolve, thus leaving our patron with an error instead of full text.  the extra “a” is after the volume; there isn’t a volume 129A, only a volume 129.

:/

we’ve lately felt as if we’re spending more time troubleshooting our library’s licensed e-resources.  saying “i feel like i’m spending a lot of time on this” doesn’t really cut it when it comes time to staff a task appropriately so we’re making an attempt to quantify our process.  knowing how much time we’re spending will tell us if we’ve got enough people tasked with the responsibility of responding to patron problem reports, since providing timely customer service is part of our mission.  enter: gimlet.  gimlet is usually used to count reference desk transactions so you can see how it can easily be adapted to count other kinds of service point interactions.  for example, the reference department gets emails requesting assistance for troubleshooting a research question, my department gets emails requesting assistance for troubleshooting e-resource access.  since our reference department already uses gimlet, we thought we’d give it a try too.

setting it up was super easy.  there are five categories built in to the system, and you can define the variables that fall under those headings.  the five categories are: duration; question type; asked by; format; location.  under the heading of duration we added the variables: 1 interaction, same day; more than one interaction, same day; 1 interaction, next day; more than one interaction, next day; more than two days.  tracking how long it takes to resolve a problem, and how many interactions with the patron it takes to get the information we need, will help us to understand the complexity of the problems we’re troubleshooting.  often we can get what we need from the patron with one interaction and get the problem resolved in one day, but sometimes it can drag on for weeks.  being able to count how often we can quickly respond and how often the problems lag will be instrumental for not only identifying our own staffing needs but can also point to how we evaluate timely vendor responses.  if we’re waiting on a vendor to fix something and they consistently take more than two days, then we may choose not to work with that vendor in the future.

here are the other categories and the variables we’ve entered.  question type: user interface problem; patron education; broken URL; expired subscription; incorrect coverage listed.  asked by: faculty; student; librarian; staff; alumni; law school; visitor; other.  format: email; phone; walk-in; referral; roving ref; text chat.  location: on campus; off campus.

we’ll be adding tags for the names of resources that are reported as problematic so we can get an idea of how many times an ebsco database goes wonky, for example.

we’ll be experimenting using the READ scale (shown as Difficulty in the screen shot) to help us assess the complexity of the questions we’re asked.  stay tuned for more on that later.

you can see from the screen shot that our database is a blank slate, ready to have questions asked and responded.  i’ll report back later to let you know how it’s going!  in the meantime, if you use gimlet to track the troubleshooting of e-resources i’d love to hear from you.

i can’t write this blog post without a nod to george carlin, whose famous bit about “stuff” comes to mind as i’m thinking about a place to put our library’s “stuff.”  “stuff,” in this case, is our perpetual access holdings data for e-journals.

here’s our thinking so far on this topic.  getting the information about which electronic journal volumes we own forever was a difficult process, but an important one.  now we have an inventory of what we own, but the inventory is on an excel spreadsheet.  looking up an e-journal title in our catalog and then needing to refer to an external spreadsheet is a drag, and we think it would be preferable to store this information in our catalog with the rest of our inventoried collection.  where in the catalog to store the information, though?  we considered putting it an 8XX field of the bibliographic record but were swayed from that since those aren’t protected fields and can _so easily_ be overlaid.  we then considered putting the data in MFHD, but that format doesn’t give us the flexibility to call out that certain volumes may be available perpetually from one provider, whereas other volumes are available through a different provider.  we’re now considering creating item records for this data, so that we can enter the volumes/years available, as well as the provider for that perpetual access.  we’ll attach as many item records as necessary to a title so that the perpetual access holdings data is completely described.

what do you think about this?  where are you storing your perpetual access holdings “stuff”?

carlin on youtube: http://www.youtube.com/watch?v=MvgN5gCuLac