Three reasons your retail data never gives you the right number

Every retail operator we talk to has a version of the same complaint: nobody in the company agrees on the margin per SKU. Finance has one number, the marketplace dashboard has another, and the store manager has a third that came from a spreadsheet somebody built in 2023.

This is not a discipline problem. It is an architecture problem, and it shows up in three predictable shapes.

1. The data is spread across systems that were never meant to talk

Shopify or Magento on the storefront. Bling or Tiny or Omie on the back office. Marketplace orders arriving through an API with documentation that is either incomplete or wrong. Logistics costs in a carrier portal. And a spreadsheet that finance maintains by hand to reconcile whatever the systems disagreed about that month.

Each of those tools is fine at what it does. None of them was designed to answer "what did we actually earn on this order". The margin per SKU lives in the gaps between them, and the gaps are where humans do arithmetic.

What we build: a data layer that pulls from every source on a schedule and lands it in one warehouse with a consistent shape. Not a rip-and-replace. Your ERP stays your ERP. What changes is that there is finally one place where an order, its cost, its fees, its shipping, and its returns are the same row.

The unglamorous truth is that this step, the pipe, is most of the work and none of the demo. It is also the step that everyone skips before wondering why the AI project produced nothing. We wrote about that failure mode in AI without a data foundation.

2. The BI tool answers last quarter's questions

You bought Power BI or Metabase. Somebody built 200 dashboards. They were correct on the day they shipped.

Then the business changed, and now every new question is a ticket. The sales team wants to know which customers stopped buying sixty days ago. The buyer wants to know which categories are carrying inventory into the next season. The ticket sits in the data team's queue for a week, and by the time the answer arrives the question has moved on. So people stop asking, and the expensive BI tool becomes a monthly screenshot in a deck.

What we build: a conversational layer over the warehouse. Someone types "top five SKUs by margin this month" or "orders pending more than three days" and gets a number, a list, or a chart. The agent writes the SQL, runs it against your data, and shows both the answer and the query it used so an analyst can check the work.

This is not a replacement for BI. Dashboards are still right for the metrics you look at every day. It is a replacement for the ticket queue, which is where the actual bottleneck is. You can try the pattern on fake data in our live demo.

3. Software should be doing the work that people are doing

Launching products. Reclassifying SKUs after a taxonomy change. Pushing price updates across four channels. Checking that yesterday's orders actually got paid. Watching a competitor's listing.

None of this requires judgment. All of it requires attention, which is why it gets assigned to a person, and why it is done inconsistently and late.

What we build: agents that handle the mechanical loop continuously and escalate the judgment calls. Two examples that come up most often in retail and that we do not cover in the catalog of what we build for retail:

Conversational anti-fraud. An order trips the risk rules. Today it sits in a queue until an analyst gets to it, and the legitimate customer waits. An agent can open the conversation instead: ask for the documentation, validate the identity and address against the sources you already subscribe to, and either release the order or hand a summarized case to the analyst. The queue shrinks and the honest customer gets their order faster.

Omnichannel reconciliation. An order placed on a marketplace, paid through one processor, shipped by a third-party carrier, partially returned three weeks later. Four systems, four partial truths. An agent pulls each side and closes the math. What used to be a monthly reconciliation exercise becomes a daily one, which means you find the leak in week one instead of week five.

The pattern underneath all three

Notice that none of these start with a model. They start with getting the data into one place, and then putting something on top of it that either answers questions or does work.

That order matters. An agent with no access to reliable data is a chatbot that guesses. The reason retail AI projects stall is almost never the model. It is that nobody wanted to do the plumbing first.

If one of these three shapes describes your operation, thirty minutes is enough for us to tell you which one is actually your bottleneck and roughly what it takes to fix it.