The Back Office Work We Deleted: A Task-by-Task Automation Audit from MOVE & MEET and Plodovi

How we audit back office work before writing any code

We audit by shadowing the operator for a full billing or delivery cycle and logging every recurring task with four attributes: frequency, time per run, error cost, and rule stability. Anything that scores high on frequency and low on rule stability gets a human approval step rather than full automation.

The mistake we see most often is auditing by asking. Operators describe the workflow they designed, not the workflow they actually run, and the actual workflow is full of exceptions that never made it into anyone's documentation. At MOVE & MEET the booking spreadsheet had a colour code nobody could explain until we found the operator who invented it: orange meant a member had paid in cash at the studio and the payment provider record would never match. At Plodovi, the retailer order sheet had a column that looked like a note field but was functionally a delivery-window override.

So we sit with the work. One cycle, timed, with the operator narrating. Then we build a table where each row is a task and the final column is one of three verdicts: automate fully, semi-automate with approval, or leave manual. That third verdict matters more than people expect. A task that runs four times a month and takes six minutes is not worth the maintenance surface of an integration, and saying so early buys credibility for the automations that do matter.

MOVE & MEET: the task list and the verdicts

MOVE & MEET's back office ran on booking confirmations, class rosters, membership reconciliation, and refunds. We fully automated confirmations and rosters, semi-automated membership reconciliation behind an operator approval screen, and left refunds mostly manual because the decision to refund was a judgement call, not a rule.

Booking confirmations were the clearest case. Before the app, someone read a form submission, checked capacity against a sheet, and typed a reply. That is a deterministic sequence with a known data source, so it became an automatic write plus a templated notification the moment bookings moved into the system. Class rosters followed from the same data: once a booking is a record rather than a row someone types, the roster is a query, and the instructor gets it on their phone instead of a printout.

Membership reconciliation is where we stopped short. Matching payment provider events to member records is automatable, but the exceptions, cash payments, a card that failed and was retried offline, a member on a paused plan, all needed a person to look. So the system does the matching and surfaces only the unmatched rows in a review queue with a suggested action. The operator confirms or overrides. Refunds stayed manual on purpose: the policy was deliberately flexible, and encoding a flexible policy in software just moves the judgement into a config screen nobody trusts.

• • Booking confirmations: automated fully. Deterministic inputs, templated output, no judgement.
• • Class rosters and capacity checks: automated fully. Became a query once bookings were records.
• • Membership and payment reconciliation: semi-automated. System matches, operator clears the exception queue.
• • Refund handling: left manual. Policy intentionally discretionary, low volume, high relationship cost if wrong.
• • Waitlist promotion: semi-automated. Auto-offer to the next member, but the offer expires and returns to the operator.

Plodovi: chasing order sheets, price lists, manifests, and invoices

Plodovi's admin load was retailer order sheet chasing, price list updates, driver manifest preparation, and invoice matching. Order sheets and manifests were automated outright. Price list updates became semi-automated with a producer-side submission and an admin approval. Invoice matching stayed partly manual because supplier documents were too inconsistent to parse reliably.

Order sheet chasing was the single worst task in the operation and the most satisfying to delete. Someone spent the back half of every ordering window sending reminders to retailers who had not submitted, then transcribing what came back by email, message, or phone into a master sheet. Replacing that with a retailer portal did two things at once: it removed the transcription entirely, and it turned chasing into a scheduled reminder driven by submission status. The human effort dropped to handling the small number of retailers who genuinely needed a call.

Driver manifests were pure derived data. Once orders, addresses, and delivery windows lived in one model, the manifest is generated, not assembled. Price lists were different. Prices change seasonally, per producer, sometimes mid-week when a crop comes in short, and the rules for who may change what are commercial rather than logical. So producers submit, admin approves, and the change propagates. Invoice matching we split: line items that matched an order exactly were auto-reconciled, and anything with a quantity or price variance went to a human, because a delivered-weight variance on fresh produce is normal and only a person knows which variances are acceptable.

• • Retailer order sheet collection and chasing: automated fully via the retailer portal plus status-driven reminders.
• • Driver manifest preparation: automated fully. Derived from orders, routes, and delivery windows.
• • Producer price list updates: semi-automated. Producer submits, admin approves, system propagates.
• • Invoice and delivery reconciliation: semi-automated. Exact matches clear automatically, variances go to review.
• • Ad-hoc B2B quotes for one-off wholesale requests: left manual. Low volume, negotiated terms.

The three automations we built and then reverted

We reverted three automations: automatic refund approval under a threshold at MOVE & MEET, automatic substitution of out-of-stock items at Plodovi, and fully automated churn-risk emails to lapsed members. Each failed for the same underlying reason: the automation was correct on average and wrong in exactly the cases that mattered most.

The refund threshold seemed safe. Anything under a small amount, approve automatically, save the operator a click. In practice the small refunds were the ones attached to conversations, a member who had a bad experience and wanted to talk, or someone testing whether cancellations were free. Auto-approving removed the operator's only signal that something was going on. We put the approval step back and kept the part that was genuinely useful: pre-filling the refund with the correct amount and the booking context.

Item substitution at Plodovi failed on trust. When a producer could not fill a line, the system picked the nearest equivalent product. It was technically reasonable and commercially wrong: a retailer who ordered a specific producer's product did not want a different farm's, even at the same price and quality grade. We changed it to a suggestion the shopper or admin accepts. The churn emails failed on tone. Automated re-engagement messages to a community of a few hundred people read as spam from a business whose entire value was that it felt personal. We kept the detection, dropped the sending, and gave the operator a weekly list.

The decision rule we now use for what to automate

Automate fully when the inputs are structured, the rule is stable for at least a year, and being wrong is cheap to reverse. Semi-automate when the computation is mechanical but the decision is not. Leave it manual when the volume is under roughly a few times a week, the rules change often, or the task is where the relationship lives.

The most useful reframing is separating computation from decision. Almost every back office task is a computation followed by a decision. Matching payments is computation; deciding what to do with an unmatched payment is a decision. Generating a manifest is computation; deciding to reroute a driver because a producer is running late is a decision. Software should absorb all of the computation and, in the uncertain cases, hand the decision back with everything the person needs to make it in one screen.

Two secondary tests catch most of the remaining bad ideas. First, the maintenance test: will this integration break when a third party changes something, and is anyone going to notice quietly or loudly? An automation that fails silently is worse than the manual task it replaced. Second, the exception rate test: if more than roughly one in five runs needs human intervention anyway, you have not automated the task, you have added a step. In that case, build the review screen properly and skip the automatic path entirely.

• • Automate fully: structured inputs, stable rules, cheap to reverse, low exception rate.
• • Semi-automate: mechanical computation, discretionary decision, exceptions that need context.
• • Leave manual: low volume, unstable or commercial rules, or the task is the customer relationship.
• • Revert: exception rate keeps climbing, failures are silent, or the output changes how customers feel about the business.

What the audit actually buys you beyond saved hours

The measurable win is reclaimed operator hours, but the durable win is that the business gets a written record of its own rules. Auditing task by task forces every undocumented exception, colour code, and side agreement into the open, which is what makes the eventual system correct rather than merely functional.

There is also a staffing effect. Both operations had a single person who was the only one who knew how a given process worked. That is a risk regardless of software. Once the mechanical part of the task lives in a system and the discretionary part lives behind a review screen with clear context, a second person can cover it. Onboarding a new admin at Plodovi stopped meaning learning one person's spreadsheet habits.

And the leftover manual tasks stop feeling like debt. When you have explicitly decided that ad-hoc wholesale quotes or discretionary refunds stay manual, and written down why, nobody spends the next planning cycle re-litigating it. We revisit those verdicts when volume changes, not when someone feels the process should be automated on principle. That is the whole audit: a list, a verdict per row, and a reason attached to each verdict that survives a year later.

If you are earlier in the process and still running the business on shared sheets, our spreadsheet-to-internal-system migration playbook covers the step before this audit: extracting the hidden business rules and cutting over without losing operator trust.