When the distribution centre invited staff in, the major decisions had already been made. The supplier contract included the allocation system, speed indicators appeared in a presentation, and the activation date was printed on calendars. The invitation asked for “constructive comments.” Aina, who knew the chilled routes and the places where forklift traffic crossed, asked what happened when a fast route required a repeat journey for safety. The answer was that the model had already been tested. She could submit a suggestion for a future version.
That scene is not participation; it is late consultation about a closed decision. It asks people doing the work to contribute experience when no budget, timetable, or authority remains to alter the design. If they then identify a problem, the organisation can call it resistance to change. The result is unfair and expensive: experience that could have prevented a bad rule returns as an accident, delay, turnover, or urgent repair.
The missing conversation must happen before procurement, before indicators are set, and before a date is promised. It does not mean voting on every technical detail or handing a group of workers responsibility for buying software. It means recognising that a system reorganises tasks, risks, and decision-making possibilities, and that people who know the working day possess evidence no sales demonstration contains. Participating means being able to influence the initial question, compare alternatives, and accept that not adopting may be a responsible answer.
Open the question before buying the answer#
A co-design process starts with a problem, not a tool. The centre may describe preparation delays, accidents at a crossing, or difficulty distributing urgent orders. It must then ask what evidence supports that diagnosis and which consequences it cannot accept. Perhaps the bottleneck is not allocation at all, but irregular labelling, inadequate loading space, or a policy changing priorities every hour. Buying an algorithm before understanding the blockage turns a supplier hypothesis into a company necessity.
A co-design process starts with a problem, not a tool. The centre may describe preparation delays, accidents at a crossing, or difficulty distributing urgent orders.
The preliminary phase needs people from every affected task, labour representation, safety, maintenance, planning, and whoever answers for the budget. It also needs recognised time. It cannot be held at the end of a shift or depend on volunteer effort. Participants need intelligible information about data, objectives, anticipated changes, and contractual limits. One person’s experience is not an anecdote to translate into a technical report; it is knowledge about exceptions, hazards, and repairs that design must consider.
A good conversation separates what is known from what is assumed. The group can walk through a real shift, identify where a priority is decided, what information is missing, which activity does not appear in records, and what manual alternative exists. It can ask who will pay in time if the recommendation fails and who can stop it. Those questions reveal whether a proposal releases work or merely moves coordination and risk onto people with least power to change it.
Compare genuine alternatives#
Co-design does not end in a list of requirements. It should produce comparable alternatives. One may be an allocation pilot limited to one area; another, better labels; another, an added coordination shift; another, no automation while basic data is repaired. Each alternative needs cost, expected impact, required data, safety conditions, effect on roles, and a withdrawal route. Comparison stops a contract looking inevitable merely because it arrived first at the table.
Budget is a test of sincerity. If all funds are committed to licences, no room remains to change an interface, add equipment, fund training, or extend a pilot. The organisation should reserve money for adaptations requested during co-design and for an alternative if the tool does not work. This is not decorative contingency. It is the material ability to turn an observation into change instead of saying that the contract will not permit it.
Alternatives must include costs often excluded from procurement: learning time, incident review, maintenance of a manual route, emotional work in resolving conflict, and possible income loss during transition. If a system promises ten minutes saved but requires two people to repair exceptions every afternoon, the initial comparison was incomplete. Making those hours visible protects both the workforce and the investment decision.
Test without turning a pilot into destiny#
A pilot is useful when it can stop and answers questions agreed before it begins. The centre can choose an area, a limited duration, and cases that do not put safety at risk. It should set signals that allow continuation, signals that require change, and signals that require a stop. It is not enough to observe higher speed. The test should examine route errors, near misses, physical effort, load distribution, ability to challenge an assignment, and invisible tasks that appear afterwards.
Staff must be able to record an incident without losing production time or facing retaliation. If an allocation proposes crossing a saturated area, Aina needs a way to refuse it, explain why in a few words, and receive an answer. Those reports are not noise for the pilot to filter; they are evidence of whether the system understands its environment. A team that does not report because it fears being marked produces falsely reassuring data.
The test needs a baseline. Before anything is activated, document time, accidents, shift changes, errors, complaints, and routes requiring coordination. Compare afterwards by task type and time, not only through a global average. Interview people executing, supervising, and receiving the work as well. Numbers identify a pattern; conversations show why a recommendation that looks efficient can be unworkable in a narrow aisle or during an unexpected delivery.
Decide and leave a record#
At the end of the phase, the organisation has three real decisions: adopt, modify, or not adopt. Adopting requires explaining what evidence shows improvement and which limits remain. Modifying requires naming changes, budget, owners, and a new test. Not adopting requires admitting that the problem may need another response. None of these choices is failure when reasoned. Failure would be retaining a harmful tool to defend a promise made before knowing the work.
The decision should be documented in a short, public format for staff: initial objective, participants, alternatives compared, pilot results, relevant incidents, approved resources, accountable person, and review date. It should not reveal personal accounts or unnecessary commercial secrets. It should let someone understand why a path was chosen and how to challenge it. Transparency prevents consultation becoming a manipulable memory that “everyone agreed.”
Co-design continues even after adoption. Orders, staff, spaces, and data change; a rule appropriate in June may cause harm in December. A committee must have authority to pause a function, review indicators, and order modification. Representation of the work cannot disappear when the pilot ends. Participation is credible only when it retains a way back after reality contradicts prediction. Its minutes should state which evidence triggered the review and what changed afterwards.
The missing conversation neither starts with a demonstration nor ends with a survey. It begins when a problem still permits several answers and ends with a decision that can change. Aina did not need the company to accept every suggestion; she needed her knowledge of routes and safety to matter before contract, indicators, and date were fixed. Dignified automation does not use experience to legitimise what has already been decided. It uses experience to decide better, reserve resources for repair, and retain the freedom not to adopt what does not improve work.
