Retail · online storefront + 50 stores

One customer view across online and in-store — with an AI analyst that cannot invent a number

A retailer selling both online and through more than fifty of its own stores had two versions of every customer. I merged them into one warehouse and put a question box on top — one you can hand to a category manager without worrying about what it will say.

2.35 million

unified customer profiles, 2.7 GB in one table

153 / 153

accuracy checks passing on the verified question set

Zero

database queries the AI can write for itself

14 tools

pre-approved data functions the analyst may call

ORVELA

Customer Atlas

Unified customer intelligence

2.35M profiles

Which cities grew repeat revenue fastest this quarter?

Repeat revenue grew fastest in Bengaluru, up 22.4% to ₹4.82 Cr from 18,402 repeat customers. Pune follows at +18.7%. Hyderabad is the only city in the top six to contract, down 3.2%, driven by a fall in second-purchase rate rather than acquisition.

✓ Grounded — every figure traced to a row4 tools calledmatched verified question #37

Evidence — rows returned

CityRepeat customersRepeat revenuevs prior
Bengaluru18,402₹4.82 Cr+22.4%
Delhi16,918₹4.31 Cr+9.1%
Pune11,244₹2.96 Cr+18.7%
Hyderabad9,870₹2.44 Cr−3.2%
Lucknow7,455₹1.71 Cr+14.9%
Kochi6,102₹1.38 Cr+6.6%
Why did Hyderabad fall?Same cut by categoryWhich stores drove Bengaluru?

How this answer was built

  1. 1

    Understand

    Matched a verified question

  2. 2

    Scope

    All stores — no restriction

  3. 3

    Fetch

    4 of 14 approved tools

  4. 4

    Ground

    7 of 7 figures traced

  5. 5

    Leak check

    Passed

Model-written database queries: 0. The capability does not exist in this system.

Swipe to see the full screen

A question in plain English, answered with the figures and the rows they came from — plus a grounding verdict that has to pass before the answer is shown.

The situation

The retailer had two customer bases that did not know about each other: an online storefront, and more than fifty physical stores. The same person could buy online in March and in a store in July and appear as two unrelated customers. Every question that mattered — is our online customer also a store customer, which stores actually acquire new people rather than recycling existing ones, what happened to last year’s best customers — required somebody to pull two extracts and reconcile them by hand. So those questions mostly went unasked.

The second problem was the shape of the questions. They arrive in English, from people who will not build a pivot table, and they change every week. A fixed dashboard answers the questions you anticipated. It cannot answer the one someone asks in a meeting.

What I built

One warehouse that resolves customer identity across both channels and rebuilds three summary tables every night, then a dashboard and an AI analyst that both read from the same definitions.

  • A customer-360 table at one row per customer — 2.35 million rows, 2.7 GB — over a 2.45-million-row identity master and a 5.93-million-row order-line view.
  • Monthly rollups at customer level (3.49M rows) and store-customer level (487K rows), refreshed nightly, cached so the same question asked twice does not cost twice.
  • A dashboard covering acquisition, retention, cohort behaviour, store-level customer performance and period comparison.
  • An AI analyst that takes a question in ordinary English and returns a written answer with the figures and the supporting table.
  • A semantic layer: one shared definition of every metric and filter, read by both the dashboard and the analyst, so the two can never disagree about what “returning customer” means.
  • A contribution engine that, given two periods, computes which stores, categories and segments actually drove the change between them — with explicit handling of the difference between gross and net movement.
  • An accuracy harness that gates deployment: if the verified question set stops passing, the build does not ship.
ORVELA

Customer Atlas

Unified customer intelligence

2.35M profiles

Customers

23.5 L

4.1%

Repeat rate

31.4%

1.8%

AOV

₹2,180

3.2%

Repeat AOV

₹2,940

5.1%

90-day retention

18.6%

0.7%

New vs repeat revenue

Rolling 9 months

Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
NewRepeat

Channel of first purchase

  • In store58.0%
  • Online — D2C26.0%
  • Online — marketplace16.0%

Customers by city

Bengaluru
1,84,020
Delhi
1,69,180
Pune
1,12,440
Hyderabad
98,700
Lucknow
74,550
Kochi
61,020

Recency bands

Active (0–90d)
7,24,000
Low active (91–180d)
5,12,000
Dormant (181–365d)
6,18,000
Deep dormant (365d+)
4,96,000

Swipe to see the full screen

One customer view across both channels, over 2.35 million profiles.
ORVELA

Customer Atlas

Unified customer intelligence

Cohorts

Retention by acquisition month

Share of each cohort still buying, by months since first purchase

CohortM0M1M2M3M4M5M6
Oct-25
100%
36%
26%
14%
16%
14%
6%
Nov-25
100%
35%
25%
18%
12%
12%
Dec-25
100%
34%
21%
15%
17%
Jan-26
100%
37%
23%
22%
Feb-26
100%
35%
23%
Mar-26
100%
36%
Apr-26
100%

Swipe to see the full screen

Retention by acquisition month — which cohorts came back, and when they stopped.
ORVELA

Customer Atlas

Unified customer intelligence

Segments

High value

84,200

₹18.4 Cr

drill through →

At risk

1,12,400

₹9.1 Cr

drill through →

Win back

1,68,900

₹6.8 Cr

drill through →

One and done

4,21,000

₹8.9 Cr

drill through →

Dormant

4,96,000

₹4.2 Cr

drill through →

At risk

Same query that produced the count above produces this list

CustomerCityOrdersLast orderLifetime valueSegment
Ananya R.Bengaluru412 Feb 26₹18,400At risk
Vikram S.Delhi528 Jan 26₹22,600At risk
Meera T.Pune604 Feb 26₹26,800At risk
Rohit K.Kochi719 Jan 26₹31,000At risk
Priya N.Jaipur831 Jan 26₹35,200At risk
Arjun D.Mumbai909 Feb 26₹39,400At risk

Swipe to see the full screen

High-value, at-risk, win-back and dormant segments, each counted with the same query that produces its drill-through list.

Decisions worth explaining

The choice, why it was made, and what it means for you. Skip the middle part if you like — the point still lands.

01

The model never writes a database query

The choice

The analyst is given fourteen specific, pre-built, tested data functions and can call those and nothing else — at most fourteen times, at most three levels deep. There is no facility anywhere in the system for executing a model-written query.

Why

The obvious way to build an AI analyst is to let the model write SQL. It is also the way that produces a system nobody can trust, because the failure modes are unbounded: a wrong join, a wrong date window, a query that runs for nine minutes, or a perfectly valid query that answers a subtly different question than the one asked.

What it means for you

A dangerous query is not caught and blocked — it cannot be composed in the first place. Injection is unreachable rather than defended against.

02

Verified questions instead of similarity search

The choice

Incoming questions are matched against 85 questions written and checked by hand, using word stemming, a synonym map, and a scoring gate with required and bonus terms. There is no vector database and no embedding search anywhere in the system.

Why

Nearest-neighbour retrieval always returns something. When a question is unlike anything it has seen, it returns its most confident wrong answer, and nothing about that is visible to the person who asked. Exact rules can fail loudly instead.

What it means for you

When the system recognises your question you are getting an answer a human has already verified. When it does not, it says so and works the question out with tools — where every number still has to survive the grounding check. The cost is that the question bank is maintained by hand. That is the trade, made deliberately.

03

Four grounding layers, each catching a different failure

The choice

Malformed tool arguments are repaired rather than silently mishandled. A filter that is not on the approved list of 78 names is a hard error, not a best-effort guess. Every number in the written answer is extracted and checked against the data actually fetched. And where a user is restricted to certain stores, any tool that cannot honour that restriction is removed from the model’s options entirely, with the finished answer re-checked before it is shown.

Why

These are four genuinely different ways to be wrong, and a single safeguard catches only one of them. The dangerous one is the third: fluent prose with a plausible figure that appears nowhere in your data.

What it means for you

If a figure is not in the fetched results, the whole answer is discarded and replaced by one assembled directly from the data — an answer that is structurally incapable of containing an invented number. On a detected scope leak, the response is refused rather than trimmed.

04

An accuracy harness that has to pass before release

The choice

A suite re-asks a fixed set of questions and checks three things: was the right date window used, is every number traceable to fetched data, and does the result agree with the dashboard’s own endpoint for the same metric.

Why

An answer is only worth trusting if it has been tested.

What it means for you

The current golden set passes 153 of 153 across six suites. Alongside it, 52 data checks guard the warehouse itself — including the one most pipelines skip: an assertion that a closed month’s numbers are still the same after tonight’s refresh.

For the technical readerUnder the hood
  • Orchestration is a state machine: understand → plan → execute → synthesize, with the execute stage allowed up to three rounds so the analyst can look at a result and decide it needs one more fact before answering.
  • Budget caps at fourteen tool calls and depth three bound both cost and latency. A model rotation chain fails over on rate limits rather than erroring to the user.
  • FastAPI backend, PostgreSQL warehouse, Redis plus a database-backed result cache, Next.js and React front end with Recharts.
  • To be precise about what this system is not: there is no vector database, no embedding model and no similarity search in it. The retrieval is deterministic and verified, and that was the choice rather than a limitation.

What it changed

  • Online and in-store customers became one customer.
  • Questions that previously required a two-day manual extract are answered in the meeting where they are asked — with figures carrying the same definitions as the dashboard, because both read the same semantic layer.
  • The accuracy harness means that is a tested property, not a hope.

Where this applies to you

If you sell through both your own stores and a website, you already have this problem and probably do not have a number for its size. The same build works anywhere two systems describe the same customer differently: online and offline, across two brands, or either side of a POS migration.

Screenshots show the real interface with sample figures. Row counts are production table sizes. The 153-of-153 figure is the documented pass rate across six golden-set suites in the project’s own accuracy harness.

Tell me what’s slow, manual, or unreliable.

Twenty minutes on a call is usually enough for me to tell you whether software is the answer and roughly what it would cost. If it isn’t, I’ll say so.

Available for freelance builds alongside senior engineering work. One or two projects at a time.