Rules That Live Only in Your Shipping Manager's Head, and What an Automation Can Do With Them

The most common objection to automating a process is that the decisive rule is written down nowhere in the system. That is not an obstacle. It is a description of the current state, and in many companies it marks exactly the process where automation pays off most.

A good example is agreed remaining shelf life on dated or perishable goods. An availability check returns a number: 240 units, free stock. How long those 240 units remain acceptable to that particular customer is not part of the number.

The difference between master data and a promise

The expiry date belongs to the batch. It is recorded in the batch data or printed on the packaging, and it is a property of the goods.

Remaining shelf life is something else. It is a condition between you and one specific customer, valid on one specific day. Typical wording is two thirds of total shelf life, at least six months on delivery, or at least twelve months on delivery. Clauses like this live in framework agreements and tender documents, not in the customer record, because there is no field for them.

That produces a situation that works for a long time and then becomes expensive. Stock is correct, picking by earliest expiry first is correct, and the promise is still wrong, because it was made without knowledge of the clause. It surfaces at the customer's goods receipt, with rejection, return transport, a credit note, a replacement order, and stock back in your warehouse that no customer with that clause can take any more.

Why such rules are nowhere in the system

The reason is rarely carelessness. Standard systems provide no field for agreements this specific. So the rule stays where it was created, in a contract document on a shared drive, and in the head of the person who looks after those accounts.

While there are three such customers and the shipping manager knows them, it works. It stops working when that person retires, goes on holiday, when order entry is spread across a larger team, or when the number of customers with such clauses outgrows what one person can carry alongside everything else.

The real risk is therefore not the individual mistake. It is a dependency on one person that nobody books as a risk, precisely because it has held for years.

What an automation can make of it

There are three steps, and only the third one is technical.

The first step is writing the rule down in a form that can be decided. Not observe remaining shelf life, but: for this customer, only batches may be allocated whose expiry date is at least six months after the planned delivery date. That translation is the actual work, it costs time inside your company, and it has value regardless of any software.

The second step is a place where the value is stored. An additional field in the customer record, a maintained table, or a small dataset of its own. Where it sits matters less than that somebody owns its upkeep and that it is keyed to the customer number the check will later use.

The third step is the check itself. For every order it compares the available batches against that customer's condition and reports when the promised quantity could only be met from critical batches.

The timing of the check decides its value

A check at picking prevents a wrong delivery. A check at order entry prevents a wrong promise, and that is worth considerably more.

If the mismatch only appears in the warehouse, the order is already confirmed and the delivery date already quoted. From then on you are managing consequences: rescheduling, calling the customer, moving the date. If it appears at order entry, you have several options and all of them are cheaper. Promise a later batch, offer part of the quantity from another batch, ask whether the customer will accept the shorter shelf life this once, or wait for the replenishment.

That is why this check belongs at order entry rather than at the end of the chain.

What this means for your buying decision

The effort does not scale with your number of customers. It scales with the number of different clause variants. Two or three variants are manageable. Twenty individually worded agreements are a project of their own, and then the first step is standardising the wording, not buying software.

You can do that groundwork without a supplier. Have the framework agreements of your twenty largest customers reviewed for such clauses and count how many distinct formulations actually occur. The result drives the price more than any technical decision.

The same pattern applies to many other agreements that live outside the system: minimum order values, deviating payment terms, blocked articles for individual customers, packaging requirements, fixed delivery time windows. Once you have walked the path for one of them, the rest follow with far less effort.

Sophera Consulting first translates agreements like these into checkable rules, records exceptions and responsibilities in writing, and then builds the check at a fixed price, without a subscription and with handover and documentation. The entry point is the free Automation Check.

The recommendation

Do not start with software. Start with a list. Which promises does your company make that appear in no field anywhere, who knows them, and what happens on the day that person is not in.

If that list has more than two entries, you do not have a data problem. You have a knowledge problem. Automation is a good instrument against it, because it forces the rule to be written down properly once. You get that part of the value even if no software is ever built.