One customer graph instead of five disconnected systems.

The complete customer picture is scattered across systems.

Churn analysis, recommendations, and journey mapping all need the same thing: a customer connected to their orders, subscriptions, support history, and behavioral events. When those live in separate systems — a CRM, a billing platform, a helpdesk, an events pipeline — every new analysis starts over as its own reconciliation project instead of reusing a shared connected model.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A CUSTOMER record with nested SUBSCRIPTION, ORDER, and SUPPORT_TICKET arrays lands as one connected write, not four table inserts to reconcile later. RushDB infers plan, status, and sentiment types on arrival, links each nested array to the parent customer automatically, and can surface relationship patterns across EVENT streams imported from a separate analytics pipeline.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

{
  "customerId": "cust-8821",
  "plan": "pro",
  "SUBSCRIPTION": [{ "status": "active", "renewsAt": "2026-08-01" }],
  "ORDER": [{ "orderId": "ord-501", "totalUsd": 240 }],
  "SUPPORT_TICKET": [{ "status": "open", "sentiment": "negative" }]
}

Working example

Query the full customer picture in one call.

Once orders, subscriptions, tickets, and events are connected to the customer, a churn-risk query traverses all of them together.

CUSTOMER cust-8821
  plan: "pro"
  SUBSCRIPTION: [{ status: "active", renewsAt: "2026-08-01" }]
  ORDER: [{ orderId: "ord-501", totalUsd: 240 }]
  SUPPORT_TICKET: [{ status: "open", sentiment: "negative" }]

{
  "labels": ["CUSTOMER"],
  "where": {
    "plan": "pro",
    "SUBSCRIPTION": { "status": "active" },
    "SUPPORT_TICKET": { "status": "open", "sentiment": "negative" }
  }
}

{
  "customerId": "cust-8821",
  "plan": "pro",
  "riskSignal": "open negative-sentiment ticket on an active pro subscription"
}

TypeScript SDK

Query churn risk across the connected customer graph.

The same connected graph also answers recommendation and journey-mapping queries — one backend, not one query per source system.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({'labels': ['CUSTOMER', 'ORDER', 'SUBSCRIPTION', 'SUPPORT_TICKET']}).data

at_risk = db.records.find({
    'labels': ['CUSTOMER'],
    'where': {
        'plan': 'pro',
        'SUBSCRIPTION': {'status': 'active'},
        'SUPPORT_TICKET': {'status': 'open', 'sentiment': 'negative'},
    },
})

Implementation blueprint

Build the customer 360 graph.

Use this sequence to connect customer data from multiple systems into one queryable graph.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.