6.0 Inventory

Watch what sells
branch by branch

SKU-level analytics tied to identified buyers via the wallet ID. Per-branch velocity, reorder signals, dead stock. Joined to actual humans, not anonymous transactions.

SKU model

Every product joined to identified buyers

Every till swipe writes a SKU-level event with the buyer's wallet ID attached. SKU + customer + branch + campaign = one row, not a four-system join.

SKUiced_latte_M
Customerw_247
BranchOlaya
AmountSAR 18

SKU + wallet_id link

Every till.debit event carries sku_id + wallet_id. The join is one event, not an after-the-fact reconciliation.

Olaya · stock84
Tahlia · stock62
Diriyah · stock41

Per-branch price + stock

Each SKU has per-branch price + on-hand quantity. Updated real-time.

Hot drinksSAR 47K
Cold drinksSAR 38K
PastrySAR 21K

Category rollups

Operator-defined category tree. Velocity aggregates at each level.

Composition

The SKU + wallet join unlocks the network

Tied to wallet for buyer identity, to attribution for campaign performance, to customers for personalisation, to brain for plain-language queries.

Maryam K. · top SKUiced_latte_M
14 visits14× iced_latte
Personalisationiced_latte boost

Per-customer history

Which SKUs each customer buys most. Drives personalised incentives + recommendations.

Campaignboost_dormant_14d
SKUs sold347 units
Top SKUiced_latte_L

Campaign → SKU loop

See which SKUs moved when a campaign ran. Close the spend-to-SKU loop directly.

Velocity

Per-SKU per-branch in real time

Designed for the merchandiser who needs to know 'is my new latte selling at Olaya specifically' without exporting CSVs. Sort by sell-through, revenue, or margin.

Reorder

Signals that fire before the shelf is empty

Operator-defined thresholds + velocity floors. When stock crosses the threshold AND the SKU is moving, a reorder signal fires to dashboard, Slack, or auto-PO.

Stock threshold≤ 40
Velocity floor≥ 10/day
Fired today12 SKUs

Threshold + velocity AND

Reorder only when stock low AND SKU moving. Avoids reordering dead stock.

dashboard slack auto-PO approval

Signal channels

Dashboard alert, Slack ping, auto-PO. Operator picks per-SKU per-branch.

SKUiced_latte_M
BranchOlaya
Statusauto-PO sent

Audit log

Every reorder signal logged with cause, action, operator approval.

"We finally know which 3 SKUs drive 80% of our LTV. Brain answered it in twelve seconds."

CEO · GCC coffee chain

"Reorder signals catch dead stock the day it goes dead. We stopped writing off pastry."

Head of supply · GCC F&B chain

Built for the future. Available today.

Talk to us Read the docs
Tech specs
6.1

SKU model

Every product is a SKU record with per-branch availability, per-branch price, and per-branch sell-through. Each till swipe writes a SKU-level event with the identified buyer's wallet ID attached.

This is the join that makes inventory tie to customers: "who bought what, where, when, on what campaign" is one query, not a four-system join.

SKU properties

Property Function
sku_id

Stable product identifier. Generated from operator catalog import.

name

Display name. Operator-managed; multilingual (EN + AR) supported.

category

Operator-defined category tree. Drives velocity rollups.

price_per_branch

Per-branch retail price. Drives revenue attribution.

cost_per_branch

Per-branch wholesale cost. Drives margin views.

stock_per_branch

Real-time on-hand quantity. Updated on till.debit + restock events.
Tech specs
6.2

Composition

Inventory composes with wallet (every till swipe carries the buyer's wallet ID), with attribution (per-SKU per-campaign), with customers (per-customer SKU velocity), and with brain (operator can ask "which 3 SKUs drive 80% of my LTV").

The composition is what gives Feddi inventory its edge over standalone POS analytics: SKU data is tied to identified humans, not anonymous transactions.

Composition points

Property Function
Wallet → Inventory

Every till.debit event carries wallet_id + sku_id. The link is one event, not a join.

Attribution → Inventory

Per-SKU per-campaign attribution. "Which SKUs moved when the boost ran?"

Customers → Inventory

Per-customer SKU history. Drives personalised recommendations.

Brain → Inventory

Plain-language queries on SKU + customer + attribution joins.
Tech specs
6.3

Velocity dashboard

Per-SKU per-branch velocity in real time. Filter by category, time window, customer segment, or campaign. Sort by sell-through rate, revenue, or margin.

Designed for the merchandiser who needs to know "is my new latte selling at Olaya specifically?" without exporting CSVs.

Velocity surfaces

Property Function
Per-SKU velocity

Units sold per day, per branch, per time window. Trend lines + sparklines.

Top movers

Most-sold SKUs in a window. By units, revenue, or margin.

Dead stock

SKUs with zero sell-through in N days. Flagged for clearance.

Per-customer velocity

Which SKUs each customer buys most. Drives recommendation rules.

Category rollup

Aggregate velocity by operator-defined category tree.

Campaign velocity

SKUs sold under a campaign tag. Closes the campaign loop.
Tech specs
6.4

Reorder signals

When a branch's stock crosses an operator-defined threshold AND the branch's velocity for that SKU is positive, the system fires a reorder signal. The signal can auto-create a purchase order, ping a Slack channel, or just surface in the dashboard.

Operator chooses per-SKU per-branch how aggressive the signal is. The signal trail is auditable end-to-end.

Reorder primitives

Property Function
Threshold

Stock level below which a reorder signal fires. Per-SKU per-branch.

Velocity floor

Minimum recent sell-through to qualify as "active." Avoids reordering dead stock.

Signal channel

Where the signal goes: dashboard alert, Slack ping, auto-PO, all of the above.

Approval flow

Per-operator-account: auto-approve below threshold, require approval above.

Reorder calendar

Day-of-week constraints. "Don't order on Fridays."

Audit log

Every reorder signal logged with cause, action, operator approval.