NO SINGLE CUSTOMER
The same person is three records: one in the shop system, one in the website, one in the loyalty scheme. Lifetime value is guesswork.
USE CASE / RETAIL & E-COMMERCE
Four systems, four answers to "how many customers do we have".
Customers, orders, stock and campaigns almost always live in different systems that were bought at different times for different reasons. Each one is right about its own piece and wrong about everything else. Every cross-system question then becomes a project instead of a query.
What usually goes wrong
STOCK IS ALWAYS LATE
The stock figure on the website is hours behind the warehouse. You either disappoint customers or you hold stock you do not need.
MARKETING CANNOT PROVE ANYTHING
Campaign spend sits in one tool and revenue sits in another. Nobody can say which campaign actually paid for itself.
PRODUCT DATA IS MESSY
The same product arrives from three suppliers under three names, with missing sizes, missing categories and inconsistent units.
THE REPORT ARRIVES TOO LATE
The weekly trading report lands on Wednesday for a week that ended on Sunday. By then the decision has already been made without it.
What we build
- A single customer record that joins shop, website, app and loyalty data, with clear rules for how records are matched.
- One product and order model that every team uses, so the word "order" means the same thing to finance and to operations.
- A near-real-time stock feed, so the website and the warehouse are minutes apart instead of hours.
- A metric layer where margin, basket size and lifetime value are each defined once, in one place, and reused everywhere.
- Marketing spend joined to actual revenue, so campaign performance is a number and not an argument.
- Data quality tests that stop a bad product feed before it reaches the website.
What AI looks like here
Ask-your-data assistant
- What it does
- A buyer or merchandiser types a question in normal English — "top twenty products by margin in the south region last month" — and gets a table and a chart back, without waiting for an analyst.
- How it works
- The question is sent to a language model along with a description of the approved metric layer. The model writes a query against that layer only, never against raw tables. The query runs, and the result comes back with the query shown underneath so it can be checked.
- What it needs
- A governed semantic layer with agreed definitions, row-level permissions so each user sees only their region, and a strict rule that the model can only use approved tables.
Product data cleanup with embeddings
- What it does
- Finds products that are the same item under different supplier names, and fills in missing categories and attributes from the product description text.
- How it works
- Every product name and description is turned into an embedding, which is a numeric fingerprint of its meaning. Products with very similar fingerprints are grouped as likely duplicates and sent to a person to confirm. A model then reads descriptions and proposes the missing attributes.
- What it needs
- A clean product feed, a vector store, and a review screen. A human confirms every merge — the system proposes, it does not decide.
Daily trading note
- What it does
- Every morning, a short written note for the trading team: what sold, what is about to run out, what looks unusual, and why.
- How it works
- The platform calculates the numbers as it always did. A model then turns those numbers into three short paragraphs of plain English, following a fixed template. The numbers come from the warehouse. The model only writes the sentences around them.
- What it needs
- Reliable daily loads that finish before the note is written, a fixed template, and a rule that the model never invents a number that is not in the data it was given.
The tools we use here
- Snowflake or Databricks
- dbt
- Apache Airflow or Dagster
- Fivetran or dlt
- Amazon Kinesis or Kafka
- AWS Lambda
- Amazon S3
- Terraform
- Amazon Bedrock or Snowflake Cortex
- pgvector
- Power BI or Looker
What changes for you
- One customer number that finance, marketing and operations all use without arguing.
- Stock on the website matches the warehouse within minutes.
- The trading team gets its numbers on Monday morning, not Wednesday afternoon.
- Merchandisers answer their own questions instead of joining an analyst queue.
What we will not do
- We do not put customer names, emails or addresses into a language model.
- We do not let an assistant query raw tables. Only the approved metric layer.
- We do not merge two customer records automatically without a person confirming it.
- We do not build a chat tool before the numbers underneath it are agreed and tested.