Back-office software gets a fraction of the care that customer-facing software gets. The cost does not disappear. It moves to the people who use it eight hours a day.
By @vgutierrez, developer at KWAN · October 2026 · 5 min read
Every company has one. A screen that takes nine clicks to do what should take two. A form that rejects a valid date and answers only "error". A spreadsheet that was promoted to "the process" because nobody had time to build the real thing.
Nobody planned it. Internal tools tend to be built once, under deadline, for users who cannot leave, and a user who cannot leave is a user nobody optimises for.
I have spent years on both sides: building the customer-facing product, and inheriting the back-office that keeps it alive. The customer side gets design reviews, analytics and a roadmap. The back-office gets a ticket.
That gap costs money, and this article is about where the money goes.
The copy-and-paste tax
A punch-card operator keys in data by hand, one record at a time. The tax is older than the software. Photo: NARA, public domain, via Wikimedia Commons.
Start with the most common cost, and the least visible. An operator reads a value in one system, switches windows and types it into another. It takes forty seconds, and it happens all day.
Take an illustrative case, not a real client: a finance team reconciling orders between two systems. Before, every order is checked by hand. Open the first system, find the order, copy the total, open the second, paste, compare. Six steps, about a minute, and a typo every few dozen orders. After a small integration that puts both totals side by side and flags only the mismatches, the operator reviews the exceptions and skips the rest.
Same person, same day. The difference is that the morning now goes to the orders that need judgment instead of the ones that need patience.
No single copy-and-paste is expensive, which is exactly why it never shows up in a budget. Multiply forty seconds by the people, the repetitions and the working days in a year, and it stops being small. Forty seconds, fifty times a day, over roughly 220 working days, comes to about 120 hours a year for one person.
The tool that only Jane Doe understands
An elevator panel with dozens of buttons and codes like LP, UP and SL. Everyone who rides it learns which ones matter. Photo: B137, CC0, via Wikimedia Commons.
Every team has a Jane Doe. She knows which field to leave blank, which button lies, and the order in which you must click things or the record breaks.
That knowledge is the tool's missing interface, stored in a person. When Jane Doe is on holiday, throughput drops. When she leaves, the company finds out what it had been paying her to compensate for.
If onboarding a new operator means weeks of shadowing, the tool is teaching badly. Good software explains itself where it is used: clear labels, sensible defaults, errors that say what went wrong and how to fix it.
The workaround is a requirements document
VisiCalc on an Apple II, 1979: an early ancestor of every spreadsheet that quietly became a process. Screenshot: User:Gortu, public domain, via Wikimedia Commons.
Look for the spreadsheet with a colour code nobody wrote down. Look for the shared inbox used as a database. Look for the status that lives in someone's head until they type it into a chat.
These are signs that the official tool failed and people, being resourceful, routed around it. The workaround is usually a precise description of what the tool should have done.
So before you replace it, ask whoever built it what they were trying to fix. That conversation beats most requirements workshops.
Measure the tool, not only the outcome
A mechanical stopwatch. Watching one operator for an hour beats a quarter of survey answers. Photo: StefanPohl, public domain, via Wikimedia Commons.
We track conversion on the checkout page down to the decimal. We rarely track how long it takes an operator to process a refund.
What to measure is not complicated: time to finish the three most common tasks, error rate, and how often people ask for help. Then watch two or three operators do real work for an hour. You will learn more in that hour than from a quarter of survey answers.
This is where the argument stops being about empathy and starts being about return. A task that takes four minutes and could take one, done a few hundred times a week, is hours handed back to work that moves the business. That is a return on investment you can measure.
Better does not mean bigger
One button, one obvious action, and a sign that says what it does. Photo: Angus Fraser, CC BY 2.0, via Wikimedia Commons.
The objection I hear most is that a better internal tool means a bigger project, more features, more complexity.
It usually means the opposite. A well-thought-through screen removes decisions instead of adding them: fewer fields, safe defaults, one obvious next step. That is less work for the people who use it and, done right, less work for the people who build it, because there is less to explain, support and fix.
Complexity is what you get when nobody owned the experience. Simplicity is what you get when somebody did.
Conclusion
You do not need a redesign programme. Pick one internal tool, sit next to the person who uses it most, and count the steps in their most common task. Then remove one that exists only because the software is bad.
Do that for the tools your operations, support and finance teams rely on, and you are already treating them as customers. They are.
Related on the KWAN blog: A new engineer hasn't shipped yet: how to find where delivery is stuck, the same question seen from the delivery side.
Top comments (0)