Blog Guides Portfolio Bio antoniotrento.net
Italiano English

The cost of NOT having the app: hours, errors, lost customers — an estimate you can do Monday morning

2 September 2026 Antonio Trento
The cost of NOT having the app: hours, errors, lost customers — an estimate you can do Monday morning

Inertia looks free

When you evaluate whether to do software, an app, an automation, you look at the project’s price and compare it with zero. «The project costs X; not doing it costs zero.» It’s the most natural reasoning in the world, and also the most wrong, because that zero doesn’t exist. Doing nothing — going on working as you’ve always done, by hand, with the sheets, with the copy-paste — doesn’t cost zero: it costs a lot, every month, only the cost is hidden. It doesn’t appear on any invoice, there’s no line in the accounts that says «inertia», and that’s exactly why you ignore it. But it’s there, and often it’s bigger than the project you’re hesitating to do.

This is the cost of inertia: what you pay for not having solved a problem. Hours of work wasted on manual operations, errors that generate returns and credit notes and angry customers, customers who don’t come back because your process made them wait or betrayed them. Three line items, all real, all invisible in the P&L, all paid every month. The paradox is that you’re prudent on the project’s spend (rightly) but blind on the inertia spend (which is bigger) — because one is a number on a quote and the other is diffuse, silent, camouflaged in normality.

This article is different from the others: it doesn’t tell you a specific problem, it gives you a method to do the sums. An estimate you can start Monday morning, on your process, without consultants and without a mandatory Excel to download. Let’s see the three line items of the cost of inertia, how you actually measure them (the hours in three days, the errors, the lost customers), and — with the honesty that’s needed — when the number you get does not justify a project and you’d be better off leaving it.

The three line items: hours, errors, customers who don’t come back

The cost of not digitizing a process breaks into three line items, and it’s useful to keep them separate because they measure in different ways and often one weighs much more than the others.

The first is the hours. The time people spend doing by hand what a system would do on its own or in a fraction of the time: recopying data, searching for information, filling documents, updating sheets, answering the same questions. It’s the easiest item to measure and the one that’s usually underestimated, because they’re scattered minutes nobody adds up. It’s the same cost I quantified for the daily copy-paste that “Maria handles anyway”: a few seconds at a time, thousands of times, and at the end of the year they’re tens of thousands of euros.

The second is the errors. Every manual process gets it wrong: a data point recopied crooked, a wrong quantity, a wrong address, a missed deadline. And every error has a concrete cost: a return to redo, a credit note, a lost shipment, a missed appointment, sometimes a lost customer. Errors are less frequent than hours but often more expensive per single event.

The third, the most insidious, is the customers who don’t come back. The customer who waits too long and goes elsewhere, the one you sent the wrong invoice and who lost patience, the one who wanted to order in the evening and couldn’t. This item you never see in the P&L — it’s made of revenue that didn’t come in, and nobody records what didn’t happen. But it’s, almost always, the biggest item. It’s the silence of the lost conversion and of the slots that stay empty: it makes no noise, and that’s exactly why you ignore it.

How to measure the hours in 3 days (the method)

The hours item is the easiest to measure, and you can do it yourself, this week, without tools. Here’s the three-day method.

Day 1: list the manual processes. For one day, keep a notepad (or the phone notes) and every time you or someone does repetitive work by hand — recopy data, search for a file, fill a form, update a sheet, answer a recurring question — mark it. Don’t measure yet, only list. At the end of the day you have the list of “manual jobs” that repeat.

Day 2: count the times. Take the list and, for another day, mark how many times each of those jobs is done. How many times an order is recopied, how many times a document is searched, how many times availability is updated. You get the daily frequency of each.

Day 3: time it and multiply. For each type of job, measure how long it really lasts once (with the data search, the check, not only the typing). Then do the sum: duration × times a day × working days a year (about 220) × fully loaded hourly cost of the person (not net salary: add contributions and costs, usually 22-30 €/hour). The result is the annual cost of that manual process.

Add the processes and you have the first item, in euros, measured on your real case — not a conference estimate. Almost always the number surprises: those scattered minutes that looked like nothing become a four- or five-figure sum. It’s the same exercise you need to see the cost you pay deciding by gut or working by hand: until you measure it it looks like zero, as soon as you measure it it becomes impossible to ignore.

Errors: a return, an invoice, an appointment

The second item, errors, is measured a bit differently: not by timing, but by estimating frequency × cost per event. You don’t need laboratory precision, an honest estimate is enough.

Start from the types of error your manual process generates. A return for a wrong order: how much does it cost? The courier (paid twice), the time to handle it, the product possibly damaged — put 30-50 € per event, often more. A wrong invoice: the credit note, the admin time, the call with the unhappy customer — an hour of work plus the relationship damage. A missed appointment for a calendar error: the lost slot, the irritated customer. A missed deadline: sometimes a penalty, sometimes a lost customer.

For each type, estimate how many times it happens (a week, a month) and how much it costs on average once, and multiply. Even with very low rates — one error every hundred operations — if the operations are thousands, the errors become tens or hundreds a year, and the cost accumulates. It’s the item where people say «but we get it wrong little»: maybe so, but little × many times × cost per event still makes a serious number. And errors, unlike hours, have a tail: an error on an important customer can cost the relationship, that is much more than the single event.

Lost customers: the silence you don’t see in the P&L

The third item is the hardest to measure and almost always the biggest: the lost customers because your process betrayed them. It’s hard because it’s made of non-events: the customer who didn’t order, the one who didn’t come back, the one who went to the competitor. There’s no line in the P&L that says «revenue lost for inadequate process», because the P&L records what happened, not what didn’t happen. But those lost customers are real money that didn’t come in.

How do you estimate it, then, without cheating? With honest reasoning on real clues. How many times did a customer complain about the wait or an error? (For every explicit complaint, there are many silent ones.) How many carts or bookings are abandoned at the point where the process jams? How many quotes don’t turn into orders because the answer arrives too late? You won’t have a precise number, but you’ll have an order of magnitude — and often that’s enough to understand that this item, on its own, exceeds the other two. The lost customer is the silence you don’t see but that you pay: precisely because it makes no noise, it’s the one you ignore most and that costs you most.

A practical way: take a typical customer, estimate their value over time (how much they leave you in a year, or over the life of the relationship), and ask yourself how many you lose a year for reasons tied to the process. Even a few lost customers, multiplied by their value, make a figure that puts the cost of any project in perspective.

The estimate sheet, explained

At this point you have the pieces for an estimate sheet — not a magic Excel to download, but a three-line reasoning you can do on any sheet. I’ll explain the structure, so you build it on your case.

Line 1 — Hours. Sum of the manual processes measured with the three-day method: duration × frequency × 220 days × loaded hourly cost. A solid number, measured.

Line 2 — Errors. Sum of the error types: frequency × cost per event. A reasonable estimate, declared as such.

Line 3 — Lost customers. Estimated number of customers lost a year for process reasons × value of a customer. An order of magnitude, honest.

Total: the annual cost of inertia. The sum of the three lines is how much it costs you, every year, not to have solved the problem. This is the number to compare with the project’s cost — not the imaginary zero from before.

The golden rule in using this sheet is honesty: use prudent estimates, not inflated ones. A sheet with exaggerated numbers to justify a spend you’d already decided is useless (you cheat yourself). A sheet with prudent estimates that still gives a big number is a solid decision. Better to underestimate and still find a strong case, than to overestimate and take a decision on an illusion. The sheet’s value isn’t the precise number (which you won’t have): it’s moving from «doing nothing costs zero» to «doing nothing costs me about X a year» — and on that «about X» you can actually decide.

A numerical example, to show how it adds up

Let’s make the sheet concrete with an invented but realistic example, so you see how the three items add up. Imagine a small commercial company that handles orders by hand.

Hours. With the three-day method it discovers that two people spend, on average, 2 hours a day each recopying orders, searching data and updating sheets. That’s 4 hours/day × 220 days = 880 hours a year. At 25 €/hour loaded, that’s 22,000 € a year in hours alone.

Errors. It estimates that, on all the orders handled by hand, a serious error (return, wrong address, crooked quantity) happens a couple of times a week, at an average cost of 40 € between courier, time and rework. That’s ~100 errors a year × 40 € = 4,000 €. Prudent, but real.

Lost customers. It notices that some customers complain about delays and that some evening orders get lost because the office is closed. It estimates, honestly, losing the equivalent of 5 customers a year for these frictions, each worth ~1,500 € a year: 7,500 € that don’t come in.

Line item Annual estimate
Hours (880 h × 25 €) 22,000 €
Errors (100 × 40 €) 4,000 €
Lost customers (5 × 1,500 €) 7,500 €
Cost of inertia ~33,500 €/year

Thirty-three thousand five hundred euros a year. This — not zero — is the number to put next to the quote for a project that solves the process. If the project costs, say, 25,000 € one-off, it pays for itself in less than a year and from there on it’s all saving. Note also that, in this example, the biggest item is not the hours (the ones everyone looks at) but the sum of errors and lost customers: it’s typical, and it’s because the hidden items, added up, often exceed the visible one. Change the numbers to yours, but redo exactly this reasoning.

When the number does NOT justify a project

And here’s the part whoever sells software never tells you, and which instead is the heart of honesty: sometimes the number is small, and then you don’t do the project. The cost of inertia isn’t always big. If you measure it and discover that that manual process costs you a few hundred or a few thousand euros a year, and the project to solve it costs much more, the right answer is: don’t do it. Keep the manual process, which is perfectly fine, and use the money elsewhere.

This is fundamental, because the opposite risk to inertia is over-engineering: solving with expensive software a problem that cost little, for the pleasure of “digitizing”. The estimate sheet serves also for this: to stop you when the number is small. A manual process that costs little and works shouldn’t be touched — automating it would be throwing money, exactly as leaving an expensive one unsolved is throwing money the other way. The question is never «is it digitizable?» (almost everything is), it’s «how much does it cost me not to do it, compared to how much it costs to do it?».

There are also cases where the number is big but the project still doesn’t pay: if the process is about to change, if volume is falling, if there’s another more urgent priority with a greater return. The estimate sheet is a decision tool, not a justification tool: sometimes it says yes, sometimes it says no, and an honest supplier helps you read both answers. Whoever always tells you «yes, it pays to automate» without having seen your number is selling, not advising — it’s the same approach with which I distinguish, in every custom software purchase evaluation, whoever looks at your interest from whoever looks at their invoice.

How to use the estimate with a supplier

Once you have your number, it becomes a very powerful tool in the conversation with whoever should build you the solution — and it protects you from rip-offs. Here’s how to use it.

First: it flips the conversation. Instead of asking «how much does the software cost?» and getting scared of the price, you arrive with «this process costs me about X a year in inertia; what can you do, and how much does it cost?». Now the quote is read in relation to the cost it eliminates, not in absolute. A project that costs half of what inertia takes from you every year is a good deal; one that costs three times, no.

Second: it unmasks inflated proposals. If a supplier proposes a huge, expensive solution for an inertia you’ve measured as small, you have the data to say no with knowledge. If they propose one that costs little but doesn’t face the big item of your cost (maybe the lost customers), you see it. Your number is the compass that tells you whether the proposal is proportionate to the problem.

Third: you measure the return afterwards. With the starting estimate in hand, after go-live you can check whether the cost of inertia has actually fallen — the hours saved, the errors down, the customers retained. The ROI of custom software stops being an act of faith and becomes a check. Whoever builds you a serious solution isn’t afraid of this comparison; on the contrary, they should want it, because that’s how they prove they solved a real problem.

A typical case: the number that decided

A typical profile, architectural, no names. A company had been hesitating for months on a project to automate a manual process that occupied several people. The brake was the price: «it costs a lot, who knows if it’s worth it». Nobody had done the sum of how much it cost not to do it — they were comparing the quote with the imaginary zero.

What was done, even before talking about software: the estimate. Three-day method on the hours (which revealed a number much higher than expected, because those scattered minutes nobody had added up), honest estimate of the errors (returns and corrections that were considered “normal”), and a reasoning on the customers lost to the process’s slowness. Added up, the three items gave an annual cost of inertia that made the project’s price — which before scared — small by comparison: it would pay for itself in a handful of months.

The result wasn’t only «do the project»: it was deciding with knowledge instead of by feeling. And, importantly, on another process the same company was evaluating, the sum said the opposite — inertia cost little, and that project wasn’t done, saving money. The honest note: the method’s value wasn’t “justifying the spend”, it was giving a number to two decisions, one with the yes and one with the no. The estimate sheet isn’t a sales tool: it’s a truth tool, and sometimes the truth is “leave it”.

It’s for you if / it isn’t for you if

It’s for you if: you’re evaluating software, an app or an automation and you compare the price with “zero” (that is, you’ve never measured how much it costs you not to do it); you have manual processes you suspect cost more than they look; you want to decide on numbers and not by feeling; you want to arrive at a supplier with a figure in hand instead of with a fear of the price.

It isn’t for you if: you’ve already measured the cost of inertia and you know it’s small (then don’t automate, that’s perfectly fine); you’re looking for an excuse to justify a spend already decided (the sheet is for deciding, not for cheating yourself); the process is about to change or disappear, and measuring it makes no sense. The method is useful when you want an honest decision, not a confirmation.

Frequently asked questions

Why doesn’t “doing nothing” cost zero? Because going on working by hand has a real but hidden cost: hours wasted on manual operations, errors that generate returns and corrections, customers who don’t come back for slowness and mix-ups. None of these items appears on an invoice or a line of the accounts, but you pay them every month. Comparing a project’s price with “zero” is the mistake that makes you hesitate on decisions that would pay.

How do I measure the hours without tools? With the three-day method: day 1 you list the repetitive manual jobs, day 2 you count how many times they’re done, day 3 you time how long they last and multiply (duration × frequency × 220 days × loaded hourly cost). You get the annual cost of each process, measured on your real case. Almost always the number surprises, because the scattered minutes nobody ever adds up.

How do I estimate the errors and the lost customers? The errors: frequency × cost per event (a return, a credit note, a missed appointment), with prudent estimates. The lost customers: estimated number of customers lost a year for process reasons × value of a customer. You won’t have precise numbers, but an order of magnitude — and often the lost customers, even though they don’t appear in the P&L, are the biggest item.

And if the number is small? Then don’t do the project, and that’s the right answer. The cost of inertia isn’t always big: if a manual process costs you little and works, automating it would be throwing money (over-engineering). The estimate sheet also serves to stop you: sometimes it says yes, sometimes it says no. The question isn’t “is it digitizable?” but “how much does it cost me not to do it, compared to doing it?”.

Isn’t this a way to justify a spend? Only if you cheat with the numbers, and then you cheat yourself. Used with prudent estimates, the sheet is an honest decision tool: if even with conservative numbers the cost of inertia is big, the decision is solid; if it’s small, it stops you. The value isn’t the precise number (which you won’t have), it’s moving from “doing nothing costs zero” to “it costs me about X” — and on that actually deciding.

How do I use the estimate with a supplier? Flip the conversation: you arrive with “this process costs me about X a year, what can you do and how much does it cost?”, so you read the quote in relation to the cost it eliminates, not in absolute. It unmasks disproportionate proposals (too big for a small inertia, or too small to face the big item). And after go-live, you check whether the cost of inertia has actually fallen: ROI becomes a check, not an act of faith.

How long does it take to do the estimate? The hours you measure in three days with the method described. Errors and lost customers are estimates you do in a few hours reasoning on real clues (complaints, abandonments, quotes not closed). In a week you have your number. It’s much less than you’d spend hesitating on the decision without data.

Does it hold for any type of activity? Yes: the method is universal, because the three items (hours, errors, lost customers) exist in every activity with manual processes. The numbers and the weights change (in one activity lost customers weigh more, in another the hours), but the structure of the reasoning is the same. It’s a way of thinking about the cost of inertia, not a formula tied to a sector.

In one line

Doing nothing looks free and it isn’t: the cost of inertia — wasted hours, errors, customers who don’t come back — is real but hidden, it doesn’t appear in the accounts, and often it’s bigger than the project you’re hesitating to do. Measure it: the hours with the three-day method, the errors with frequency × cost, the lost customers with an honest order of magnitude. Add the three items and you have the number to compare with the quote — not the imaginary zero. And if the number is small, don’t do the project: the estimate sheet is for deciding with honesty, not for justifying a spend. Arriving at a supplier with that number in hand lets you decide on facts and protects you from disproportionate proposals.

If you want to put in euros how much a manual process costs you today, before spending a cent on software, look at the projects I’ve built or drop me a line: we start from your number — measured, not imagined — and we decide together whether the project makes sense or whether it’s better to leave it.

Antonio Trento — System Architect & AI Integrator

Is this your problem?

I design and build data, backend, interface and AI agents end-to-end. No slides: systems that run and stay yours.