The call came in the way these calls usually do, framed as a software problem. A residential roofing company in Etowah County, Alabama had migrated to the new version of their quoting platform, and ever since, the estimates had been coming out wrong. The sales team would build a quote, the labor would populate, and the materials would simply not be there. Every estimate that went to a homeowner was being rebuilt by hand first, line by line, on every job. The team wanted to know if the software was broken and whether it could be fixed.
It was not broken, and the story of what was wrong instead is worth telling in full, because the pattern shows up in businesses far outside roofing. This is a case study in where the failure lives when every tool reports healthy, how to diagnose it, and what a version migration quietly does to the connections a business depends on. Advocate Roofing agreed to be named, and the details below are the real ones.
The symptom
Advocate runs its sales operation on a roofing CRM with quoting templates. A template holds the structure of a job: the labor items, the material items, the margins. The material items are supposed to pull live from the supplier’s synced product library, so that when a salesperson generates an estimate, current products and current pricing flow in on their own. That is the whole value of the connection. Price changes at the supplier show up in the quote without anyone maintaining a spreadsheet.
After the platform’s version migration, that flow stopped. Templates still existed, labor still populated, but the material lines came through empty or wrong. The visible result was a sales team generating estimates that could not be sent, and the invisible result was more expensive: every quote now carried a manual rebuilding step, and manual steps under time pressure are where errors and delays live. A homeowner waiting on a quote does not care why it is late. Some of them stop waiting.
Worth pausing on what happened next inside the company, because it is the most human part of the story. Within weeks, the team had absorbed the rebuilding into their routine. It became a known chore, the way things are now. A serious failure in the connection between two systems had been normalized into everyone’s workflow, and that normalization is exactly the pattern the resisting organizations in my doctoral research displayed a decade ago: an operational cost becomes the water everyone swims in, and nobody prices it (Goodwin, 2014). I wrote about that mechanism in the communication tax your business pays every day. This was a communication tax with a start date.
The explanations that were wrong
Before the right explanation, it is useful to walk through the wrong ones, because they are the ones every business reaches for first, and each one points at a fix that would have wasted money.
The first wrong explanation was that the software was broken. It was not. The platform was doing exactly what it was told with the data it had. Buying a different platform, the fix this explanation implies, would have transplanted the same underlying problem into a new tool and added a second migration on top of the first.
The second wrong explanation was user error. It was not that either. The sales team was using the templates correctly. Retraining the team, the fix this explanation implies, would have taught people to work around a fault instead of removing it, which institutionalizes the manual rebuilding forever.
The third wrong explanation was that the supplier’s data feed was down. The feed was fine. The supplier connection was syncing. Escalating to the supplier, the fix this explanation implies, would have produced a support ticket confirming that everything on their end worked, which is true and useless.
Notice what all three explanations share. Each one blames a single component, and each component, examined alone, was healthy. The failure did not live in any component. It lived in the connection between them, which is precisely where nobody was looking, because connections do not have a login screen you can stare at.
The diagnosis
The reframe that cracked it was to stop asking which tool is broken and start asking where the information stops flowing. Treated that way, the problem became traceable. An estimate template asks the supplier library for a product by name. Follow one product from the template to the library and watch where the request dies.
It died at the name. The version migration had left the templates referring to products by names the supplier library no longer used. A template item read like this: Shingles, Lifetime, GAF, Timberline HDZ. The actual item in the synced supplier library read like this: SHINGLES, Generic, GAF Timberline HDZ StainGuard AR Shingles. To a human, those are obviously the same shingle. To a system matching on names, they are strangers. Every material line in every template was making a request the library could not answer, and the estimate rendered without materials because, as far as the software was concerned, the materials it was asked for did not exist.
There was a second fault underneath the first, and it is the kind of thing a systematic diagnosis catches and a quick fix misses. The account had two separate supplier connections active at once, a leftover from an earlier configuration, and the redundant connection was interfering with the sync the templates depended on. Even with the names repaired, that duplicate account would have kept producing intermittent, unexplainable misses, the kind of ghost problem that erodes a team’s trust in the whole system. The supplier had no self-serve way to remove it, so deactivation had to be requested through them directly, a dependency worth knowing about before it bites you.
The proof came the way proof should, with a test rather than a theory. One template, rebuilt with the corrected pricing book names against the single clean connection, generated a complete estimate with labor and materials attached. The diagnosis took an afternoon of systematic work. The problem it ended had been taxing every quote the company sent.
The handoff decision
With the root cause proven, there was a fork in the road, and how it was handled says something about how this kind of engagement should work. Two options went to the owner. Option one: stop at the diagnosis, and hand over a step-by-step document for rebuilding the remaining templates in-house, so the company owns the repair and the knowledge. Option two: rebuild the affected templates directly, then review them together to validate the result.
The point of offering the fork is that the client chooses how much of the fix to own. Teaching the repair costs the client some internal time and builds capability. Doing the repair costs less of their time and gets the sales team back to full speed faster. Neither answer is wrong, and a consultant who only ever offers one of them is optimizing for himself. What should never be on the menu is a black box, a fix nobody in the building understands, because the next migration will come, and a company that understood this repair will catch the next break in a day instead of a month.
What the fix cost, against what the break was costing
Put numbers next to each other, because the asymmetry is the lesson. The diagnosis took an afternoon, and the template repair after it is measured in hours. The break, left alone, was metered. Price a failure like this in any business with the convention from the communication tax: minutes per manual rebuild, times rebuilds per day, times loaded hourly cost, times working days. Take an illustrative sales operation rebuilding four quotes a day at twenty minutes each. That is eighty minutes daily, and at a blended 38 dollars an hour across 240 working days it comes to roughly 12,000 dollars a year, for this one break, before counting a single quote that went out late or wrong to a homeowner comparing three bids. Omnine’s convention is deliberately conservative, and even the conservative number dwarfs an afternoon of systematic work.
The deeper point is structural. A diagnosis is a fixed cost, small and paid once. An unrepaired break is a metered cost, unbounded and paid forever, and because it is collected in twenty-minute increments it never triggers the alarm a single 12,000 dollar invoice would. When a business hesitates over the cost of fixing a flow, it is almost always comparing a visible small number against an invisible large one, and choosing the expensive option while feeling frugal.
The migration tax
Zoom out from roofing, because the general pattern is the valuable part. Version migrations are sold as upgrades, and mostly they are. What the sales page never mentions is that a migration is also a controlled demolition of your integrations. Every connection between the migrating tool and the rest of your stack, every place where system A refers to something inside system B by name or by identifier, is a candidate to break silently. The tools themselves will both report healthy, because they are. The connection between them is what died, and no dashboard watches the connections.
The modern data says this blind spot is close to universal. McKinsey’s research on where AI investment produces real financial return keeps arriving at the same answer: the gains come from redesigning how work flows end to end, not from the tools themselves, and only about one in five organizations has done that work (McKinsey, 2025). A business that cannot see its own connections cannot redesign them, and a business that only audits its tools will pass every audit while paying the tax every day.
So here is the discipline, stated as a checklist you can run before and after any software migration, whether it is a CRM, a scheduler, an accounting package, or anything else that talks to anything else. Before migrating, inventory every connection: list each system the migrating tool exchanges information with, and for each one, note what the exchange is keyed on, names, codes, or identifiers. After migrating, test one real transaction end to end through every connection on that list, a real quote, a real booking, a real invoice, and watch the data arrive on the far side. Do it the same day. A break found on day one is a configuration task. A break found in month two, after the workarounds have calcified, is a diagnosis project plus a bad habit to unwind.
The objections
The first objection: why not just call the vendor? By all means call them, but understand what a vendor can see. Vendor support is responsible for their component, and their component was working. The roofing platform functioned. The supplier feed functioned. A problem that lives between two vendors belongs to neither of them, and each will, truthfully and correctly, point at the other. Somebody has to be responsible for the system as a whole, and by default that somebody is you.
The second objection: why did nobody inside the company catch it? Because the people inside the company were busy running a roofing business, which is what they should be doing, and because normalization works fast. The rebuilding became routine within weeks. This is not a failing of the team. It is what the research says organizations do with costs that arrive in small daily increments: they stop seeing them (Goodwin, 2014). The value of an outside diagnosis is not superior intelligence. It is the unfamiliarity that makes the invisible chore look like what it is, and a method that starts from the flow of information instead of from any single tool. If you want to build that evaluation lens yourself, it is the subject of how to evaluate an AI tool as a leader, not an engineer.
The third objection: this was a configuration problem, not an AI problem, so why is an AI consultancy telling the story? Because the naming layer that broke here is the same layer every automation you will ever build depends on. A workflow that moves information on its own is only as reliable as the connections it moves across, and the discipline of mapping, testing, and maintaining those connections is the unglamorous foundation under everything with AI in its name. Fixing the flow underneath is the work; the trap of skipping it and buying another tool instead is covered in why buying more AI tools is making you slower.
The move
If you have migrated any core system in the past year, run the after-half of the checklist this week: one real transaction, end to end, through every connection that system has, watching the data land. If you find a place where a person has been quietly bridging a gap by hand, you have found your version of the rebuilt quote, and the fix is almost always cheaper than the habit. The problem-first sequence for acting on it is laid out in AI adoption starts with a problem, not a tool, and if you want a fast structured read on where your operation is leaking, the Omnine AI Readiness Assessment takes about three minutes.
References
Goodwin, M. R. (2014). A qualitative descriptive multiple-case study: Fortune 500 leaders’ social business platform adoption (Doctoral dissertation, University of Phoenix). ProQuest Dissertations Publishing (UMI No. 3648813).
McKinsey & Company. (2025). The state of AI in 2025: Agents, innovation, and transformation. McKinsey Global Survey on the state of AI.