SUPPORT GROUPS REFERENCE
Customer Service Intelligence Support Groups
Customer Service Intelligence organizes detection into 6 support groups covering 200 indicators across 18 languages.
All Support Groups
Each support group contains a set of specific indicators that the API can detect. Click a group to expand its signal list. Signal lists are available to customers - sign in to view them.
01
Access Account
access_account
38
38 signals - request access
for the complete list.
View 38 indicators
Access Account
access_account
The complete signal list is available to customers. Request access to view it.
02
Billing Retention
billing_retention
25
25 signals - request access
for the complete list.
View 25 indicators
Billing Retention
billing_retention
The complete signal list is available to customers. Request access to view it.
03
Product Tech
product_tech
51
51 signals - request access
for the complete list.
View 51 indicators
Product Tech
product_tech
The complete signal list is available to customers. Request access to view it.
04
Delivery Status
delivery_status
24
24 signals - request access
for the complete list.
View 24 indicators
Delivery Status
delivery_status
The complete signal list is available to customers. Request access to view it.
05
Escalation Urgency
escalation_urgency
37
37 signals - request access
for the complete list.
View 37 indicators
Escalation Urgency
escalation_urgency
The complete signal list is available to customers. Request access to view it.
06
Security Feedback
security_feedback
25
25 signals - request access
for the complete list.
View 25 indicators
Security Feedback
security_feedback
The complete signal list 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 withinput_too_long, never truncated.language- must be a language this analyzer supports. Unsupported codes are rejected with400 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.”
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.
Access the taxonomy through the API
Check Customer Service Intelligence availability and endpoint programmatically via the public catalog endpoint - no authentication required. Include your API key to also retrieve taxonomy size and supported languages.
curl -X GET https://sentiqra.tech/v1/meta/domains/customer-service \
-H "Authorization: Bearer sq_live_your_key_here"Example response (authenticated):
{
"catalog_version": "...",
"domain": {
"id": "customer_service",
"name": "Customer Service Intelligence",
"status": "production",
"taxonomy": { "groups": 6, "detection_labels": 200 },
"languages": [ ... ]
}
}Signals returned by the analyzers use code for the category or label slug - these correspond to the categories and indicators documented on this page.