I volunteer at the CYM Library, a music library based in north London, mostly helping with day-to-day jobs. Recently I undertook a project to improve the way that CYM Library records requests and loans and I talked about this project at the IAML UK & Ireland Annual Study Weekend in April.
Background
CYM Library is a collection of vocal scores and orchestral parts that can be borrowed, for a fee, by choirs and orchestras across the UK. We lend both directly to them and via other libraries through the inter-library loan (ILL) system. CYM Library is an independent, self-funding charity. In addition to a part-time music librarian (Ceri Mann) there are several volunteers. I’ve been volunteering there for two and a half years and have a good understanding of how it all works.
Until last October we kept track of music reservations and loans via a combination of Word and Excel files, stored on Google drive, plus paper loan records. We had lists of music on loan and a list of requests that needed action – invoicing, packing, posting. Separate lists recorded invoices and payment details.
This all worked, but there was much duplication of information between the different lists, creating additional work and with a danger that they might get out-of-step. We had no list of all our customers, and generating any statistics was an onerous task.
Project aims
As we considered how to streamline our records, we agreed that any new system should:
- Save time and be less work
- Be easy to implement and use
- It had to be able to interface with shelves/packing/returns. That is, we needed to be able to generate a printed record sheet for each loan.
- It needed to be available anywhere, so we could work on some tasks away from the library if necessary.
- It needed to be inexpensive. We would struggle to find funding for a big system.
I explored Google Drive and Microsoft Office but was unsuccessful in my attempts with these. Possibly that’s down to a deficit in my technical skills, but I also had a sense (from previous experience) that whatever I did with Google or MS Office was going to end up being very clunky.
As I searched for software tools that were both powerful yet easy-to-use, one popped up that I recognised from my previous workplace – Airtable. I thought it was worth a closer look so I started playing with it on a one week free trial and immediately liked it.
Airtable
Airtable describes itself as a ’No-code’ database. This means a platform that allows users to create and manage databases without writing code. It looks like a spreadsheet, and has a drag-and-drop interface. It is cloud-based and very flexible. Airtable was founded in 2012 and is now widely used so there is a large community of users and good online support. It has many integrations with other software packages.
Pricing is based on the number of users, starting at a single user, and there is a charity and non-profit discount. This makes it very affordable for small organisations like CYM Library.
I read a useful eBook – Learning Airtable and registered for an online course which gave me a good grounding in the basics.
New system
My priority was to create a system that would allow us to enter details of a request just once, and then to amend the record as changes occurred to the status of the request. I also wanted to launch the system in a reasonable timeframe, so I deliberately limited the scope of the initial system to managing requests, loans and returns.
We switched to the new system on 1 October 2024, though I had been recording data in the new system from 1 May 2024.
The two key tables in our database are Customers and Requests, with a few others used occasionally.
The customer table currently has 230 records, and is still growing. It records names of borrowing organisations and the contact person, plus any contact details. We also record the type of borrower (orchestra, choir, public library, school etc).
The request table has more than 70 fields. That’s a lot of data to scroll through on a screen and would be unwieldy to work with but Airtable allows you to create different ‘views’ of your data.
When you create a view you can filter the records by one or more fields, eg to show only requests that have been confirmed and need an invoice to be paid. You can also hide fields that are not of interest at a particular point as well as sorting the records in a view. Thus you end up with a view that shows key fields from the requests that need some action to be taken. Updating a record in one view updates the underlying database, so any changes are reflected in all other views too.
We have created about a dozen different views to match the various processes through the lifecycle of a request.
The first stage is to enter the details of a new request – composer, title, edition, number copies, dates needed (from and to), customer, quotes for charges (price or number of BL forms). There is a view that makes this straightforward, and also a form that can be used for the same purpose.
When a customer confirms they wish to proceed with the request, we then change the request status from Provisional to Confirmed and we print out a loan sheet from Airtable. It was important that we could generate a piece of paper for each loan, so that key details would be available when we’re at the shelf picking copies, at the packing desk, or at the returns desk.
Airtable’s Page Designer tool lets you create a printable version of a record and is very flexible. You can choose any fields, and position them in boxes wherever you want on a page. Then you can format the text in the box, add more text and images.
The Request Tracking view shows confirmed requests and what stage they’re at – invoiced, whether paid, packed, etc. as well as whether the music is to be posted or collected. Some loans are booked well in advance, so this helps to keep track of what needs to be done when. Different colours in fields provide helpful visual clues.
The list of current choral loans and reservations, shows alphabetically by composer/title what choral sets are out on loan or provisionally reserved, and when they are due back.
Some of the fields are formula fields, derived from a number of other fields. Sometimes I’ve used these to make the lists easier to read, other times there is some calculation or logic involved – eg calculating prices. The formulae look a bit scary, but I quickly learnt how they work. It’s a great feature of Airtable.
Results
We made the changeover with no noticeable affect on the service and broadly speaking we’re happy with the result. It is easier for us to record a new request now. It is easier to follow a request through different stages and change its status. The information is all brought together in one place and we don’t need to keep opening different files, using different programs. Claims to the BL for ILL payments are easier – we’ve just done our second batch of these.
We will be generating annual statistics soon, and I expect it to be easier than in the past (fingers crossed). As time goes on I think we will gain new insights from analysing data about our loan activities.
Printing out packing sheets (equivalent to the old loan sheets) has worked well, though we have needed to tweak the format and layout a few times.
The database is accessible anywhere – from the library or when working from home. It is also available via the Airtable phone app if necessary.
We have only needed one userid so the software cost is manageable. It was a bit of a hassle to get validated by Airtable as a charity, but worth it.
We have already found some additional benefits of having an up to date customer list. It allowed us to identify new customers and add their email addresses to an email group that we send updates to. We’ve also been able to start centrally recording the postal tracking details for parcels of music that we send out.
Challenges
Switching to the new system was a bigger challenge than anticipated – it took several weeks to get used to how it works. It’s a cliche, but more time for training in advance would have helped.
We’ve had to devise some workarounds to cater for non-standard requests — time extensions, additional copies, discounts. The basic data structure though has proved to be solid.
Reports are not as easy as I’d expected, though data can be exported to Excel for more analysis. The Page Design feature is cumbersome.
Though the community of Airtable users is large, not many of them are libraries, so the support forums tend to deal with more business-focused applications. It would be good to find other libraries who are using Airtable.
Future developments
We have some new volunteers and I plan to give them Airtable training. I hope they may have ideas for improvements that we can incorporate into Airtable.
I would like to automate some operations, such as calculating prices and parcel weights, and generating invoices. I’d also like to create a webform on the CYM Library website, for requestors to enter new requests. This could feed straight into our Airtable database. A next step would be to integrate the catalogue into the webform.
A bigger challenge would be to expose part of our Airtable database via the CYM Library website, making it into a ‘live catalogue’ that shows the availability of copies.
Conclusion
It is possible to use a general database tool (no-code) for record keeping in a music library.
No-code databases are much easier to get started on than traditional database products.
