Marketplace e-commerce · Sales analytics

Profit per SKU across three marketplaces, checked against manual figures

Five seller accounts on WB, Ozon and Yandex Market merged into one SKU-level P&L. Variance from the client’s manual figures on a control SKU for one month: 0.00%.

Status
In production
Timeline
about 2.5 months, two phases
Stack
  • Python / FastAPI
  • ClickHouse + PostgreSQL
  • LightGBM / XGBoost / scikit-learn
  • Wildberries, Ozon and Yandex Market APIs
  • OpenAI API (function calling)
  • Docker / Traefik / GitHub Actions

The task

A home-goods manufacturer sells through five seller accounts on three marketplaces and had no reliable profit per SKU. Statements differ by platform, some operations settle in another month, and ad spend and account fees never reached products. Excel reconciliation took days and still drifted. They needed one source of truth for profit, a demand forecast for purchasing, and a check on marketplace overcharges.

What we built

Outcome

0.00%
variance vs the client’s manual benchmark across units, revenue, COGS, profit and margin for a control SKU over a month; the threshold was 1%
1.18M rows
of sales across 5 accounts and 12 months processed; 10.7% were ordered and settled in different months
~7.5% of spend
in one account’s monthly statement never reached the SKU report (no SKU attached). We found it and included it in total spend; reconciled down to one control line

Services

More cases

IT consulting · Lead qualification

In-house product

A pilot plan for the visitor, a qualified lead for sales

We replaced the contact form with an AI consultant: it interviews the visitor, returns a pilot plan with KPIs and risks, and sales gets a lead with budget and timeline.

1 day
to build a working MVP: frontend, backend and deploy configs
16 days
from first commit to production with HTTPS and an issued certificate on its own domain

Aviation · aircraft components trading and MRO

Pilot

Aircraft parts procurement: from email to a managed pipeline

An AI agent reads incoming RFQs, compares supplier quotes and checks trace documents. A separate deal-tracking system moves each deal through mandatory stages.

Full loop
the AI loop ran end to end on a live procurement process, from an incoming RFQ to a team notification. This was a pilot and the figures are our own so far: the client has not confirmed them yet
3
types of trace documents checked by the agent: FAA 8130-3, EASA Form 1 and COC. Like the figure above, it still awaits the client’s confirmation

Distribution · Partner networks

In production

A sales and support platform for a distributed partner network

Partners ask who on their team is inactive and what blocks the next level, and get numbers for their own part of the network only. Access is enforced at the SQL level.

Their own slice
a partner gets figures for their own team only: a filter on the current user is added to every SQL query
6 layers
of data protection between the language model and the database, from blocked personal-data columns in SQL to rate limits; counted in the code

Estimate the payback of a similar process

AVA lets you work out the economics of your process on your own figures, with no form and no price from us. It shows what the manual work costs, what cash effect automation would give and what budget would pay back. If the effect does not even cover running costs, it says so.

Estimate the payback

Discuss a similar problem

Describe the process and the data you have. Before any work starts we will tell you what can be measured in money, what cannot, and whether it is worth doing.

In the reply we will say what we understood, what we need to clarify and whether it is worth doing.

or email us directly: hello@xteam.pro

New write-ups on Telegram