E-Commerce and AI: The Catalogue Is the Product, and It Is Usually the Bottleneck
Storefronts are a solved problem. What still consumes a team is everything behind it: product data that arrives inconsistent, listings duplicated across marketplaces, and an operations layer that grows faster than the catalogue does.
It has not been difficult to put a competent storefront online for some years. Checkout, payments, responsive product pages and a content-managed homepage are commodity capabilities, and a custom build that delivers only those is usually the wrong project. Yet e-commerce teams remain conspicuously busy, and the work that occupies them sits almost entirely behind the storefront: getting product data into a usable state, keeping listings consistent across channels that each want something different, and handling the order exceptions that no amount of front-end polish prevents.
That is where AI has something to offer, and it is a less exciting pitch than personalised recommendations. It is also the one that reliably returns time.
Product data is the actual constraint
Catalogue data arrives from suppliers in whatever shape the supplier keeps it: spreadsheets with inconsistent column names, descriptions written for a different market, attributes encoded in the product title because there was nowhere else to put them, images at unusable resolutions, and the same physical item appearing under three different codes across two suppliers. Every downstream problem (poor on-site search, thin listings, failed marketplace validation, incorrect filtering) traces back to this.
- Attribute extraction. Pulling structured fields out of unstructured titles and descriptions is the highest-yield application in the category, because structured attributes are what search, filtering and marketplace feeds all depend on.
- Normalisation and deduplication. Recognising that two supplier records describe the same item is judgement work that scales badly with people and well with a model, provided a human confirms merges.
- Description generation. Drafting channel-appropriate copy from structured attributes, reviewed before publication. The structured data must come first; generating prose from bad data produces confident, fluent errors.
- Categorisation and taxonomy mapping. Every marketplace has its own tree, and mapping into each one by hand is the reason adding a channel is expensive.
Extraction before generation, always
Teams frequently start with description generation because it demonstrates well. It is the wrong first step. Generated copy built on unstructured, unreliable source data is fluent and wrong, and it is harder to audit than the mess it replaced. Extract structure first, verify it, then generate from the structure.
Multi-channel operations is where cost compounds
Selling on a single storefront is straightforward. Selling on a storefront plus several marketplaces introduces a problem that grows with the product of channels and SKUs: each channel has its own listing requirements, its own category tree, its own image rules, its own order format and its own idea of what a return is. Teams typically absorb this with people, and the headcount required rises with every channel added.
The architectural answer is an internal canonical product model that owns the truth, with per-channel adapters that translate outward. This is not novel, and it is frequently skipped because the first channel does not need it. The cost of skipping it appears at the third channel, when changing an attribute means editing it in several places and nobody is sure which is authoritative.
Inventory truth, and why it should stay boring
Stock levels across multiple sales channels are a synchronisation problem with a correct answer, and it should be solved deterministically. Overselling is not an acceptable probabilistic outcome; it produces a cancellation, a refund, a marketplace penalty and a customer who does not return. The same principle that applies in warehouse systems applies here: keep the arithmetic exact, and place the intelligence where a wrong answer is caught before it reaches a customer.
Personalisation is worth less than the basics
Recommendation and personalisation are the most requested AI features in e-commerce and rarely the highest-value ones for a mid-sized catalogue. They depend on behavioural volume many stores do not have, and they sit downstream of exactly the product data quality discussed above. A recommendation engine reading a catalogue with missing attributes and duplicated items will recommend duplicates and miss obvious matches, and the conclusion drawn will be that the engine is poor.
Fixing search and filtering first is less interesting and usually more valuable, because a customer who can find the thing they came for does not need to be recommended it.
Almost every e-commerce problem presented as a front-end problem is a product-data problem wearing a front end.
For e-commerce and operations leaders
Before commissioning a rebuild, look at where the hours actually go. If the team is spending them on listing maintenance, supplier onboarding and order exceptions rather than on the storefront, a new storefront will not change the number. The question worth putting to a prospective partner is how they would model the catalogue and where the canonical product record lives, because that answer determines whether the fourth sales channel costs a sprint or a hire.