G Gaia

Switch factory

CYTO-11 — Balakong Jaya CTSB CYTO-29 CTSB CYTOWELL-54 — Taming Jaya PIC/S CTWSB CYTOCNGZ-602 — Guangzhou CTCNGZ

Only factories you are granted appear here (Filament tenant menu).

Leo Lim

leo@navi.my · Owner / Admin

Profile settings Change password

Theme

Sign out
RetailSellR&DMakeBuyStockPlanItemsGMPAdminInsights
Sales CRM Shipments Customers Price lists Returns

Retail CRM — customer book

+ Sale
The book replaces staff memory, not a sales pipeline: retail CRM is a customer book — who buys what, at what price, on what rhythm. Follow-ups are derived from cadence, not a task list anyone maintains. OEM deals keep their pipeline in Sell → CRM; same people underneath when a customer is both.
Follow-ups today 2 due to reorder derived: now > last order + 1.5× cadence — nothing to tick off, it clears itself when they buy
5 retail customers in the book · it remembers prices and rhythm so staff don't have to
Customer Phone Usual products · last price Orders Cadence Last order Follow-up Notes
New sale — what staff see (price memory + floor enforcement in action — same variant_prices floor as OEM)

Customer: Kedai Pak Din

Double Root Coffee / 2024-02

auto-filled: last paid 6.50 · band 5.00–8.00 · floor 5.00

✓ within band — staff can confirm

Customer: Kedai Pak Din

Kopi Cik Abang / 2023-01

BELOW FLOOR 3.00

Line locked — approval request sent to owner. Staff cannot confirm this sale.

Project Gaia — static mockup in Filament v3 idiom. No backend. Retail module; customer data shared with OEM underneath (channel-flagged), screens separated. The Double Root RM 5–8 band is the founder's real example.

Retail CRM — field manifest

FieldFilament componentTypeSourceFK target
Customer bookTable over customersviewONE customers table shared with OEM, channel enum (oem / retail / both); this view scoped to channel ∈ {retail, both}. Sell > CRM shows the same people as a deal pipelinecustomers
Usual products · last priceTagsColumn, derivedderivedfrom retail sale-line history: most-frequent variants + last price paid per variant (price memory)retail_sale_lines
CadenceTextColumn, derivedintervalmedian days between this customer's sales — recomputed on every posted sale, never typed in—
Follow-upBadge, derivedflagDUE TO REORDER when now > last_order + 1.5× cadence. A derived flag, NOT a task table — no follow_ups table exists; the queue clears itself when the customer buys—
Call / WhatsAppTable actionsactiontel: link + wa.me link pre-filled with usual product and last price (concept — no message log stored)—
New sale price fieldTextInput + memory hintmoneyauto-fills last paid for customer+variant; floor from SHARED variant_prices — below floor locks the line and creates an owner approval request, identical to OEMvariant_prices

Engine notes

  • Shared-data doctrine: ONE customers table (channel enum oem / retail / both) and ONE variant_prices table — data shared, views scoped. What separates Retail from Sell: screens, numbering series (RS- vs SO-), CRM shape (book vs pipeline), e-invoicing path (consolidated vs per-order).
  • Cadence formula: cadence = median(days between consecutive sales); follow-up flag = now > last_order + 1.5 × cadence. Derived on read — deleting a sale re-derives everything.
  • The book is deliberately not a pipeline: no stages, no deal values. Small repeat buyers need "who's overdue and what do they pay", nothing more.