Support context that survives every handoff.

Support context resets on every new ticket.

Customers move across email, chat, and calls, and their history lands in separate tools each time. Without a connected record, ticket history stays split across channels, resolutions for similar issues are hard to find, account and plan context is missing when a ticket opens, and keyword search misses a problem described in different words than last time — so agents re-ask questions and miss fixes that already worked.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A ticket lands as a TICKET record nested under its CUSTOMER, carrying channel and status, with MESSAGE and RESOLUTION records nested inside it, like the CSV export fix on ticket tkt-512. RushDB types those fields on write, auto-links MESSAGE and RESOLUTION records to their parent TICKET and CUSTOMER, and keeps message body text searchable so a differently worded export complaint still matches the resolution that already worked.

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-88",
  "plan": "pro",
  "TICKET": [{
    "ticketId": "tkt-512",
    "channel": "email",
    "status": "resolved",
    "MESSAGE": [{ "role": "customer", "body": "Export to CSV fails on large datasets." }],
    "RESOLUTION": [{ "summary": "Raised export row limit; advised chunked export." }]
  }]
}

Working example

Resolve once. Recall the fix for the next similar ticket.

A resolved ticket stores its messages and resolution linked to the customer. A later ticket recalls similar past issues by meaning, scoped to the same customer.

CUSTOMER cust-88  plan: pro
  TICKET tkt-512  channel: email  status: resolved
    MESSAGE "Export to CSV fails on large datasets."
    RESOLUTION "Raised export row limit; advised chunked export."

{
  "labels": ["MESSAGE"],
  "propertyName": "body",
  "query": "CSV export failing for big exports",
  "where": { "CUSTOMER": { "customerId": "cust-88" } }
}

{
  "ticket": "tkt-512",
  "match": "Export to CSV fails on large datasets.",
  "resolution": "Raised export row limit; advised chunked export."
}

Python SDK

Persist the ticket trail. Recall the resolution that worked.

RushDB keeps customers, tickets, messages, and resolutions connected and keeps message text searchable. Your support workflow and model decide how to use the recalled history.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

db.ai.indexes.create({'label': 'MESSAGE', 'propertyName': 'body'})

db.records.import_json({
    'label': 'CUSTOMER',
    'data': {
        'customerId': 'cust-88',
        'plan': 'pro',
        'TICKET': [{
            'ticketId': 'tkt-512',
            'channel': 'email',
            'status': 'resolved',
            'MESSAGE': [{'role': 'customer', 'body': 'Export to CSV fails on large datasets.'}],
            'RESOLUTION': [{'summary': 'Raised export row limit; advised chunked export.'}],
        }],
    },
})

similar = db.ai.search({
    'labels': ['MESSAGE'],
    'propertyName': 'body',
    'query': 'CSV export failing for big exports',
    'where': {'CUSTOMER': {'customerId': 'cust-88'}},
    'limit': 10,
})

Implementation blueprint

Build the customer support memory path.

Use this sequence to connect ticket history across channels and retrieve similar past issues with their resolutions.

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.