Customer Support Schema

The Customer Support Schema is for support chatbots, agent-assist copilots, CRM AI, and helpdesk platforms. The SDK stays the same. Enable domain_schema: "support" and MemoryOS adds a structured support overlay to every add() and get() call.

What it stores

Field	Meaning
`support_type`	Active support vertical for this customer
`customer_identity`	Account hints, tier, name, verified status
`communication_preference`	Channel, tone, detail level, technical comfort
`language_profile`	Preferred language and regional style
`current_open_issue`	The issue future replies should start from
`issue_history`	Useful prior issues without dumping every ticket
`resolution_preference`	Refund, replacement, callback, workaround, escalation, or self-serve
`sentiment_pattern`	Frustration, repeat complaint, escalation risk, or easy-to-resolve
`risk_signals`	Fraud, churn, legal, compliance, VIP, or safety signals
`support_context`	Vertical-specific context: orders, invoices, bookings, plans, transactions

Support types

saas, ecommerce, banking_fintech, travel, telecom, edtech_support, general_info

Enable

From the workspace dashboard: Settings → Domain Schema → Customer Support Schema, or via API:

PATCH /v1/tenant/domain-schema
Authorization: ApiKey mem_...
Content-Type: application/json

{ "domain_schema": "support" }

Routing modes

Mode	Use when
`single`	One vertical — SaaS, ecommerce, banking, travel, telecom
`multi`	Helpdesk platform serving many verticals
`auto`	Early testing or broad demos

Single vertical:

{
  "support_type_mode": "single",
  "support_type": "banking_fintech",
  "support_types_allowed": []
}

Multi-vertical helpdesk:

{
  "support_type_mode": "multi",
  "support_type": null,
  "support_types_allowed": ["saas", "ecommerce", "banking_fintech", "travel", "telecom", "general_info"]
}

Classification happens inside the extraction pass — no separate detection call.

Retrieval safety rules

Support retrieval prepends guardrails to system_prompt_addition:

Support memory usage rules:
- Treat this as remembered customer context, not live system truth.
- Do not claim you checked, changed, refunded, cancelled, verified, located, or triggered anything
  unless your own tool/API result confirms it.
- If live system data is needed, say you need to check the relevant support system.

For banking_fintech:

- Never ask for or repeat OTPs, passwords, full account numbers, full card numbers,
  Aadhaar, or PAN values.

These add no extra LLM call — just a few deterministic prompt tokens.

MemoryOS vs. your support tools

Belongs in MemoryOS	Belongs in your systems
Customer prefers refunds over replacements	Current order status
Unresolved billing issue from last session	Current invoice status
Customer contacted support three times	Account owner verification
Escalation risk signals	Refund creation
Communication style preference	Ticket SLA timer

The recommended flow:

mem.get() — remembered support context
your tools — live truth (orders, invoices, tickets)
combine both in the model call
mem.add() — store the conversation

PII guidance

Prefer stable internal IDs for external_user_id. Keep ticket IDs in metadata. Never send raw card data, OTPs, passwords, Aadhaar, PAN, full account numbers, or full passport numbers to MemoryOS. PNR values for travel are fine — they’re operational references, not financial credentials.

Dashboard endpoints

Need	Endpoint
Customer support memory list	`GET /v1/tenant/customers`
Aggregate support stats	`GET /v1/tenant/support-stats`
Configure routing	`PATCH /v1/tenant/support-type`
Current domain config	`GET /v1/tenant/domain-schema`

Use SDK get() for model calls, not dashboard endpoints.

​What it stores

​Support types

​Enable

​Routing modes

​Retrieval safety rules

​MemoryOS vs. your support tools

​PII guidance

​Dashboard endpoints

​Related pages