A reader finds the title needed for a research project, copies its reference and begins planning a visit. From that reader’s perspective, the search is useful only if it leads to a realistic next step. A catalogue can describe a collection accurately while the systems used to request, retrieve and consult its contents remain limited. Restoring discovery is therefore an important achievement, but it is a specific achievement with a specific boundary.
On 16 January 2024, Euronews reported that the British Library in the United Kingdom had restored its main online catalogue in read-only form after the previous year’s cyberattack. That limited return provides the starting point for this analysis. The discussion below concerns how a research institution could organise and explain a staged recovery; it does not claim to describe the library’s internal procedures.
Start with the task a reader wants to finish
A system inventory might list a website, a catalogue, a registration service and an ordering application. A reader usually has a different list: identify a source, establish whether it is relevant, arrange access, consult it and record a usable reference. The two lists overlap, but they are not interchangeable. An institution can restore several applications without allowing someone to complete that sequence. Conversely, staff assistance may make part of the sequence possible before every application returns.
This suggests a practical way to describe progress. Instead of announcing only that a component is online, explain the task it now enables and the conditions attached. Searching a record is different from viewing a digital reproduction. Recording a request is different from accepting it. Accepting a request is different from confirming that the object will be available at a particular desk. Clear verbs give readers a much better basis for decisions than a single general statement that services are returning.
The distinction also helps internal planning. If discovery works but requests cannot be processed, the immediate constraint lies beyond the search interface. If requests are accepted but retrieval is slow, adding another search feature will not remove that delay. Mapping the reader’s sequence makes it possible to locate the point where work accumulates, rather than treating every unfinished technical task as equally important to access.
A record and an available object answer different questions
A catalogue entry establishes that something has been described. It may contain a title, creator, publication details, a reference and notes that distinguish one item from another. Availability is a separate statement about whether and how that item can be consulted under current conditions. Combining these statements without qualification risks making a stable descriptive record look like a live promise of service.
A useful recovery interface would preserve that distinction even if its design is simple. The descriptive information could remain visible while the access message states which request route applies. Where current availability cannot be confirmed electronically, the page could say so and identify the appropriate enquiry route. This is more informative than either removing all records or displaying a reassuring availability label that the institution cannot support.
Readers should also be able to tell whether an absent result means no matching record was found or whether the search covers only part of the collection. These are different conclusions. A researcher who mistakes a temporary coverage limit for proof that a source does not exist may abandon a useful line of enquiry. Coverage information therefore belongs near the search task, where it can influence interpretation, rather than only in a general recovery notice elsewhere on the website.
Measure the transition between stages
Counting searches can show that a restored catalogue is being used. It cannot by itself show that research access has been restored. A more useful operational view would follow transitions: searches that lead to a sufficiently identified item, enquiries that become valid requests, requests that receive a decision, and accepted requests that result in consultation. Each transition has its own possible failure or delay.
Consider an entirely hypothetical week in which staff receive 100 enquiries and can convert 60 into requests with adequate identifying information. If 40 of those requests reach consultation, it would be misleading to describe either all 100 enquiries or all 60 requests as completed access. The numbers represent different stages. They are not estimates of the British Library’s workload or performance.
The remaining cases need explanation as well as counting. Some may be awaiting clarification, others may concern material outside the currently supported service, and others may have been withdrawn by the reader. A single unfinished total hides these distinctions. A short set of meaningful statuses would let managers see where assistance, clearer instructions or additional retrieval capacity might have the greatest effect.
Design a temporary request route around real staff capacity
A manual or assisted route can reconnect readers with a collection, but it also creates work that an automated process may previously have organised. Someone must read the request, identify the item, check the relevant conditions, communicate a decision and keep a record of what happened. Opening an inbox is therefore only the beginning of a service design. The organisation must decide who owns each request and how it moves between teams.
Duplicate requests are a foreseeable difficulty. A reader who hears nothing may send another email or ask at a desk. If the two contacts enter unrelated lists, staff can spend time investigating the same need twice. A reference number and a simple acknowledgement can help connect those contacts. The acknowledgement should say that the enquiry was received, while reserving confirmation of availability for the point at which it has actually been checked.
Capacity should shape the promise made to users. If a team can reliably process a limited range of requests, a clearly defined service may be more useful than an expansive promise followed by unpredictable delays. This does not mean concealing unmet demand. Recording unsupported requests is valuable evidence for deciding what to restore next, provided that recording them is not presented as accepting an order that cannot yet be fulfilled.
Use a few fields that prevent expensive ambiguity
A temporary form should ask for information that helps resolve the request, without turning the reader into a substitute cataloguer. The central question is which missing detail would force staff to stop and ask again. In many hypothetical workflows, that might be the item reference, the desired date of consultation or a way to contact the requester. The precise fields depend on the collection and the service being offered.
- Identify the requested item using the available catalogue reference.
- Distinguish the preferred visit date from a confirmed appointment.
- Give the reader a way to correct or withdraw the request.
- Record who is responsible for the next decision.
- Keep receipt, acceptance and readiness as separate statuses.
These fields should support a conversation rather than demand impossible precision. A reader may have a partial citation or be unsure which edition is relevant. The route should make that uncertainty visible so that the request goes to someone who can help, instead of silently treating incomplete information as a normal retrieval order. Good triage saves time by distinguishing a discovery problem from a delivery problem.
Make the cost of uncertainty visible to the reader
For someone planning a visit, an uncertain result can have consequences beyond an unanswered email. Travel, accommodation, time away from work and a research deadline may depend on whether the material can be consulted. An institution does not need to promise success in every case to be helpful. It needs to communicate what has and has not been confirmed early enough for the reader to adjust those plans.
A status page could distinguish a general service update from an individual confirmation. The former explains which routes are operating; the latter answers whether a particular request can proceed. Confusing the two encourages a reader to infer that a broad reopening announcement guarantees their own visit. Repeating a short, consistent distinction in acknowledgements and request pages would reduce that risk without requiring a long warning on every screen.
There is also value in stating the next expected communication. Even when a final answer is not ready, a defined follow-up point gives the reader a reason to wait rather than start again through another channel. If that point cannot be met, an updated message is more useful than leaving an old estimate in place. Predictability can improve before the full service has recovered.
Preserve the reference through every handover
During a staged recovery, a reader may move between an online record, an enquiry form, an email and an in-person conversation. Each handover creates an opportunity to lose the connection between the original description and the requested object. A stable reference, carried consistently through those steps, is therefore a small but valuable piece of operational continuity.
This is not an argument for copying every field into every system. It is an argument for retaining enough identity to explain which item and which request are being discussed. Two editions with similar titles, two volumes in a set or two parts of an archive can otherwise become indistinguishable in a shortened message. Staff need a route back to the fuller description when the abbreviated reference is not sufficient.
Corrections deserve the same care. If a reader changes the requested item after receiving advice, the record should show that the request changed rather than leave several contradictory versions circulating. The relevant question for the next team is not merely what the reader first asked for, but what has now been agreed. A clear handover protects both staff time and the reader’s limited opportunity to consult material.
Test a complete journey before expanding the promise
A restoration test can begin with a realistic task rather than a successful page load. Imagine asking a tester to find a specified edition, submit an eligible request, understand the response and arrive knowing what to expect. Observing where that person hesitates would reveal gaps that a technical check of each component might miss. The example is a proposed test method, not a report of an exercise conducted by the library.
The test should include less straightforward cases. A record with several related items, an unsupported request and a reader who needs assistance can each expose a different weakness. A system that works only when every field is perfect and every request is eligible will create hidden work as soon as normal variation returns. Recording these cases makes the limits of the restored route explicit.
Success criteria should include the quality of the explanation when access cannot be provided. A clear refusal or redirection can be a correctly completed service interaction even though it does not result in consultation. By contrast, a request that disappears without a decision is not complete simply because the form accepted it. Recovery testing should therefore examine both successful access and understandable outcomes for other cases.
Plan how temporary work will be reconciled
Temporary arrangements create records of their own. When a more complete system becomes available, outstanding enquiries, accepted requests and completed consultations may still sit in earlier lists. A transition plan should decide which records need to move, which can be closed and how staff will prevent the same request from being acted on twice.
The change should also be intelligible to readers. Someone who has already received a confirmation should not have to guess whether a new interface invalidates it. A short instruction can explain whether existing requests continue, need checking or require a specific action. The answer may differ between categories, but it should be explicit before users begin resubmitting everything in an attempt to protect their place.
Keeping every temporary procedure indefinitely would create a different problem: parallel routes with unclear authority. Retirement criteria matter alongside launch criteria. Once the permanent route reliably handles a category of request, the institution can close the corresponding temporary route while preserving a way to resolve older cases. That is part of completing the recovery, not merely administrative tidying after the technical work.
A useful final check is to ask a colleague unfamiliar with the temporary arrangements to explain the next step from the reader’s message alone. If the colleague cannot tell whether to wait, clarify a reference or attend a confirmed appointment, the communication still leaves an operational gap.
Describe recovery as restored capability
The return of a searchable catalogue is valuable because it restores a concrete capability: readers can again discover and identify material through that route. Its value does not depend on pretending that every later step has returned at the same time. A precise account of partial recovery respects the work already completed and gives users a practical basis for deciding what to do next.
The wider lesson is to connect each technical milestone with an observable reader outcome. Search, request, decision, retrieval and consultation form a sequence whose weak points can be investigated separately. An institution that explains those boundaries, tracks unfinished work and tests the whole journey can make progress understandable even while limitations remain. For the reader, recovery becomes meaningful when a promising catalogue result leads to a clear and dependable next step.
Source: Euronews, 16 January 2024.
Sources: Euronews.
Leave a comment