The first time the neighbourhood association used a tool to sort requests for its rooms, nobody said it was making an important decision. They only wanted to stop reading thirty emails every afternoon. The system suggested an order: activities with the largest expected attendance first, then those booked earliest, and difficult time requests last. Within days, the conversation group for recently arrived neighbours could no longer find a slot. There was no bad intent and no spectacular breakdown; there was a convenient rule that nobody had put into words. That is a useful place to begin understanding algorithms that recommend and decide: not as a mysterious force, but as a way of setting priorities that can help when we know how to inspect, discuss, and correct it.
Turn a concern into a small question#
A realistic plan does not start by buying a platform or searching for the fashionable technical term. It starts by describing one concrete decision. Rather than saying, “we want to use artificial intelligence,” the association can ask, “How do we allocate rooms without pushing out activities with fewer resources?” That sentence makes the problem precise and keeps the trial limited. It also shows when a recommendation should not decide anything by itself. If a benefit, exclusion, diagnosis, contract, or right is at stake, a tool may organise information, but a responsible person must study the case and explain the decision. Automation gains value when it reduces repetitive work; it loses value when it is used to hide responsibility.
A realistic plan does not start by buying a platform or searching for the fashionable technical term.
Make the hidden rule visible#
Every recommendation contains a preference, even when it looks neutral. It may favour speed, savings, proximity, popularity, likelihood of response, or habit. At the association, the first rule rewarded estimated attendance and the speed of the email request. It was easy to calculate, but it was not the only reasonable criterion. On a shared sheet, the team wrote four questions the screen did not show: what is being valued, what is being left out, who can change it, and what happens when information is missing? Reading them led the team to add accessibility needs, rotation between groups, and protected space for new proposals. The rule did not disappear; it stopped operating in silence.
Separate a suggestion from an instruction#
The word “recommended” may sound harmless, yet many people read an ordered list as an instruction. That is why it helps to build a visible pause between a result and an action. It might be a confirmation box, a person who checks exceptional cases, or a note explaining why an option appears. This is not about slowing everything down. It is about reserving human attention for what the tool cannot know: a temporary need, a missing context, difficulty expressing a situation, or a consequence that matters more than efficiency. When a list offers an alternative and states that it can be reviewed, people can use it without giving up their judgement.
Use the minimum information needed#
The rush to personalise often asks for more data than a decision requires. Before entering names, messages, addresses, photographs, or family circumstances, ask whether that information truly changes the recommendation. To allocate rooms, schedule, duration, required physical resources, and a group’s stated preference may be enough. There is no need to collect personal stories or build profiles. Reducing data protects privacy and improves the work: it forces the team to write simple rules that others can understand. When data belong to someone else, asking permission is not an awkward formality. It recognises that the person retains a voice in how their information is used.
Test with a reversible case#
The best first trial is one that can be stopped without causing harm. For two weeks, the association used the system only to suggest a draft timetable. Nobody received an automatic refusal, and every group could flag a time that was impossible. At the end of each day, a volunteer compared three things: the automated proposal, the final timetable, and the changes people had requested. They found that the tool treated two activities of equal length as interchangeable, even though one needed an interpreter and the other could change time. That discovery was not a failure. It was useful information found before a provisional rule became a habit that would be hard to undo.
Look for the option the list does not offer#
A simple practice against automatic obedience is to ask for a fourth alternative. If the system presents three options, someone should look for one outside that list: change the duration, share a resource, open a different time, call the affected person, or postpone the decision until reliable information is available. This search does not try to prove that the tool is always wrong. It reminds us that a list is a selection, not the whole world. In the association’s case, the fourth option was to use a small room in another building for the conversation group and keep the main accessible room for activities that truly required it. The solution appeared when the group stopped confusing an order with inevitability.
Check whether convenience is shared fairly#
A system can save staff time while shifting effort onto people with less room to adapt. Imagine an app that recommends the earliest available appointment. For someone with a flexible schedule it may help; for someone caring for another person, relying on public transport, or needing support, it may be a barrier. The question is not only “does it work?” but “whose work does it save, and whose does it add?” It helps to examine outcomes through concrete situations: people using screen readers, different languages, slow connections, changing work hours, or limited digital experience. Nobody needs to be invasively labelled; it is enough to listen to the obstacles that arise and check whether they repeat.
Give an explanation people can answer#
A useful explanation fits in everyday language. For example: “The proposal orders requests by room availability, required materials, and outstanding turns; you can ask for a review if information is missing or the time is not workable.” That sentence names the criterion, acknowledges limits, and opens a door. It does not promise a perfect calculation or require programming knowledge before someone can question it. Avoiding phrases such as “the system decided” matters too: behind every system are people who chose data, objectives, and boundaries. When an explanation can be discussed, a recommendation becomes public help rather than an authority nobody knows how to question.
Create a correction route that does not humiliate#
Correcting a recommendation should be simple and safe. If a person must explain intimate details in front of everyone to request a change, many problems will never be reported. The association offered a short email, an in-person conversation, and a no-explanation-needed option to request review. It recorded only what was needed: date, type of problem, adjustment made, and whether the rule needed changing. It did not retain the personal story behind the request. That distinction matters: learning from an error does not require turning people into case files. A respectful route reveals patterns and repairs individual cases without punishing someone for saying, “this does not work for me.”
Measure what does not fit in a counter#
Indicators can help, but they cannot replace conversation. The team tracked how many requests it resolved each week, then added two closing questions: “Who had to make the greatest effort to take part?” and “Which decision can we still not explain?” Sometimes the answer was uncomfortable. A highly efficient timetable could keep giving the best hours to the same groups. A proposal that looked balanced could ignore that someone had not been able to answer an email. Naming such doubts stops a clean number from becoming an excuse. The quality of a recommendation includes efficiency, but it also includes intelligibility, appeal, and belonging.
Agree who looks after each part#
Saying there will be human oversight is not enough; people need to know who will do what. One person can check that room data are current. Another can review exceptions each week. The coordinator must be able to pause the trial if unforeseen consequences appear. And users need to know whom to contact. Sharing these tasks prevents the familiar problem in which everyone assumes somebody else will check the tool. It also makes supervision proportionate: a music recommendation may allow occasional review, while a recommendation affecting access to resources requires closer controls and a clearly human final decision.
End in a way that leaves room to change#
When the trial ended, the association did not celebrate that an algorithm had solved its timetable. It kept part of the system, changed two criteria, and scheduled another review a month later. Its final agreement was specific: the list may propose; people may object; no activity is excluded without an explanation that can be reviewed. That kind of commitment is more valuable than an abstract promise to use technology “responsibly.” This week, you can do something similar with an everyday recommendation: note what it ranks, which data it uses, which alternative is missing, and how you would request a correction. If you cannot answer those four questions, you do not have to abandon the tool, but you have a good reason not to let it decide alone.
