The Co-op That Wouldn't Log In: A Change Management Playbook for 38 Producers, 4 Admins and 6 Drivers

Why co-op software rollouts fail on people, not features

Most co-op software rollouts fail because the platform changes who holds information and who can be blamed when something goes wrong. Producers lose the ability to phone a friendly administrator and negotiate. Administrators lose the informal control that came from owning the spreadsheet. Nobody says this out loud, so it surfaces as 'the app is confusing'.

In a spreadsheet-run co-op, a lot of value sits in one person's head. That administrator knows Marija always underreports her lettuce by 10% so she has slack, knows the driver on the northern route will not take the last stop after 4pm, knows which producer to call when someone drops out on Thursday. A platform makes all of that explicit, and explicit means auditable. The producer who used to have quiet flexibility now has an on-time rate visible to an administrator.

That is not a reason to avoid the platform. It is a reason to name the shift openly during the rollout rather than pretending the software is neutral. When we introduce a system, the honest framing is: this makes the co-op's operations legible to everyone in it, including you, and the first people to benefit are the ones being blamed for problems they did not cause.

Who actually resists, and what each objection really means

Resistance is rarely uniform. In a co-op of 38 producers, 4 administrators and 6 drivers, opposition clusters into four recognisable patterns, and each needs a different response. Treating all of them as a training problem is the fastest way to lose the group that is not resisting training at all.

The most dangerous objection is not the loud one. A producer who says 'I'm too old for this' will usually be posting stock within two weeks if the interface is simple enough. The administrator who quietly keeps a parallel spreadsheet 'just in case' is the one who will still be running it in month six, and every other person in the co-op will notice that the real numbers live somewhere else.

The low-confidence producer: says 'I don't understand computers'. Actually means 'I am afraid of making a public mistake in front of the co-op'. Fix: private practice mode, undo everywhere, no notification to others when they edit.
The status-loss administrator: says 'the system doesn't handle our exceptions'. Actually means 'my expertise was the exception handling'. Fix: put them in charge of configuring the exception rules, so their knowledge becomes the system's knowledge.
The high-volume producer: says 'I already have my own system'. Actually means 'you are asking me to do double entry for the co-op's benefit'. Fix: CSV import or integration before you ask them to type anything.
The driver: says almost nothing, then keeps using paper. Actually means 'the app needs two hands and a signal, and I have neither at the kerb'. Fix: offline-first, one-thumb confirmations, and let them see the route before they leave the depot.

The training sequence that sticks: drivers, then admins, then producers

Train in the order of blast radius, smallest first. Drivers are 6 people doing one repetitive task and give you clean feedback within a day. Administrators are 4 people who become internal support. Producers are 38 people you can only train once before word of mouth decides the outcome, so they go last.

The instinct is to start with producers because there are most of them and they are the hardest. That is backwards. Producers judge the platform by whether their first week goes smoothly, and their first week goes smoothly only if the administrators already know the answers and the drivers are already confirming deliveries correctly. Train producers first and every early question lands on an administrator who is also learning, which produces the sentence that kills a rollout: 'nobody knows how this thing works'.

Producer training itself should be staged, not blanket. Start with 5 or 6 producers who are already comfortable with a smartphone and are respected in the group, run one real order cycle with them, then let them be the reference point. The remaining producers are far more receptive to 'Ivan did it last week and got paid on time' than to a training deck.

Week 1: Drivers. One route, one van, real stops. Fix whatever fails at the kerb before anyone else sees the system.
Week 2: Administrators. Full order cycle in a sandbox, then configure the exception rules with them, not for them.
Week 3: Pilot producers. 5 to 6 volunteers post real stock for one real order window while the spreadsheet still runs in parallel.
Weeks 4 to 6: Remaining producers, in cohorts of 8 to 10, each cohort supported by a pilot producer rather than by the vendor.
Week 7: Cut the parallel spreadsheet. Announce the date two weeks in advance and do not move it.

What breaks trust in the first 30 days, and how to prevent it

Trust in a co-op platform is lost by money errors, phantom orders and silent failures, not by ugly interfaces. A producer who is paid the wrong amount once will check every payout manually for a year. A driver whose confirmed delivery does not appear in the admin view stops confirming deliveries. Both failures are recoverable technically and expensive socially.

The prevention is unglamorous. Run the first two settlement cycles against the old spreadsheet line by line and show producers both numbers side by side, including the cases where the platform is right and the spreadsheet was wrong. Make every state change visible to the person who caused it: if a producer edits available stock, they should see the new number reflected in the shop within the same session, not on a delayed sync. If an action fails, say so immediately in plain language rather than failing quietly and reconciling later.

One more thing matters more than it should: response time to questions in the first month. A producer who messages an administrator on Tuesday about a stock discrepancy and hears nothing until Friday concludes the system is unsupported. Set an explicit internal target, name a single person per week as the answer point, and publish who it is.

Measuring adoption honestly: the metrics that tell you it worked

Login counts are a vanity metric. Real adoption shows up as a reduction in the workarounds: fewer phone-call orders, fewer manual spreadsheet corrections before settlement, fewer paper delivery notes coming back in the van. Track the old channels going quiet, not the new one lighting up.

Four numbers are worth reviewing weekly during the first quarter. First, the share of producers who posted stock without a reminder, which tells you whether the habit formed or whether administrators are still chasing. Second, the number of orders created by an administrator on a producer's behalf, which should trend towards zero. Third, the count of deliveries confirmed in the app versus deliveries confirmed by phone. Fourth, settlement corrections after the run, which is the single best proxy for whether people trust the numbers.

Expect a dip. Somewhere around week 5 or 6, usually right after the parallel spreadsheet is cut, throughput drops and complaints spike. That is not failure, it is the point where the last workarounds die. The rollouts that fail are the ones where leadership reinstates the spreadsheet during that dip, because after that nobody believes the cutover date again.

Governance after go-live: who owns the platform inside the co-op

A platform without a named internal owner degrades within a season. Assign one administrator as the system owner with explicit authority over price list changes, new producer onboarding and exception rules, and give them a standing slot in the co-op's regular meeting. Vendor support handles bugs; the co-op handles decisions.

The decisions that need an owner are mundane and constant. What happens when a producer lists a product that overlaps with another producer's? Who approves a new delivery zone? What is the cut-off for editing stock before the order window closes, and who can override it? If these are decided ad hoc by whoever is on the phone, the platform slowly turns back into a spreadsheet with extra steps.

It also helps to schedule a review at the end of the first full season, with producers in the room. Ask what they still do outside the system and why. The answers point at genuine product gaps, and the act of asking is itself part of change management: it signals that the platform belongs to the co-op rather than being something done to it. That feedback loop is how Plodie's producer, administrator and driver apps have been shaped, largely by running our own short food supply chain and watching where people quietly went back to paper.

Key Takeaways

Resistance to co-op software is usually about lost informal control and fear of public mistakes, not about the interface.
Train in order of blast radius: 6 drivers first, then 4 administrators, then producers in small cohorts led by respected early adopters.
Trust is broken by payout errors and silent failures, so reconcile the first two settlement runs line by line against the old spreadsheet.
Measure adoption by the old channels going quiet: fewer phone orders, fewer admin-entered orders, fewer settlement corrections.
Expect an adoption dip right after the parallel spreadsheet is cut, and do not reinstate it.

This playbook covers the people side of the switch; the technical side is laid out in our 6-week migration plan, which maps order sheets, price lists and delivery routes into the platform week by week.

Frequently Asked Questions

How long does it take a food co-op to fully switch from spreadsheets to a platform?

Plan for six to eight weeks of rollout plus one full season of settling. The technical migration of order sheets, price lists and routes can be done in a few weeks, but habit change across dozens of producers takes at least three or four complete order cycles. Cutting the parallel spreadsheet around week 7 forces the transition; keeping it longer indefinitely delays adoption.

What do you do about a producer who simply refuses to use the app?

First check whether it is refusal or an access problem, since poor signal, a shared family phone or a cracked screen look identical to refusal from the admin side. For genuine holdouts, keep a supported fallback such as an administrator entering their stock from a weekly phone call, but make the cost visible: they get later order windows and no real-time stock edits. Most convert once they see peers getting paid faster.

Should the co-op run the old spreadsheet in parallel with the new platform?

Yes, but only for a fixed and announced period, typically three to four weeks covering the pilot and first cohorts. Parallel running lets you reconcile settlement numbers and catch mapping errors before money moves. Open-ended parallel running is the most common cause of stalled adoption, because staff default to the tool they already trust.

Who should lead a digital transformation project inside a small food co-operative?

An internal administrator with operational credibility, not the most technical person and not an external consultant. They need authority over price lists, onboarding and exception rules, plus a standing agenda slot at co-op meetings. The vendor handles bugs and feature requests; decisions about how the co-op runs must stay inside the co-op.

How do you train producers with low digital literacy without a manual?

Train on their own phone, with their own real products, during a real order window rather than in a demo environment. Cover one task only, posting available stock, and let everything else wait until that task is habitual. A peer producer who completed the same step last week is a more effective trainer than a vendor representative.