The Checks Your Back Office Makes in Its Head Are in No Written Procedure

The most common reason an automation creates more work after go live than before is not technical. It is a check somebody has been making in their head for years, and that appears in no written procedure.

Anyone who has handled a process for a long time validates while entering data, without calling it a control. They pause at a quantity that does not fit the customer. They pick up the phone when a delivery address sounds unusual. They ignore a line they know is a note rather than an order item. These judgements are the actual substance of the work, and they are invisible, because they never produced a record. Building an automation replaces the keystroke and drops the judgement.

A typical picture

Suppose a wholesaler for medical practice supplies takes orders through a customer portal, by email and through an interface. A process reads the line items, matches the article number and creates the order. Article number and quantity are carried over. The unit of measure is not, because the order never contained it as a separate field.

A care home orders ten boxes of disposable gloves. In the article master the base unit is the single item and the sales unit is an outer carton of twenty four boxes. The ten lands in the quantity field, the system multiplies by the stored sales unit, and picking receives ten cartons on the document.

Someone who used to enter that order would have paused. A home with forty beds does not order two hundred and forty boxes. Nobody would have called that check a control. Moving to an automated process removes it without replacement.

The error runs both ways

Over delivery costs a credit note, a return and an awkward phone call. That is the visible case.

Under delivery is the expensive one. It often surfaces when the ward asks for supplies on a Friday afternoon, and it gets closed with a special run. What that gap costs appears in no report, because nobody traces the special run back to the original order. This is precisely why an automation often looks better in the statistics than it is in daily operation.

How to collect the knowledge without turning it into a project

You do not need weeks of process mapping. Two approaches are enough.

The first is to ask the people who handle the process today. Not how they work, but when they last paused. What made you notice in the past four weeks that an order was not right? What did you do about it? Who did you ask? Those three questions surface more in half an hour than any flow chart.

The second is to look at a hundred real transactions from recent weeks. Sort them by how many ran through without a query and which special cases occurred. What you find is the list of exceptions, and the exceptions are the project. The normal case is built in a few days.

A gut feeling becomes a rule or a clarification case

Every check you find falls into one of three buckets.

Some can be written as a rule. A quantity exceeding ten times this customer's previous maximum does not pass automatically. An article whose price deviates sharply from yesterday is not published.

Some need a query back to the customer, and the process needs a path for that which does not end in a shared mailbox.

And some need a human approval before anything binding happens. That is not a weakness of automation, it is its most sensible component exactly where an error becomes visible outside the company.

The order matters. First name the checks, then decide which bucket applies. Anyone who starts with the technology lands in the first bucket by default, because rules are the easiest thing to build.

Rules age

One peculiarity of these checks is that they change. A supplier alters a pack size, a customer moves to different terms, an article switches to a new unit. A rule wired into the process notices none of it and keeps calculating with the old value.

Every rule therefore comes with a question about where its value is maintained. It belongs in the master data of the article or customer concerned, not in the process itself, and somebody in your company has to be allowed to change it without calling the supplier. Getting that into the quote buys an automation that is still correct in its third year, rather than one that needs reworking every year.

What this means for choosing a supplier

A supplier who asks uncomfortable questions about your special cases before naming a price is a good sign. He is calculating instead of guessing. A quote that covers the process in a single headline has priced the normal case, and anything not explicitly stated becomes a change request later.

So ask specifically how the quote handles transactions that do not fit the pattern. The answer reliably separates suppliers who understand operations from those who build a surface.

The recommendation

Before automating a process, spend half an hour with the people who run it today and write down how they recognise that something is wrong. That list is worth more than any specification document, it costs you nothing but time, and it belongs in every quote you request.

Sophera Consulting takes exactly that list as the starting point, translates it into rules, clarification cases and approvals, and then builds the process for a fixed price, with no subscription and with handover and documentation. The entry point is free via the automation check.