Reading through the postings on the TalisMessage forum about returned messages, pecking order, and the release notices and articles on the TDN by Brian Crampton, concerning borrower notification preferences, (http://www.talis.com/tdn/node/836) the focus of all this seems to be falling short. Are Talis and Talkingtech looking towards a more integrated approach that would take into account e-mail and other new forms of alert? The articles on the TDN and the work that lies behind it, are admirable as far as it goes, but they do not, as Brian admits, include all scenarios. To begin with, the order I would choose is not included, which is Email - Telephone - Post. This is not possible using the current suite of notification scripts. Our investment in notifications is huge, in postal charges, stationery, contracts with print units, and particularly in regard to capital outlay required to set up the telemessage infrastructure. Libraries need to recoup this investment by streamlining the notification process to minimise costs and provide an efficient messaging system. Sending e-mails first (free) then voicemail and SMS and post as a last resort, would give more hope of reducing costs.

But why have any ‘pecking order’? Running three scripts a night to send notices by TalisMessage, then Email, then Post, consumes valuable machine time offline on the ‘live’ Talis system. For a very large system such as Lancashire’s this represents a serious issue - but even if time is not such a critical issue for others, the need to run three scripts for overdues and another three for reservations is surely a very inefficient way of handling this? What is really required is a radical shake-up of the concept of notifications and a method of flagging transactions for a notification, referencing the borrower’s notification preference and dealing with the transaction accordingly to generate simultaneous notifications by whatever method has been recorded as the preference; optionally adding an associated charge to the borrower’s account at the same time, appropriate to the type of notification generated.

The analysis codes don't hold the entire key as what is really required is a single transferable vote not a first-past-the-post system. Failed messages by one method should automatically progress to the second and third methods without recourse to re-setting the database and re-running them. Users already experience too much postal delay. At least there should be an additional analysis code to distinguish voicemail from SMS message; retaining the use of the T or V prefix is undesirable since it represents a misuse of the field and viewed strictly should be classed as data corruption, as is the addition of ‘mailto:’ in the email field of the borrower’s record. (It is fairly simple to add the ‘mailto:’ text into the format.pl of the notice script, but it again means putting an element into a notice designed as a letter to create something to enable other notification methods to operate.)

Is there still a need to produce output files formatted for A4 letter or datamailer, when Microsoft gives mail merge facilities and most printing services use design software such as ‘Formscape’ which can format fields into customised datamailers. The TalisMessage script only outputs the basic data for processing by voicemail – why not for post and email too? Equally the database itself should enable instant alerts to users when items are about to become overdue, or recalled, or requests become available for collection. In the age of the Talis Platform and Web 2.0, Apple’s as yet un-named revolutionary new ipod-cum-phone and Microsoft’s Sandbox, isn’t the whole concept of an offline notification system an anachronism? But since we still have users who aren't equipped to take advantage of new developments, if there has to be an offline process it should only pass through the database once!

I couldn't agree more. You've managed to put in to words something that has been going through my mind in various stages for ages. I've recently finished setting up Talis message outbound which I found to be quite a complex task. I can't fault the support and assistance I got from both Talis and Talking tec but I couldn't help feeling it shouldn't have been that complex in the first place.

I've begun to look at emails but I have to admit I'm actually pleased I'm too busy with Lyra to start trying to make email work and that in itself says a lot about how I feel about it given what a task Lyra is.

Leeds too has a lot of data and the scheduling of all these scripts overnight took ages and I pitty anyone who else who would have to maintain them in future if I weren't around despite my efforts to document it all.

I really hope Talis take your comments on board, perhaps the new Talis reporting stuff is part of moving this forward.

We currently use TalisMessage and Letter overdues/reservations. You really hit the nail on the head because we would like exactly the same pattern of notification. We have also asked that some sort of identification was given to the dates shown on Alto so that we knew quickly whether it was TM or letter (or email if we had that!). We would also like something in the reservation screen that denoted a phonemessage or letter - it's a pain when there is a dispute over a phonemessage or letter being delivered - it can be quite timeconsuming going through the log files. Sharon