We are currently building something exciting and will be launching soon. Registration is temporarily closed. Launching soon — registration temporarily closed.

INDICATORS REFERENCE

Customer Service Intelligence Indicators

Customer Service Intelligence covers 200 indicators across 6 support groups. Each signal has a stable slug and code for programmatic access. Representative signals are shown publicly; the complete reference is available to customers.

200
Indicators
6
Support Groups
18
Languages
33
Avg / Group
6 results

Showing 6 representative indicators of 200. The complete taxonomy is available to customers.

Request access
# Indicator Slug code Support Group
001 login failure login_failure access_account.login_failure Access Account
002 duplicate charge duplicate_charge billing_retention.duplicate_charge Billing Retention
003 bug report bug_report product_tech.bug_report Product Tech
004 email not received email_not_received delivery_status.email_not_received Delivery Status
005 urgent request urgent_request escalation_urgency.urgent_request Escalation Urgency
006 security breach security_breach security_feedback.security_breach Security Feedback

Browse by Support Group

Alternatively, explore indicators grouped by their parent support group:

1

Access Account

access_account
38 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

2

Billing Retention

billing_retention
25 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

3

Product Tech

product_tech
51 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

4

Delivery Status

delivery_status
24 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

5

Escalation Urgency

escalation_urgency
37 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

6

Security Feedback

security_feedback
25 Indicators

The complete signal list for this support group is available to customers. Request access to view it.

Reading Customer Service Intelligence output

What you can safely infer from a result - and what you must not.

Intended task

Classify support text into routing signals - intent, urgency, escalation, churn risk - so the ticket reaches the right queue.

Input requirements

  • text - the only field analyzed; up to 4,096 Unicode code points. Over the limit is rejected with input_too_long, never truncated.
  • language - must be a language this analyzer supports. Unsupported codes are rejected with 400 unsupported_language, never analyzed as a different language.
  • analyzers - include "customer-service"; up to 2 analyzers per request, one billed run each.
  • No context beyond text - no user IDs, history, profiles, or attachments are read or inferred.
  • Analyzes the submitted message only - account state, order history, and past tickets are not inputs.

Ordinary positive

“I have been charged twice this month and your support line keeps dropping me. If this is not fixed today I am cancelling.”

billing_payments very high
retention_cancellation high
escalation high

Safe inference: The ticket matches billing intent plus escalation and churn-risk signals - enough to route it to a senior billing queue rather than general support.

Confusing negative · Insufficient context

“Quick question - how do I cancel a subscription?”

What happens: Retention/cancellation signals can fire even though the customer is asking a how-to question. Cancellation-related language is not the same as cancellation intent - the signal flags the topic so your router sends it to the right queue, not to confirm the customer is leaving.

Why it's tricky: Intent signals describe what the text is about. How-to questions, agent quotes, and forwarded complaints all mention the same topics - combine the signals with your own context before treating a churn label as churn risk.

What you can safely infer

  • Which routing categories the text matched - intent, urgency, escalation - and at what strength.
  • That the same ticket text on the same pinned configuration routes the same way every time.

What you must not infer

  • ✕That the customer will actually churn - a cancellation signal is a queueing hint, not a retention forecast.
  • ✕An SLA commitment or promised resolution - the analyzer reads text, it does not promise outcomes.
  • ✕That a ticket with no urgency signal can safely wait - priority is your policy decision.

Boundary: Routing signals describe the ticket's language - they are not verified customer state. A churn or escalation signal is a routing hint, not a prediction.

Using Indicators in API Responses

When you call /v1/analyze, the response includes matched indicators with signal-match scores. Each signal is identified by its code and includes a level field (“category” or “label”). A score expresses signal-match strength under a particular analyzer configuration. It is not a probability that the signal or a downstream action is correct. Validate action thresholds on representative labeled data.

{
    "language": "en",
    "language_source": "declared",
    "signals": [
        {
            "analyzer": "customer-service",
            "code": "support_intent",
            "label": "Support Intent",
            "score": 0.94,
            "level": "category"
        },
        {
            "analyzer": "customer-service",
            "code": "billing_issue",
            "label": "Billing Issue",
            "score": 0.92,
            "level": "label",
            "parent": "support_intent"
        },
        {
            "analyzer": "customer-service",
            "code": "access_issue",
            "label": "Access Issue",
            "score": 0.89,
            "level": "label",
            "parent": "support_intent"
        }
    ],
    "meta": {
        "analyzers": [
            {
                "name": "customer-service",
                "status": "completed",
                "applicability": "analyzable",
                "assessment": "signals_detected",
                "signal_count": 3,
                "billed": true
            }
        ]
    },
    "usage": {
        "analyzer_runs": 1
    },
    "verification": {
        "configuration": "sqcfg_E6A178YY",
        "fingerprint": "fp_8a72...19f",
        "input_commitment": "ic_31bd...a42",
        "signature": "sig_ed25519_4c1f...e2a",
        "key_id": "edk_af4f218e"
    }
}