AI in E-commerce Operations: Turning AI from a Tool into a Business System

Ask an e-commerce team whether they use AI and almost everyone says yes. Someone rewrites product titles in ChatGPT, someone asks Copilot to fix an Excel formula, someone summarises a competitor's campaign page. All useful, and almost invisible in the results. The time saved stays with one person, nothing is written down, and tomorrow the same question gets asked again.

The teams that get real leverage do something less glamorous. They take the checks and actions they already repeat every day and turn them into a system: the same data every morning, the same rules applied to it, a draft ready for every action, and a person deciding what goes live. AI is one part of that system, not the whole of it.

This piece walks through that system for a team running its own e-commerce site and several marketplaces at the same time. It comes from building a smaller version for a client, a collectibles e-commerce company, and from agent workflows I built for a B2B software company. The scale is different from a national retailer. The logic is the same.

The work is a loop, not a list

Read any commercial operations job description and the tasks look like a list: execute pricing and campaign actions, track daily sales, monitor price accuracy and stock, coordinate listings with content and PIM teams, follow up until things are done, report, watch competitors. In practice they are one loop that runs every day:

1. Look at what happened yesterday and what is live right now.
2. Find what is off: a price that does not match, a product in a campaign with three units left, a listing that never went live.
3. Decide what to do about it.
4. Do it, or ask the right team to do it.
5. Follow up until it is closed, and remember it next time.

Steps one and two, and most of four and five, are mechanical. Step three is judgement. A good system hands the mechanical parts to software and AI, and keeps the judgement with people, who now decide with better information than they had before.

Four layers of an AI business system

1. One snapshot of the business, every morning

Everything starts with a single table that is rebuilt every day: SKU, approved price, live price on each channel, stock, yesterday's sales against plan, campaign status, listing status. It is pulled from the e-commerce platform, the marketplace seller panels or their APIs, the PIM and the campaign calendar. At first it can live in Excel or Google Sheets. What matters is that everyone, people and AI alike, reads the same numbers.

This is the least exciting layer and the one that decides whether anything else works. In the system I built the model was never the hard part. Agreeing on what "in stock" means for a product on pre-order was, as the example further down shows.

2. Checks that run on their own

On top of the snapshot sit checks. Some are plain rules: the live price on a marketplace differs from the approved price by more than an agreed threshold; a SKU is in an active campaign with less stock than a day of sales; a product page went out of stock overnight. Others need the kind of reading AI is good at: a category's sales dropped 30 percent, and the likely reasons are a competitor's price cut and two best-sellers out of stock, written in one paragraph a category manager can act on.

The output is not another dashboard. It is a short morning list: what is off, what it is worth in revenue, and who owns it.

3. A draft for every action

For each item on that list the system prepares the next step: the price update file in the format the platform expects, the corrected title and attributes for the PIM team, the message to the marketplace account manager, the line for the weekly report. A person reviews it and sends it. Writing the request is often slower than making the decision; this layer takes that weight away.

4. Approval, and a log that follows up

Nothing that touches price, stock or spend goes live without a person approving it. Every approved action goes into a log with an owner and a due time, and the next morning's checks verify that it actually happened. Open items roll forward on their own. This is the part that replaces the action-item spreadsheet nobody updates.

What it looks like in a normal week

Inside a real build

One of my clients imports trading cards and sealed collectibles from the US and sells them online in Turkey. I run their digital side, and over the past months I rebuilt the store and the operations around it. When a global set launched, we opened pre-orders in Turkey on the same day as the rest of the world. The launch month returned 15 times its ad spend, and the first stock batch sold out within 24 hours.

That result sits on top of a fairly unglamorous system. Here is what it actually looks like:

Mapped to the four layers above, it reads like this. The snapshot is one database instead of a set of spreadsheets: every product, its price and cost, and stock across the store, the warehouse and parcels still in transit, kept as a ledger of movements so any number can be traced back. The checks run on that data: a nightly job reprices the catalogue from market prices, cost and the exchange rate and sends a short summary of what moved; the product feed decides for each item whether it is in stock, on pre-order with a ship date, or sold out; a daily audit compares a partner's listings with ours. The drafts come from AI: when the supplier logs a box we have never sold, Claude writes a Turkish description and finds images, so the listing is ready before the box arrives. The decisions stay with people: anything we price by hand is locked out of the nightly run, and staff get the morning summary and push alerts rather than silent changes.

The AI pieces earn their place by doing one narrow job well. A model looks at a supplier's photo of a shelf and returns the two or three most likely products with current prices, which speeds up buying decisions. Another reads shipping labels when parcels arrive. For that one I tested two models on the same twelve labels before choosing: one read all twelve correctly at about a sixth of the cost of the other, which read ten. Picking the model was a measurement, not a preference.

The hardest decision in the whole build was not technical. It was agreeing on what "in stock" means for a product that is on pre-order, paid for with a deposit and shipping in three weeks. Once that rule was written down, the storefront, the Google feed and the ads all said the same thing. The system is also not finished, and I would say so in any interview: low stock still shows up only on the admin dashboard, and a proactive alert for products running low inside an active campaign is the next check on the list.

Almost all of it was built by one person with Claude Code. Before this, at a B2B insurtech, I built agents that read every inbound lead, asked follow-up questions and scored it before sales picked up the phone, with a person deciding who to call. 2,500 leads became 300 demos and 40 customers. A different industry, the same pattern: software does the reading and the drafting, people make the call.

Guardrails that make it trustworthy

• Read-only first. The first version only reads and reports. Write access to prices or campaigns comes later, one action at a time, with approval.
• Every check has an owner. An alert nobody owns is noise. Each check names the person or team that acts on it.
• Thresholds, not perfection. A one-kuruş difference is not an issue. Agree on what counts as a deviation, in money, before a check goes live.
• Show the reasoning. When AI explains a sales drop, it shows the numbers it used, so the reader can disagree.
• Measure the system itself. Hours saved per week, issues caught before they cost money, actions closed on time. If those do not move, change the checks.

A 30-day way to start

1. Week 1: the snapshot. One daily table for the top 200 SKUs across the own site and two marketplaces: price, stock, sales, campaign status.
2. Week 2: three checks. Price mismatch, low stock in active campaigns, listings that are not live. A morning list goes to the team.
3. Week 3: drafts. Price update files and listing fix requests are prepared automatically, ready for approval.
4. Week 4: the log and the report. Approved actions are tracked until closed, and the weekly report is drafted from the same data.

After a month the team has not bought a new platform. It has a working loop it understands, numbers to judge it by, and a clear list of what to automate next.

What changes for the people doing the job

The role does not shrink. It moves. Less time finding problems, more time deciding what to do about them and working with the teams who can fix them. The specialist who used to run the checks becomes the person who designs them, and that person ends up knowing the business better than anyone, because they wrote down how it should work.

Turning AI from a tool into a business system does not mean more prompts. It means a clear loop, shared data, and people who own the decisions.