The week before a major seasonal campaign, someone on the commerce team pulls the product readiness report.
Of the 3,400 SKUs going live across seven retail channels, around a third need manual attribute corrections before the feeds can go out. Some are missing required fields for specific retailers. Some have taxonomy values that do not match the channel's accepted classifications. Some were created by the supplier data team using a template that has not been updated to reflect the current channel specifications. A handful have conflicting values across the PIM, the ERP, and the commerce system, and nobody is certain which version is correct.
The team knows what happens next. Someone builds a spreadsheet. Responsibilities get divided. People work through it over the following three days, alongside everything else they were supposed to be doing that week. The feeds go out on time. The campaign launches. Leadership sees the launch date met and the channel coverage achieved.
What leadership does not see is the invoice.
Not a literal invoice. There is no line item in the budget that reads "cost of correcting product data before campaign launch." The cost is distributed. It lives inside the overtime hours, the delayed projects, the team members pulled away from higher-value work, the retailer relationships strained by late or incomplete submissions, and the quiet understanding across the commerce operation that this is just what the week before a major campaign looks like.
It has always looked like this. It will look like this again before the next one.
Why Product Data Workarounds Stay Invisible Until They Are Enormous
The reason workaround costs rarely get calculated is structural. They are distributed across teams, time periods, and activities in a way that makes them impossible to see on a single report or dashboard.
A product manager spending three hours correcting attribute values before a retailer submission records that time as product management work. A commerce operations lead spending two days building and maintaining a master correction spreadsheet before a seasonal launch records that time as campaign preparation. A data team member investigating a rejected feed to identify which attribute caused the rejection records that time as operational support.
None of these are recorded as what they actually are: the cost of product data quality problems that were never resolved at source.
According to PwC's 2026 Digital Trends in Operations Survey, based on 767 operations and supply chain leaders at US companies, 89% of organisations say their technology investments have not fully delivered expected results, and poor data quality is specifically identified as impacting organisations' ability to achieve value from digital initiatives. The survey surfaces a paradox that most commerce operations leaders will recognise: 84% of leaders say they have become comfortable making decisions even when data is not perfect, while simultaneously acknowledging that poor data undermines outcomes.
That paradox has a name in daily operations. It is called a workaround.
The workaround is the gap between what the data should be and what it actually is, filled in by human effort at the point of execution. And because the effort is distributed across many people making many small corrections continuously, it rarely accumulates into a number that anyone calculates.
MIT Sloan Management Review research by Thomas Redman found that poor data quality costs organisations between 15% and 25% of revenue. The most significant component of that cost is not the errors themselves. It is the human effort spent accommodating those errors — correcting them, working around them, seeking confirmation in alternative sources, and dealing with the downstream consequences when neither correction nor workaround is sufficient.
That accommodation cost is what most commerce and product data teams are carrying. Silently. Continuously. At scale.
The Three Categories of Product Data Workaround Cost
Most organisations think about workaround cost as a single type of problem: people doing manual work that should be automated. The actual cost structure is more complex than that and more expensive. Product data workarounds create cost in three distinct categories simultaneously, and all three are running at the same time in most commerce operations.
Direct Labour Cost — The Hours That Should Not Exist
The most visible component of workaround cost is the direct labour required to perform the correction.
A feed enrichment sprint before a major retailer onboarding. A taxonomy reconciliation exercise before a marketplace expansion. A data cleaning project triggered by a channel compliance audit. An attribute correction cycle before every seasonal campaign.
Each of these consumes hours from people whose time carries a cost. In most organisations, the people doing this work are product managers, commerce operations specialists, or data stewards — roles that are not cheap and are not supposed to be spending their time correcting records that should have been complete when they were created.
The direct labour cost of a single correction cycle is calculable: hours spent multiplied by the loaded cost of the people involved. What makes this cost structurally invisible is that it is never calculated. It is absorbed into the role's general activity and reported as operational work rather than as a cost of poor data quality.
Across a year, across every campaign, every retailer onboarding, every channel expansion, every new product introduction cycle — the accumulated labour cost of these corrections represents a significant operational expense that most organisations have never seen on a single report.
Opportunity Cost — The Work That Did Not Happen
The second category is less visible and more expensive over time.
When a product manager spends three days correcting attribute values before a retailer submission, those three days were not spent on something else. The channel expansion analysis that was supposed to happen that week was deferred. The product content improvement project that had been scheduled got pushed. The competitive pricing review that needed to be completed before the end of the quarter was deprioritised.
Workarounds do not just consume time. They consume the capacity for the higher-value work that the people doing them were hired to do.
In a commerce operation running continuous correction cycles — which is most commerce operations — the opportunity cost compounds. Teams become perpetually reactive, organised around the next correction cycle rather than around strategic product data improvement. The work that would prevent the correction cycle from being necessary never gets done, because the correction cycle consumes the capacity that would have been used to do it.
This is the mechanism MIT Sloan Management Review describes as organised cleanup mode: a state in which organisations have formalised their response to bad data without addressing the conditions that create it. As MIT Sloan research on proactive data quality management explains, companies that remain in organised cleanup mode find the gains are generally small. Finding errors is straightforward. Fixing them without understanding the business context is not. And the cycle continues because the root cause — data being created without quality standards enforced at source — is never addressed.
The opportunity cost of remaining in this mode is not just the time lost. It is the strategic progress that never happened.
Downstream Execution Cost — What Goes Wrong Despite the Workaround
The third category is the cost that accumulates when the workaround is insufficient, late, or simply missed.
A retailer feed goes out with a corrected set of attributes, but the correction was based on last quarter's specification. The retailer has updated their requirements. The feed is rejected. The team investigates. A resubmission is prepared. The window for the promotional placement was missed. The product does not appear in the retailer's seasonal campaign at the planned position.
A marketplace expansion onboarding is delayed because the enrichment sprint that was supposed to clean the data before submission was not completed on time. The delay costs two weeks of channel availability during a peak trading period.
A new product launch goes live across four retail channels with incomplete specifications because the correction cycle ran out of time before the launch deadline. Customer-facing pages show incomplete product information. Conversion rates for those SKUs underperform against the campaign forecast.
These are downstream execution costs: revenue impact, channel relationship damage, and operational disruption that occur because the workaround either failed to compensate fully for the underlying data problem or was not completed in time to prevent the consequence.
Deloitte's research on manual adjustments in the data supply chain identifies exactly this dynamic: manual adjustments across the data supply chain increase complexity and operational risk with a cumulative impact on business outcomes. The cumulative nature of that impact is the critical observation. Each workaround that partially compensates for a data problem leaves residual risk. That residual risk accumulates across every correction cycle, every campaign, every channel, and every product category that is being maintained through manual intervention rather than through a data foundation that performs reliably without it.
Why Workarounds Feel Like Problem-Solving When They Are Actually Problem-Deferring
There is a reason workarounds persist in organisations that have the resources and the intention to fix the underlying data problems. They work. In the short term, for the immediate deadline, the workaround delivers the result that was needed. The feed goes out. The campaign launches. The onboarding completes.
That short-term success is what makes workarounds so expensive over time.
Every time a workaround delivers the immediate result, it reinforces the belief that the situation is manageable. The campaign launched. The retailer accepted the feed. The quarterly targets were met. The underlying data problem is still there, but the evidence of its cost was absorbed by the team that corrected it and distributed across time and activity in a way that never produced a visible number.
The next correction cycle begins with the same data foundation the last one started with, because the workaround addressed the symptom and the root cause was deferred to a point when things are less busy, when there is more resource available, when the next governance initiative gets prioritised.
That point rarely arrives. Because the next correction cycle is already consuming the capacity that would have been used to address the root cause.
This is the pattern MIT Sloan identifies as the common trap: organisations see themselves as data customers who consume data created elsewhere, correcting errors as they encounter them. They do not see themselves as data creators who are responsible for the quality of the data at the point it enters the system. The correction cycle perpetuates itself because the mindset that would break it — every person who creates or modifies data is responsible for its quality at source — never gets established.
The workaround culture and the data quality problem are self-reinforcing. Workarounds make it possible to operate without addressing the root cause. Operating without addressing the root cause guarantees that workarounds will always be necessary.
The Compounding Effect — Why Workaround Costs Grow Faster Than the Business
The most dangerous characteristic of product data workaround costs is that they compound.
As a commerce operation grows — more products, more channels, more retailers, more campaigns, more regions, more supplier relationships — the volume of data that needs to be maintained grows with it. If that data is being maintained through correction cycles rather than through a quality foundation, the correction work grows proportionally with the business. More products means more records to correct. More channels means more channel-specific requirements to accommodate. More retailers means more feed specifications to manually maintain.
The business scales. The workaround cost scales with it.
In an organisation managing product data well — with governance embedded in the systems where data is created, with ownership enforced through workflow checkpoints, with quality standards applied at the point of entry — business growth does not proportionally increase the correction workload. The foundation absorbs the growth because the standards and controls apply to new products and new channels through the same system logic that applies to existing ones.
In an organisation managing product data through workarounds, growth creates more workarounds. The correction team grows. The correction sprints get longer. The tools built to manage the corrections — the master spreadsheets, the validation macros, the pre-submission checklists — become increasingly complex. The institutional knowledge of how to run the correction cycle becomes a critical operational dependency, concentrated in a small number of people who know which retailer requires which format and which product category needs which manual override.
That concentration of knowledge in individual people rather than in documented, system-enforced standards is itself a risk that most organisations have not priced. When those people leave, or change roles, or are unavailable during a critical launch window, the correction capability temporarily disappears and the consequences arrive immediately.
What the Workaround Budget Would Look Like If Anyone Built It
Most organisations have never tried to calculate the total cost of their product data workarounds. The distributed nature of the cost makes it genuinely difficult to aggregate. But the exercise is worth attempting, because the number that emerges is almost always larger than expected and almost always larger than the investment that would be required to address the root cause.
A workaround budget for a typical commerce operation would need to account for:
Direct correction labour: The hours spent by product managers, commerce operations specialists, data stewards, and marketing operations teams on attribute corrections, taxonomy reconciliations, feed reformatting, enrichment gap filling, and data conflict resolution — multiplied by the loaded hourly cost of those roles — across every campaign, every retailer onboarding, every channel expansion, and every new product introduction cycle in a twelve-month period.
Management oversight of corrections: The time spent by team leads and managers planning correction sprints, allocating resource, reviewing outputs, managing escalations, and reporting on readiness status — all of which exists because the correction cycle exists.
System and tooling cost: The licences, build time, and maintenance cost of the tools built to manage corrections — validation spreadsheets, data cleaning scripts, pre-submission checklists, custom integrations designed to compensate for data quality gaps between systems.
Downstream execution failures: Lost revenue from retailer feed rejections, delayed channel launches, incomplete product pages, missed promotional placements, and onboarding delays — each of which can be partially or fully attributed to product data quality gaps that workarounds failed to compensate for in time.
Opportunity cost: The value of the strategic work that was deferred because the correction cycle consumed the capacity that would have been used to do it. This is the hardest to calculate and the most significant over time.
Most organisations that have attempted this calculation have found the total exceeds the cost of the governance, system, and process investment that would address the root cause. The workaround is more expensive than the fix. It is simply more visible as individual corrections and less visible as an aggregate cost.
Why Workarounds Survive Governance Initiatives and Platform Migrations
The previous blogs in this series established two specific patterns. Replatforming rarely eliminates product data problems because the migration moves the data without changing the conditions that create the problems. Governance initiatives rarely produce lasting operational change because the frameworks they produce sit above the operational workflows where data decisions actually happen.
Both patterns produce the same consequence: the workaround survives.
After a platform migration, the correction cycle continues in the new environment because the data foundation that was migrated was the same data foundation that required corrections before the migration. The platform changed. The correction workflow transferred with the data.
After a governance initiative, the correction cycle continues because the governance framework defined the standards without embedding them in the systems where records are created. The standards exist in the documentation. The correction workflow continues because the system does not enforce the standards at the point of data creation.
This is why workaround costs are so persistent. They are not caused by any single failure. They are the cumulative consequence of a series of investments — platform, governance, ownership — that each addressed a visible aspect of the product data problem without reaching the root cause: the absence of quality enforcement at the point where data enters the system and at every point where it is subsequently modified.
Until that enforcement exists — in the form of validation rules, required fields, controlled vocabularies, automated completeness checks, and workflow checkpoints that prevent non-compliant records from progressing — the workaround will fill the gap. Because something has to.
How to Calculate What Your Workarounds Are Actually Costing
Before scoping the next data quality initiative, technology investment, or governance programme, one exercise is worth completing.
Map every correction cycle your commerce and product data teams run in a typical quarter. For each one, record:
- Who performs it and how many hours it takes
- What triggers it — a campaign, a retailer submission, a channel onboarding, an audit
- What the consequence would be if it were not performed
- Whether it addresses the same underlying issue as the previous cycle
Then apply a loaded cost to the hours. Add an estimate of the downstream revenue impact of the correction cycles that were incomplete or late. Add the management time spent planning and overseeing them.
The number that results is your current workaround budget. It is what you are already spending, distributed invisibly across roles and activities, to compensate for a data foundation that does not perform reliably without human intervention.
Compare that number to the cost of the investment that would reduce it. In most commerce operations, the comparison is instructive. The workaround budget is larger. Often significantly larger. And unlike an investment in fixing the root cause, the workaround budget does not decrease over time. It grows with the business.
What would it take for your largest seasonal campaign to launch without a correction sprint in the week before it? If the answer is unclear, the workaround budget is doing more work than the data foundation, and the gap between them is costing more than most organisations have calculated.
What Organisations With Low Workaround Costs Do Differently
Organisations that have genuinely reduced their product data correction workload share a characteristic that is less about the sophistication of their technology and more about where quality is enforced.
In a low-workaround commerce operation:
- Product records cannot be activated until completeness thresholds are met for every configured channel. The incomplete record does not reach the submission queue. It gets flagged at creation, not at launch week.
- Taxonomy classifications are controlled vocabularies in the PIM. A product manager cannot enter a free-text category. They select from approved values. The taxonomy drift that creates downstream feed rejections does not accumulate because the system does not permit the local classifications that cause it.
- Supplier data goes through an automated validation on ingestion. Records that do not meet the quality threshold are quarantined before they enter the active product catalogue. The enrichment gap sprint before every campaign launch does not exist because the gap is identified and resolved before the record is ever live.
- Channel-specific attribute requirements are mapped to product creation workflows. When a product is assigned to a channel, the system surfaces the required attributes for that channel and flags gaps immediately. The channel compliance discovery that currently happens during pre-submission review happens at the point of product creation instead.
None of these require extraordinary technology. They require the quality standards that governance initiatives typically document to be translated into system logic — validation rules, required fields, workflow triggers, automated checks — rather than left as policies that teams are expected to remember and apply manually.
The translation is the work. And it is the work that most organisations defer because it comes after the governance initiative closes and the project has already been declared complete.
ThoughtSpark works with enterprise data and commerce teams to identify where product data workaround costs are accumulating and what it takes to build the operational foundation that reduces them. If the correction cycles described in this article are a recognised part of your commerce operation, the conversation worth having is about the cost of continuing them versus the investment required to address what is causing them.