The procurement meeting had all the familiar ingredients: a vendor demonstration, a tidy estimate of staff time saved, and an inbox full of repeated questions. The neighbourhood library was not imagining its workload. People asked about renewals, opening times, reservations, passwords, and account notices every day. An AI assistant appeared to offer a sensible shortcut. Then the service manager put the comparison sheet aside and asked the room to complete a problem card before discussing any product.
The card was deliberately plain. It asked for the need, the people affected, the harm the library would not accept, the evidence still missing, and a non-technical alternative. That sequence mattered. “We need AI to reduce repetitive work” can sound like a decision, but it is not a description of a service failure. It cannot tell a team which repetition should disappear, which one needs a clear rule, or which one contains a judgement that should remain with a person.
Begin with a situation someone can recognise#
The first version of the card said: “A member waits too long to understand whether they can renew a loan after receiving an unclear notice.” That is more useful than “automate customer service.” It identifies an observable wait, a specific action, and a current failure. It also refuses to make a tool the centre of the story. The library might later choose automation or an AI service, but the member’s confusion is the thing that must improve.
The first version of the card said: “A member waits too long to understand whether they can renew a loan after receiving an unclear notice.”
This wording led the team to inspect recent messages rather than rely on a sales forecast. They found requests that looked similar in a spreadsheet but were different in practice. A question about a holiday opening time could be answered from an approved public source. A message saying “my account is blocked” might concern a forgotten password, a disputed fee, a problem with a contact detail, or a failed verification step. Treating all of these as the same kind of repetitive work would make the purchase look simpler than the service actually was.
The card also required a measure that was not merely speed. The team recorded the time to the first useful next step, but also whether the member had to contact the library again, whether the response could be used with assistive technology, and whether staff later corrected it. A fast message that sends someone into another loop is not a resolved enquiry. It is work moved from one place to another.
A scene from the returns desk#
One librarian described an email that contained only three words: “it will not let me.” A classifier might label the message as an account issue and send a polished reply. When she called the member, however, she learned that the person had changed phones and could no longer receive a verification code. The immediate task was not a loan renewal at all. It was a careful account-recovery process.
That small scene changed the affected-people section of the card. The purchaser is not the only person who matters. There is the member with a slow connection, the person using a screen reader, the parent writing quickly between shifts, the visitor working in a second language, and the staff member who inherits an incomplete conversation. If an assistant saves internal minutes while asking the member to explain the same situation three times, it has not removed friction. It has reassigned it.
The library avoided broad labels such as “vulnerable user.” Instead, it named circumstances that could be tested: someone unsure whether an email is safe to answer; someone who cannot interpret an automated notice; someone who needs acknowledgement after hours but not a final decision. This is more respectful and more practical. It points towards a service design choice rather than an assumption about a person.
Compare three ways to reduce the repetition#
The first option was to repair the service that generated the question. Staff rewrote the renewal notices, added examples beside the most confusing instructions, and made the online form ask whether the person needed to renew, understand a notice, or regain access. None of this is artificial intelligence. It is still a serious option because an unclear message can create hundreds of avoidable contacts. Its costs are editorial work, accessibility checks, and maintenance, not a subscription fee.
The second option was rule-based automation. The library could send approved replies for opening hours, collection deadlines, catalogue links, and other questions with stable answers. A rule can be inspected: staff can see what triggered it, update it when policy changes, and route a non-matching case to a colleague. Its limitation is honest rather than embarrassing. A rule should not pretend to understand ambiguity that it cannot safely resolve.
The third option was a constrained AI assistant. It might summarise a long message for staff, suggest a draft that is never sent automatically, or identify a missing detail that the member could supply. The problem card excluded more consequential uses. The assistant would not decide whether an account restriction was justified, infer a person’s intention, or give a final answer where a decision could affect access to the library. It would need an editable output, a clear record of the information used, and a handoff that did not erase the conversation.
Putting the three routes side by side stopped the team from treating AI as the default high-tech answer. A repeated task can be removed by clearer design, handled by a transparent rule, or supported by a supervised model. The useful question is not which option looks most advanced. It is which combination reduces avoidable work without creating a harder error for someone else to repair.
Define unacceptable harm before testing benefit#
The card’s most demanding field was the one about acceptable harm. It was not an invitation to make mistakes acceptable in the abstract. It asked what would happen after a mistake, who would bear its cost, and whether repair would be straightforward. An incorrect opening time can usually be fixed quickly when the response links to an official page. A false statement that a member’s account is suspended can cause embarrassment, a wasted trip, or a decision not to seek help again.
The library set three boundaries. Public information could be automated if it named its source and review date. Account questions could provide verification steps and an easy path to a person, but could not state an unverified cause. Decisions involving children, personal records, or restrictions on borrowing were outside automatic responses altogether. These are service commitments, not temporary technical shortcomings waiting to be overcome.
Repair was written down too. A member who received a wrong answer should reach a person without starting the story again. Staff should see the original message, the suggested response, and the rule or information that produced it. The team should group corrections to find systemic patterns. If many people misunderstand the same notice, improving a model may be less responsible than fixing the notice itself.
Missing evidence belongs on the same page#
Procurement documents often ask teams to predict benefits with confidence. A useful problem card gives equal space to what they do not know. The library admitted that it did not know how many enquiries disappeared after clearer wording, which languages needed the most support, or how many people abandoned a renewal because the first screen was confusing. Those gaps were not a reason to rush into a purchase. They were the design brief for a small, reversible trial.
For two weeks, staff logged de-identified cases: where the request began, what detail was missing, how long resolution took, whether a correction was needed, and what happened next. They added one voluntary question after an interaction: “Did this answer let you take the next step?” The results were revealing. Many messages followed a notice that was short but unclear. One of the highest-impact changes was a concrete example and an account-recovery link, not a new conversational system.
The team did not rule out an AI trial. It made one conditional. AI could help staff prepare internal drafts for complex language, under human review and with no automatic decision. It would be compared with the redesigned pages and the rule-based replies. Success would include fewer repeat contacts, fewer corrections, and a reliable recovery path, not simply a larger count of processed messages.
Buy a decision trail, not a black box#
At the end of the meeting, the library did not sign a contract or reject every AI product. It approved better notices, four rule-based replies, and a limited pilot with an end date. The procurement record included the problem card, the assumptions to revisit, the people responsible for review, and the reasons particular uses were prohibited. That record makes the decision explainable to staff and members who were not in the room.
It also makes revision easier. When a vendor announces a new feature, the library will not have to choose between enthusiasm and fatigue. It can return to the wait it wanted to reduce, the harm it refused to transfer, and the evidence it promised to collect. If the feature helps under those conditions, it has a case. If it does not, the team has a reason to leave it out.
Before requesting your next AI demonstration, take one recurring task from your own workplace and write five short statements: the observable situation, the people affected, the harm you will not accept, the evidence you still need, and one non-technical alternative you can test this week. If AI remains the strongest option after that exercise, you will be buying a bounded and reviewable service. If it does not, you may solve part of the problem before turning it into a licence.
