Skip to main content

Customer Interaction and Routing: The Front Door to Our Platform

1. Introduction: Every Interaction Matters​

Every time a customer interacts with the XOPS platform—whether through an API call, the Control Center UI, or a support request—we have an opportunity to provide a world-class experience. This document outlines the lifecycle of a customer interaction, detailing how we intelligently route requests and proactively communicate with our users.

Our philosophy is to empower customers with self-service capabilities while providing a highly automated and intelligent safety net to catch issues before they become problems.

Core Mission: To ensure every customer interaction is routed efficiently, handled intelligently, and contributes to a seamless and proactive user experience.

2. The Customer Interaction Lifecycle​

A customer interaction is any contact a user has with our platform. We categorize these interactions to handle them appropriately.

This guide focuses on the intelligent routing and proactive notifications that underpin all of these channels.

3. Intelligent Routing via the Autonomous Engine​

Not all requests are created equal. When a request requires more than a simple, synchronous response, our Autonomous Engine takes over. It uses the Knowledge Graph and Cerebro to make smart decisions about where to route the work.

How Routing Decisions Are Made:​

  1. Context from Knowledge Graph: The Autonomous Engine first queries the Knowledge Graph for the customer's context. Are they in their onboarding "hypercare" period? What is their subscription level? What is their platform usage history?
  2. Intent Analysis by Cerebro: For complex requests (like a natural language query to the Sidekick app), Cerebro is used to determine the user's intent.
  3. Route to a Specialized Application: Based on the context and intent, the Engine routes the request to the appropriate backend application best suited to handle the work.
  4. The Sparky Safety Net: If the request type is unknown, ambiguous, or indicates a potential error, the Autonomous Engine will not guess. It will always fail safe by routing the request directly to Sparky for L1 triage, as detailed in the Sparky AI Agent Guide.

4. Proactive Notifications: Communicating Before They Ask​

A key principle of our customer experience is proactive communication. We use Cerebro to detect potential issues and notify customers before they are impacted.

Verbose Workflow: Proactive API Token Expiry Notification​

  1. Cerebro Detection: A scheduled Cerebro job runs daily, scanning the Knowledge Graph for all customer API tokens that are due to expire in the next 7 days.
  2. Autonomous Engine Task: For each expiring token, Cerebro creates a task for the Autonomous Engine: {"task": "notify_token_expiry", "customer_id": 123, "token_id": "xyz"}.
  3. Platform API Call: The Autonomous Engine calls a private endpoint on the Platform API to send the notification. This ensures all outbound communication is standardized, logged, and tracked.
  4. Customer Receives Notification: The customer receives an email and an in-app notification in Control Center, warning them about the expiring token and providing a direct link to generate a new one.

Example: Proactive Notification API Call​

This is an example of the internal API call the Autonomous Engine would make to the Platform API to send a notification.

Request: POST /v1/internal/notifications

{
  "customerId": "cust_abc123",
  "channel": ["email", "in_app"],
  "type": "proactive_alert",
  "urgency": "medium",
  "subject": "Action Required: Your API token is expiring soon",
  "message": "Hello [Customer Name], your API token named 'Primary Integration' is scheduled to expire in 7 days. To prevent any service disruption, please generate a new token and update your clients.",
  "cta": {
    "text": "Generate New Token",
    "url": "https://control.xops.io/settings/api-tokens"
  }
}

5. Accountability in Support: "Defend & Guide"​

Not every issue reported by a customer is a defect in our platform. We operate under a Shared Responsibility Model.

  • Data Quality: If a customer reports bad data in the Knowledge Graph, first verify if the source data they sent us was bad. If so, guide them to fix their source.
  • Third-Party Vendors: If an integration fails because a vendor (e.g., Twilio) is sending bad telemetry, we must isolate the issue to the vendor and direct the customer to manage their vendor relationship. We do not assume liability for external systems.

Refer to the Accountability Model for detailed playbooks on handling these scenarios.

6. Escalation Paths and Support​

When self-service and proactive notifications are not enough, customers need a clear path to human support.

  • Primary Support Channel: The Jira Service Management portal is the single source of truth for all support requests.
  • Hypercare Support: As detailed in the Customer Success Guide, customers in their onboarding hypercare period have access to a dedicated support channel with faster SLAs.
  • Incident Response: If a customer reports a P1/P2 incident, the ticket created in JSM immediately triggers our full Incident Management process.