Interface or manual work: doing the maths

In many companies manual data transfer is treated like a bad habit to be admitted to. That does not hold up. Manual work is the right choice when a case occurs rarely, when it runs differently every time, or when it calls for judgement that cannot be captured in rules. A complaint that requires someone to decide on a goodwill gesture does not improve through automation; it merely goes wrong faster. The dividing line runs between cases that follow fixed logic and cases where the logic only forms in the mind of the person handling them. Only the first group is a candidate for an interface.

Equally important is the difference between disordered and ordered manual work. Disordered means everyone does it differently, with no template, no checklist and no second look. Ordered means a fixed sequence, a documented template, defined mandatory entries and a sample check. Moving from disordered to ordered costs almost nothing and cuts the error rate noticeably. It is therefore the first step in nearly every case, including those where an interface will follow later. Automating a disordered workflow simply casts the disorder into software, and the unclear results afterwards come as a surprise to no one who has seen it before.

The calculation needs an internal hourly rate. That is not the gross wage but a full-cost rate including employer contributions, workplace and non-productive time. Many companies work internally with a figure between 40 and 60 euros for administrative work (own project experience). If you have no figure of your own, take a middle value and then run the decision again with the upper and lower bound. If the recommendation flips, the case sits in the grey zone and an intermediate stage is usually the right answer.

The worked example below uses assumed values and is meant to show the structure, not to be transferred to your own company. It describes a case right at the threshold: forty cases a week, six minutes per case, three percent rework. The figures for implementation and support match the entry values on our pricing page.

The calculation shows two things. First, the first year barely produces an advantage; the benefit starts in year two. Anyone expecting payback within a few months will be disappointed unless the volume is considerably higher. Second, the residual effort does not disappear. Even a good interface needs someone to look at the daily log and clear the cases left waiting. Calculations that set this item to zero are the most common reason for disappointment after rollout. If you want to track how such effort develops over time, that belongs in regular metrics and reporting rather than in a one-off assessment.

An interface is not a piece of furniture that stays put once delivered. It is a component in live operation and behaves accordingly. Both sides are systems that get updated, add fields, change formats or let credentials expire. On top of that come cases the rules do not cover: a record without a mandatory entry, a number that does not exist in the target system, a character set that trips up the import. Those cases have to be noticed, logged and made workable. A connection that silently discards them causes more damage than the manual work it replaced.

The recurring items therefore include monitoring with notification on failure, a queue for rejected records together with a responsible person, logs with adequate retention, adjustments when either side changes, and a restart after disruption that does not create duplicate postings. These points belong in the quotation and in the acceptance test, not in a later conversation about additional effort. How we structure them is described on our page about interfaces. Recurring effort is not a defect of the solution but its normal operating state.

The figures above lead to a simple procedure that works without outside help. It does not replace a professional review of the individual case, but it reliably sorts out the cases where the answer is obvious anyway and narrows down the grey zone. The order matters: measure first, then put things in order, then calculate, and only then talk about technology. Starting with the technology regularly produces a solution for a problem that could have been dissolved beforehand.

As a rough orientation that does not replace the individual case: below roughly 20 comparable cases per week, ordered manual work usually stays the cheapest option. Between about 20 and 50 cases lies the zone of intermediate stages. From about 50 cases a week with a stable structure, an interface typically pays for itself within two years (own project experience). These thresholds move down when the cost of errors is high, for instance with prices, dates or quantities that feed straight into production or dispatch. They move up when the structure on the other side is unstable.

A reasoned decision against automation is a result, not a failure. It should receive the same care as placing an order, however. That means writing down the manual workflow, securing the template, naming a stand-in and making the review step binding. It also means documenting the decision together with its figures so that it can be understood in a year rather than debated from scratch again. Such documentation usually takes a single morning and forms part of proper process documentation.

The second part is the review date. Volumes grow, systems get replaced, staff change. A workflow that today sits well below the threshold at fifteen cases a week may be at forty in eighteen months without anyone noticing, because the load rises gradually. An annual look at the three figures costs little and prevents a workflow being carried along for years when automating it would long since have paid off. Where retention or auditability requirements apply, a professional review of the individual case is advisable in addition.