Triage with AI, Escalate with Purpose

Most teams start with email rules or Slack keyword alerts. An admin sets up a rule to forward any email containing "urgent" to a shared channel. This works for a week, until clients learn that using the keyword gets a faster response. Soon, every email is marked "urgent," the channel becomes pure noise, and the team learns to ignore it.

This leads them to dedicated help desk software. These tools offer rule-based routing, but the logic is brittle. A rule that assigns tickets based on the phrase "billing issue" cannot distinguish between a simple request for an invoice copy and a complex dispute over a $20,000 charge. The first can be handled with an automated response; the second requires immediate C-level attention. The tool treats them identically, forcing manual review on every single ticket.

A 12-person insurance agency used a shared Outlook inbox for new claims. They set up rules to flag emails containing "new claim" to interrupt an adjuster. But they also received marketing spam, status update requests, and vendor invoices that included those keywords. Adjusters wasted the first 45 minutes of every day deleting noise and manually assigning the real claims, delaying response times by hours.

Syntora would begin an engagement by auditing your existing communication channels and understanding the critical events that warrant immediate human intervention. The initial step involves collecting a historical sample of 300-500 recent requests and their resolutions. This data would be used to establish a baseline for what 'urgent' or 'actionable' means within your specific business context.

For integrating with source systems, we would connect directly via their APIs. For instance, for an Outlook shared inbox, we would use the Microsoft Graph API, and for a web form, we would build a dedicated FastAPI webhook endpoint.

The core of the system would use the Claude API to classify and extract key information from each incoming request. We have experience building similar document processing pipelines using Claude API for financial documents, and the same pattern applies to this type of operational document. The system would be configured with a multi-shot prompt, including 5-10 real examples, to teach the AI to identify intent (e.g., 'Status Update' vs. 'New Lead' vs. 'Critical Failure'), urgency, and structured data like an Account ID or Order Number.

Based on the AI's classification, a Python function would determine the appropriate next action. For example, a 'New Lead' from a company meeting specific criteria could be routed to a designated Slack channel and simultaneously added to a CRM via its API. A 'Status Update' request might automatically trigger an email reply with a link to a tracking portal. A 'Critical Failure' with negative sentiment could trigger an alert in a system like PagerDuty. Every event would be logged to a Supabase table for auditing and transparency.

The entire workflow would typically be packaged into a container and deployed as an AWS Lambda function, a design choice aimed at optimizing operational costs and scalability. We implement structured logging using structlog, piping all system events to Amazon CloudWatch. We would configure monitoring and alerting for operational issues, such as spikes in API errors or increased processing queue depth, to ensure system reliability.