The Luxury Retail CRM Data Model: Engineering Client Relationships at High-Value Scale

Luxury retail operates on relationship capital. A client who has spent $50,000 at a single boutique expects to be remembered — not just by name, but in terms of their style preferences, their family milestones, their advisor relationships, and the history of every interaction they have had with the brand. Building software that supports this level of relationship management requires a data model that is meaningfully different from a standard e-commerce database.

This post walks through the data model we developed for luxury retail CRM systems, the relationship structures that matter, and the engineering decisions that make the difference between a system that advisors actually use and one that gets abandoned after three months.

Why luxury retail CRM is different

Standard CRM systems (Salesforce, HubSpot) model the world in terms of contacts, accounts, opportunities, and activities. This works for B2B sales. It does not work for luxury retail, where the meaningful entities are:

• Clients — not just contacts, but people with relationship context: family connections, lifestyle signals, event participation, and a long history with the brand that advisors carry in their heads but which the system must also know
• Households — many luxury purchases are made by one member of a household but relevant to the household as a whole. A watch purchased as a gift, a piece of jewelry bought by a husband for a wife — the relationship context spans the household, not just the individual buyer
• Advisors — client advisor relationships are the core of the luxury retail model. An advisor's book of business is their livelihood, and the system must support advisor-client attribution, advisor performance, and the handoff when an advisor leaves
• Products — in luxury, products have provenance. A Hermès bag has a specific leather, hardware finish, year, and production provenance that matters for resale, authentication, and client service. The product data model must carry this context
• Service events — repairs, alterations, cleanings, authentication, and other post-sale service interactions are relationship-building touchpoints that standard e-commerce systems do not model at all

The core data model

Clients and households

CREATE TABLE households (
  id              CHAR(36) PRIMARY KEY,
  display_name    VARCHAR(255),          -- "The Chen Family", "Dr. & Mrs. Rodriguez"
  tier            ENUM('prospect','client','vip','ultra-vip') DEFAULT 'prospect',
  primary_advisor_id CHAR(36),           -- advisor who owns the relationship
  annual_spend    DECIMAL(12,2),         -- rolling 12-month spend
  lifetime_spend  DECIMAL(12,2),
  created_at      DATETIME(3) NOT NULL,
  updated_at      DATETIME(3) NOT NULL
);

CREATE TABLE clients (
  id              CHAR(36) PRIMARY KEY,
  household_id    CHAR(36) REFERENCES households(id),
  first_name      VARCHAR(100) NOT NULL,
  last_name       VARCHAR(100) NOT NULL,
  preferred_name  VARCHAR(100),          -- "Prefers to be called Alex"
  title           VARCHAR(50),           -- Mr., Mrs., Dr., etc.
  role_in_household ENUM('primary','spouse','partner','child','parent','other'),
  is_buyer        BOOLEAN DEFAULT TRUE,  -- makes purchasing decisions
  is_influencer   BOOLEAN DEFAULT FALSE, -- influences purchases but does not buy
  email           VARCHAR(255),
  phone           VARCHAR(50),
  birthday        DATE,                  -- for outreach without year (GDPR-conscious)
  anniversary     DATE,
  preferred_language VARCHAR(10),
  preferred_contact_method ENUM('email','phone','whatsapp','in-person'),
  created_at      DATETIME(3) NOT NULL
);

-- Style preferences stored as a flexible JSON document
CREATE TABLE client_preferences (
  client_id       CHAR(36) PRIMARY KEY REFERENCES clients(id),
  -- Stored as JSON to accommodate brand-specific preference taxonomy
  preferences     JSON,
  -- Example: {"categories": ["handbags","watches"], "colors": ["navy","camel"],
  --           "materials": ["calf leather"], "sizes": {"ring": "6.5", "belt": "32"}}
  updated_at      DATETIME(3) NOT NULL,
  updated_by      CHAR(36)  -- advisor ID who last updated
);

Advisor-client relationships

The advisor-client relationship is not a simple foreign key. It has history, it has multiple advisors serving the same client, and it changes over time when advisors leave or clients change their primary advisor.

CREATE TABLE advisor_client_relationships (
  id              CHAR(36) PRIMARY KEY,
  advisor_id      CHAR(36) NOT NULL,
  client_id       CHAR(36) NOT NULL REFERENCES clients(id),
  relationship_type ENUM('primary','secondary','temporary-cover') NOT NULL,
  started_at      DATETIME(3) NOT NULL,
  ended_at        DATETIME(3),           -- NULL if current
  transferred_from_advisor_id CHAR(36),  -- when a client is transferred
  transfer_reason VARCHAR(500),
  UNIQUE INDEX idx_active_primary (client_id, relationship_type, ended_at)
               -- enforces one active primary advisor per client
);

Interaction history

Every meaningful interaction with a client — a visit, a phone call, a WhatsApp message, a special order, a service drop-off — is an interaction record. Advisors log these to build the relationship history that allows any advisor covering a client to understand the relationship context.

CREATE TABLE client_interactions (
  id              CHAR(36) PRIMARY KEY,
  client_id       CHAR(36) NOT NULL REFERENCES clients(id),
  advisor_id      CHAR(36) NOT NULL,
  channel         ENUM('in-store','phone','email','whatsapp','video','event','other'),
  interaction_type ENUM('visit','outreach','service-drop-off','service-pickup',
                        'special-order','event-attendance','complaint','other'),
  occurred_at     DATETIME(3) NOT NULL,
  duration_minutes INT,
  notes           TEXT,                  -- advisor's notes on the interaction
  outcome         VARCHAR(500),          -- what happened / what was agreed
  follow_up_date  DATE,                  -- if a follow-up was agreed
  follow_up_done  BOOLEAN DEFAULT FALSE,
  created_at      DATETIME(3) NOT NULL,
  INDEX idx_client_time (client_id, occurred_at)
);

Products with provenance

CREATE TABLE luxury_products (
  id              CHAR(36) PRIMARY KEY,
  brand           VARCHAR(100) NOT NULL,
  category        VARCHAR(100) NOT NULL,  -- 'handbag', 'watch', 'jewelry', 'rtw'
  model_name      VARCHAR(255) NOT NULL,
  sku             VARCHAR(100) UNIQUE,
  color_description VARCHAR(255),         -- "Etoupe with Gold Hardware"
  material_description VARCHAR(500),      -- "Togo Calf Leather"
  year_of_production INT,
  serial_number   VARCHAR(100),           -- for watches and serial-numbered pieces
  provenance_notes TEXT,                  -- auction history, prior owners, certificates
  retail_price    DECIMAL(12,2),
  current_retail  DECIMAL(12,2),
  authentication_status ENUM('unauthenticated','authenticated','certified'),
  authentication_date DATE,
  authentication_by VARCHAR(255)
);

Purchase history with gift context

CREATE TABLE purchases (
  id              CHAR(36) PRIMARY KEY,
  buyer_client_id CHAR(36) NOT NULL REFERENCES clients(id),
  recipient_client_id CHAR(36) REFERENCES clients(id),  -- NULL if self-purchase
  is_gift         BOOLEAN DEFAULT FALSE,
  gift_occasion   VARCHAR(100),           -- 'birthday', 'anniversary', 'christmas', etc.
  product_id      CHAR(36) NOT NULL REFERENCES luxury_products(id),
  quantity        INT NOT NULL DEFAULT 1,
  unit_price      DECIMAL(12,2) NOT NULL,
  total_price     DECIMAL(12,2) NOT NULL,
  discount        DECIMAL(12,2) DEFAULT 0,
  advisor_id      CHAR(36) NOT NULL,      -- advisor who made the sale
  boutique_id     CHAR(36) NOT NULL,
  transaction_date DATETIME(3) NOT NULL,
  notes           TEXT,                   -- client's stated purpose, occasion context
  INDEX idx_buyer_date (buyer_client_id, transaction_date)
);

Service events

CREATE TABLE service_events (
  id              CHAR(36) PRIMARY KEY,
  client_id       CHAR(36) NOT NULL REFERENCES clients(id),
  product_id      CHAR(36) REFERENCES luxury_products(id),
  service_type    ENUM('repair','cleaning','alteration','authentication',
                       'spa-treatment','restoration','appraisal'),
  intake_date     DATETIME(3) NOT NULL,
  intake_advisor_id CHAR(36),
  intake_notes    TEXT,
  estimated_completion DATE,
  completion_date DATETIME(3),
  return_advisor_id CHAR(36),
  quote_amount    DECIMAL(12,2),
  final_amount    DECIMAL(12,2),
  status          ENUM('intake','in-service','ready','returned','cancelled'),
  client_notified_at DATETIME(3),
  INDEX idx_client_service (client_id, intake_date)
);

The engagement scoring model

In luxury retail, an "at-risk" client is one whose engagement is declining, not just one who has not purchased recently. A client who visits frequently but has not purchased in six months may be more engaged than one who purchases annually from a catalogue without visiting.

The engagement score we built:

-- Engagement score components (updated nightly)
SELECT
  c.id as client_id,
  -- Purchase recency (0-30 points)
  CASE
    WHEN MAX(p.transaction_date) >= DATE_SUB(NOW(), INTERVAL 90 DAY) THEN 30
    WHEN MAX(p.transaction_date) >= DATE_SUB(NOW(), INTERVAL 180 DAY) THEN 20
    WHEN MAX(p.transaction_date) >= DATE_SUB(NOW(), INTERVAL 365 DAY) THEN 10
    ELSE 0
  END as purchase_recency_score,

  -- Interaction frequency (0-30 points)
  LEAST(30, COUNT(CASE WHEN i.occurred_at >= DATE_SUB(NOW(), INTERVAL 90 DAY) THEN 1 END) * 6) as interaction_score,

  -- Service engagement (0-20 points)
  LEAST(20, COUNT(CASE WHEN se.intake_date >= DATE_SUB(NOW(), INTERVAL 365 DAY) THEN 1 END) * 10) as service_score,

  -- Event attendance (0-20 points)
  LEAST(20, COUNT(CASE WHEN i.interaction_type = 'event-attendance' AND i.occurred_at >= DATE_SUB(NOW(), INTERVAL 365 DAY) THEN 1 END) * 10) as event_score

FROM clients c
LEFT JOIN purchases p ON c.id = p.buyer_client_id
LEFT JOIN client_interactions i ON c.id = i.client_id
LEFT JOIN service_events se ON c.id = se.client_id
GROUP BY c.id

The engagement score drives advisor outreach prioritization: each morning, advisors see their clients sorted by engagement score, with the most at-risk clients highlighted for proactive outreach.

Advisor performance attribution

In luxury retail, commission and performance attribution are complex because clients often interact with multiple advisors and purchases may involve advisor introductions separate from the final sale. The system must track:

• Which advisor is credited for the sale (typically the primary advisor or the advisor who assisted the client at point of sale)
• Which advisor introduced the client to the brand (referral credit)
• Client retention by advisor book — when a client reduces spending, is it the advisor's relationship quality or the brand's issue?

These attribution rules are implemented in the reporting layer rather than hard-coded in the transaction data, which allows the boutique to adjust attribution rules without modifying purchase records.

What makes advisors actually use the system

Every luxury retail CRM project we have worked on faces the same adoption challenge: advisors resist logging interactions because they see it as administrative overhead that competes with time they could spend with clients. The systems that get used share three characteristics:

Mobile-first logging: Advisors need to log interactions from their phone, immediately after the interaction, in under 60 seconds. If logging requires opening a laptop, it does not get done. We build a mobile app with voice-to-text note entry and a one-tap "interaction type" selector as the primary logging interface.

System gives advisors value: The system must give advisors something useful back. Anniversary and birthday reminders, replenishment predictions for consumable products, upcoming event invitations filtered to the client's stated interests — these make advisors want to log interactions because they see the return.

The data follows the client, not the advisor: Advisors are more willing to maintain data quality when they know that if they leave, they take their client relationship knowledge with them — not the system. We build advisor export functionality that lets advisors take their interaction notes with them, which paradoxically increases data entry quality because advisors treat the system as their own record rather than the company's.

If you are building or evaluating CRM software for a luxury retail operation and want to understand whether a custom build is the right approach for your specific situation, this is work we have done before and can help you scope correctly.