Broken. Think about that word. Does it mean a system once worked but no longer does? Does it mean the system still works, but is no longer fit for its intended purpose? Or does it work exactly as designed—just inefficiently, expensively and without the ability to scale? Those are not the same diagnosis.

Before replacing anything, it might be wise to understand which one you are dealing with. What made the system work in the first place? What changed? Age? Overuse? Poor maintenance and neglect? Or replacement parts that never quite fit?

If you are repairing an airplane, you had better diagnose the problem before removing parts and installing new ones. Otherwise, you may not discover what you misunderstood until the plane is already in the air.

Is an archaic legacy platform, propped up at every stage by human intervention, reconciliation controls and huge volumes of old-fashioned elbow grease, necessarily broken? Or is it simply inefficient? There is an enormous difference.

A 30-year-old collection system may be slow, cumbersome and expensive to operate. It may depend upon spreadsheets, handwritten procedures and employees who have accumulated decades of knowledge about what happens when something does not process exactly as expected. But if that system consistently receives the right accounts, applies the right client instructions, routes payments through the right trust accounts, identifies exceptions and remits the right money to the right client at the right time, it may not be broken at all.

It may be highly effective. Just highly inefficient. And almost certainly difficult to scale.

That distinction is easy to miss when developers define “the system” as only the software. The employee who recognizes that a client file is missing a critical field is part of the system. The accountant who reconciles the payment processor with the bank account and the system of record is part of the system. The operations employee who knows that one client’s payments must be routed differently from another’s is part of the system. The supervisor who recognizes an unusual exception because she has seen it three times in 20 years is part of the system.

Those people may be compensating for limitations in the technology, but they are also supplying business rules, institutional knowledge and financial controls that the technology does not contain. Call all of that a collection of “workarounds” if you want. But those workarounds may be the very reason the process still works.

That is where automation can become dangerous. A developer sees redundant steps, manual intervention and too many people touching a transaction. Eliminate the extra steps. Remove the unnecessary labor. Streamline the process. Great, but did you first understand what those people are actually doing. Which decisions are they making? What exceptions are they catching? What information are they reconciling? What client requirement are they satisfying? What financial control are they performing? What breaks if they are removed?

If those questions are not answered first, automation does not eliminate inefficiency. It eliminates the knowledge and controls that made an inefficient system effective.

This risk may be particularly acute in collections because the contact-center aspects of the business are the easiest to see, understand and retool. At the visible front end, the similarities are obvious. Calls. Texts. Emails. Consumer conversations. Payment arrangements. Portals. Virtual agents. Artificial intelligence can and does transform all of that. But a collection agency also has a less visible core. Accounts must be received accurately. Client rules must be applied correctly. Balances must remain reliable. Payments must move through the correct processors and trust accounts. Transactions must be recorded in every place they belong. Exceptions must be identified. Money must be reconciled and remitted accurately and on time.

The consumer may never see any of that. Neither may the developer, but the business fails without it. That back office is not an annoying remnant of an obsolete system. It is where the agency proves that it can account for someone else’s money. Any transformation that overlooks that core risks automating the visible activity while weakening the foundation underneath it.

There is an especially dangerous sequence. Recognize that an overstaffed, inefficient process must change if the business is going to scale. Declare the legacy system broken. Begin replacing it without fully understanding the processes surrounding it. Remove the human interventions and reconciliations that kept it functioning. Discover client requirements and edge cases only after failures occur. Then point to the resulting difficulty as proof that broken systems cannot be automated.

Perfectly circular. The original system gets blamed for failures created by replacement components bolted onto what has become a fragmented end-to-end process.

None of this is an argument for preserving obsolete technology forever. Manual processes create real cost, key-person dependency and risk. Reconciliations performed outside the primary application are rarely ideal. Institutional knowledge locked inside the heads of long-term employees is itself a vulnerability. Modernization is necessary. But modernization begins with humility.

The people who have operated a business for 20 or 30 years may understand things that are not evident in a process map. Their systems may contain rules that are not documented. Their inefficiencies may conceal controls. Their repetitive manual work may be compensating for complexities that a new development team has not yet discovered.

Those are not reasons to stop building. They are reasons to stop and listen before building.

You cannot automate a broken system, but before declaring a system broken, make damn sure you understand how it works, why it works and all the human knowledge holding it together. Otherwise, you may not be fixing a broken system. You may be breaking a functioning one.