X-Mailer: InterCon Dispatcher/SMTP for QuickMail
X-Priority: 4
Newsgroups: bit.listserv.circplus
Date:         Thu, 27 Aug 1992 14:50:21 -0500
              <CIRCPLUS@IDBSU.BITNET>
From:         Loretta Merlo <Loretta_Merlo@QMCUMC.MAIL.CORNELL.EDU>
Subject:      re>overdue notice file
X-To:         BULLETINBOARD CIRCPLUS
              <CIRCPLUS%IDBSU.BITNET@CORNELLC.cit.cornell.edu>

     I can't imagine keeping such a file. What purpose does it serve? We use
LIS here, and we can certainly find out, through a Circulation Trace, when we
sent out a notice, should we ever need to, but I can't remember really needing
to.
    Here (Cornell Medical Library, NYC), we advise patrons up front that the
notice serves as a courtesy reminder only. They are responsible for
remembering when their item is due, and returning or renewing on time. We
print notices every weekday and mail them out through the interoffice mail
system, which is unreliable at best. Often, patrons say they didn't get the
notice, but we still charge them the overdue fine. Not receiving the notice is
no excuse.
    We have been considering changing our policy re> fines. I am looking into
no longer charging fines, but rather a "service charge" based on the
production of the overdue notice, i.e. after 3 days, we produce the first
notice, which will result in a service charge to the patron of, say, $1.50.
The following notice, produced a week later, will result in a similar service
charge, etc. I have envisioned that we might get arguements from people who
did not receive the notice, but again, it's their responsibility. The notice
is a courtesy only, as far as we are concerned.
   On a similar note, we used to keep a registration card file for several
years after we became automated. We updated the patron's card each time we
updated his/her record in the system. I was undecided as to whether or not we
should get rid of the file. So, I implemented a plan to test the need for this
file by having one staff member "secretly" update patron records in LIS
without updating their corresponding registration cards. The staff member, who
worked during the busiest hours and performed perhaps 20-25% of all entries
and updates, coded the system record in such a manner that he and I would
recognize that he had updated that record without updating the registration
card. The other staff members updated both the system record and the
registration card, as was our policy.
    After one year's time, I had not one problem with a patron record which
could be traced to not updating the registration card in the file. No staff
member ever came to me to say that the system record was up to date but the
registration card was not and therfore it caused him/her a problem.
    After that amount of time with no problem, I decided we could dispense
with the card file altogether. We now update directly onto the screen, unless
the patron wishes to write out a new card with the new information on it. For
new registrations, we ask the patron to fill out a card which is then entered
and retained long enough to double check the information, a task performed by
the weekend supervisor. The card is then discarded.
    We have had .01 problems with this system in the past year. Perhaps you
can devise a similar test to verify the real need for your file, but my vote
is to be brave and do away with it.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU