We built SuperCommerce based on problems we saw firsthand during years working in commerce infrastructure. We had strong intuitions about where catalog data and fulfillment operations were most broken, and we had a product thesis about the kind of platform that could address them. Then we gave early access to a small group of retailers and spent six months watching what actually happened.
This post is honest about what we got right, what we got wrong, and how it changed what we are building. If you are considering working with us, this is the most accurate picture we can give you of what the platform does today and where it is heading.
We are not going to name the retailers in our early access group. Some of them asked us not to, and we think that is a reasonable request. The observations are real; the specifics are generalized.
What We Got Right
Our hypothesis going in was that the catalog data problem and the fulfillment routing problem are connected at a level most retailers do not fully recognize. Catalog quality affects demand signals. Demand signals affect inventory planning. Inventory planning affects fulfillment routing effectiveness. A gap in catalog attribute completeness does not just hurt discoverability in isolation. It distorts the demand data that the operations team uses to stock fulfillment nodes ahead of peak periods.
The pilot data confirmed this connection. Every retailer in the early access group had examples where a product performed below forecast during a peak period, and where some portion of that underperformance was traceable to catalog gaps that suppressed the leading traffic signals that should have indicated higher-than-expected demand. The connection is not always dramatic, but it is real, and it is systematically underestimated because catalog health and demand forecasting are typically owned by different teams with different tooling and different reporting lines.
We also got right that the exception management queue in enterprise retail is a larger operational drain than most operations teams are tracking explicitly. We knew this in theory. Seeing it in practice with real retailers, and measuring where their people-time was actually going, made the scale of it concrete. A mid-market retailer with a 150,000 SKU catalog, operating from three fulfillment nodes, was spending a meaningful portion of one full-time equivalent on exception queue management during peak periods. The math on this kind of capacity cost is rarely made explicit in the operations review, because exception handling gets bundled into general operations labor rather than tracked as a distinct activity.
What We Got Wrong
We underestimated how much variability there would be in the starting condition of retailers' catalog data. We built our catalog normalization tooling assuming a reasonably consistent baseline: product records with complete core attributes, some inconsistency in extended attributes, a manageable backlog of attribution gaps. What we found was that the baseline variability is much higher than that.
Some retailers had recently migrated from one platform to another and had a catalog in a genuinely messy state, with attribute fields that had been mechanically migrated without any normalization. Others had grown through acquisition and had two or three distinct catalog schemas that had never been properly merged. The "reasonably consistent baseline" we assumed was the exception, not the rule.
This forced us to build more robust data ingestion and normalization tooling than we had originally planned, and to be honest with retailers about the onboarding time required to get catalog data to the state where our AI enrichment features produce reliable output. The enrichment layer works well when the input data is reasonably clean. It produces less reliable output when the input data has structural inconsistencies that our normalization layer does not catch. Acknowledging this directly in the early access process changed how we scoped the onboarding work and led to better outcomes for everyone.
We also underestimated the importance of explainability in the routing decisions our fulfillment system makes. We built an effective routing engine. What we did not build well enough in the first iteration was the tooling that lets an operations manager understand why a specific routing decision was made and how to override it when their local knowledge tells them something the model does not know.
Fulfillment operations teams develop deep expertise about carrier behavior in their specific regions, warehouse-specific operational quirks, and seasonal patterns that are not fully captured in any data feed. When our routing engine made decisions that seemed correct based on the data but conflicted with an operations manager's judgment, and the manager could not see enough of the routing logic to evaluate the decision, the response was to route around the automated system entirely. That is the failure mode we needed to prevent. We added routing decision transparency tooling in the second iteration of the pilot, and the adoption rate improved materially.
What the Retailers Taught Us to Build Next
The feature request we heard most consistently was not something we had planned: better tooling for understanding which catalog gaps are actually costing revenue versus which are just data quality issues that have no material effect. Catalog teams know their data is imperfect. What they do not have is a prioritized view of which imperfections are generating real revenue loss and which can be deprioritized.
We have been working on this since the pilot. The approach is to connect catalog attribute completeness metrics to actual shopper behavior: search queries that return incomplete results due to attribute gaps, filter paths that dead-end because the relevant attribute is missing on high-traffic products, category browse sessions that end without a click because the attribute-based sort is producing poor results. The goal is a prioritization layer that takes a catalog operations team from "here are all the products with missing attributes" to "here are the 80 products where closing the attribute gap is likely to affect revenue in the next 30 days."
The second common request was for better alerting on fulfillment routing drift. All of the retailers experienced periods where the routing decisions gradually drifted out of alignment with operational reality, usually because something in the carrier landscape or node capacity changed and the routing model was not updated quickly enough. The operations team discovered the drift when they saw its effects in late deliveries or exception spikes, not in advance. Early warning tooling that identifies when routing decision quality is degrading, before the degradation shows up in customer-facing outcomes, is something we are building based directly on what we heard.
Where We Are Being Honest About Limits
We want to be specific about what SuperCommerce does not do today, because overstating capability during an early access phase is how you destroy the trust that makes an honest working relationship possible.
Our catalog AI enrichment works well for product types that are well-represented in our training data. It works less well for highly specialized product categories, particularly in industrial and technical product lines where the attribute requirements are domain-specific and our models have not seen enough training examples to be reliable. We are honest with retailers in these categories that the initial output quality will require more human review, and we scope the onboarding accordingly.
Our fulfillment routing handles the standard case of domestic multi-node routing for direct-to-consumer orders well. It handles cross-border routing, marketplace-specific fulfillment requirements, and dropship-heavy catalog operations less well at this stage. We tell retailers with significant volumes in these scenarios that the routing coverage for their use case is on our roadmap but not in the current release.
We are an early-stage company. Our product is improving quickly, but it is not feature-complete against the full range of enterprise retail complexity. The retailers who get the most value from us at this stage are those who have a specific, well-defined problem in the catalog or fulfillment space where the current capability directly applies, rather than those who need us to be a complete commerce data platform on day one. The early access program was designed to find that fit honestly, and the retailers who joined knowing that produced the best outcomes for both of us.
If you are interested in working with us, the right starting question is not "can SuperCommerce solve all of our catalog and fulfillment problems." It is "is there a specific, high-priority problem in our catalog data or fulfillment operations where SuperCommerce's current capability applies, and can we start there." If the answer to that narrower question is yes, we should talk. If your requirement is a complete solution on day one, we are probably not the right fit yet, and we would rather tell you that now than after you have invested in an integration.