Forfis Blog

Tag: Ticket Triage and Routing

  • UK E-commerce Voice Agent for Ticket Triage: 3-Month GDPR-Compliant Pilot

    Process Audit and Baseline Measurement

    A 500-person e-commerce company in the UK handles 12,000 support tickets monthly, with 40% involving order status checks or returns. The support team spends 6 hours per day on manual data entry and routing, with an average cycle time of 4.2 hours from ticket creation to first response. The goal is to reduce manual back-office work by 30% and cut cycle time to under 2 hours, while maintaining GDPR compliance and supporting English plus two additional languages. The engagement starts with a two-week process audit that analyzes call recordings, ticket logs, and CRM data to identify the top five query types and the current error rate. The audit produces a baseline document with cycle time, error rate, and customer satisfaction scores for each query type, which becomes the success criteria for the pilot. The team selects one product category and one language for the isolated pilot, ensuring the scope is fixed and measurable. The pilot runs for four weeks, with a human-in-the-loop approval for any action that touches money or account changes. The architecture uses the Anthropic Claude API for response generation, with a custom REST API and webhooks connecting the voice agent to the existing CRM and helpdesk. No data is stored in the AI layer; all records remain in the client’s systems. The pilot ships with a measured before/after baseline, and the team reviews the results in a structured debrief before deciding on rollout.

    Voice Agent Architecture and Model Selection

    The voice agent uses a three-stage pipeline: speech-to-text, language model inference, and text-to-speech. The speech-to-text engine captures the caller’s voice and converts it to text with a 92% accuracy rate in English. The Anthropic Claude API generates the response using a prompt template that includes the caller’s intent, order details, and the company’s returns policy. The prompt is tuned for each language, with a glossary of product terms and a confidence threshold that routes low-confidence calls to human agents. The text-to-speech engine converts the response to natural-sounding audio with a 180 ms latency, which is within the acceptable range for conversational AI. The system supports English, German, and French, with a fallback to English if the confidence score drops below 85%. The voice agent does not make decisions with legal or similar significant effects; it provides information and captures data, with a human agent handling any action that touches money or account changes. The architecture is model-agnostic, so the team can switch to an open-weight model on client hardware if the data sensitivity requires it. The integration layer uses custom REST APIs and webhooks to connect the voice agent to the CRM and helpdesk, with no vendor lock-in on the AI model or integration layer.

    Integration Sprint and API Design

    The integration sprint delivers a working voice agent connected to the client’s CRM and helpdesk via REST APIs and webhooks. The deliverable includes the model configuration, prompt templates, API endpoints, and a runbook for the support team. The client retains full ownership of the code and configuration, with no vendor lock-in on the AI model or integration layer. The integration layer is designed to be modular, so the team can add new languages or product categories without re-architecting the system. The API endpoints are documented with OpenAPI 3.0, and the webhooks are signed with HMAC-SHA256 to ensure data integrity. The system logs all interactions with a timestamp, caller ID, and intent classification, which the support team can query via the CRM’s reporting dashboard. The runbook includes troubleshooting steps for common issues, such as high latency or low confidence scores, and a contact list for the integration team. The client’s IT team is trained on the system during the final week of the sprint, with a handover document that covers the architecture, configuration, and maintenance procedures. The integration sprint is fixed-scope, with a defined deliverable and a 48-hour rollback window if the pilot fails to meet the success criteria.

    Isolated Pilot and Rollback Strategy

    The pilot runs in isolation on a single product category and one language, with a measured baseline of cycle time and error rate before go-live. The system does not touch production data or affect other support channels. If the pilot fails to meet the predefined success criteria, the team rolls back to the manual process within 48 hours, with no data loss or system disruption. The success criteria include a 30% reduction in manual data entry, a cycle time under 2 hours, and an error rate below 5%. The team reviews the results in a structured debrief, with a focus on the error types and the customer satisfaction scores. The debrief produces a report that includes the before/after metrics, the error analysis, and a recommendation for rollout. The rollout plan includes a phased approach, with the voice agent expanding to additional languages and product lines over the next eight weeks. The team monitors the error rate and customer satisfaction scores during the rollout, with a 24-hour review window where a support lead audits a sample of AI-handled calls for accuracy. The rollout is considered successful if the error rate remains below 5% and the customer satisfaction score does not drop by more than 2 points.

    GDPR Compliance and Data Handling

    The system complies with GDPR Article 5 (data minimization) and Article 22 (automated decision-making). Voice recordings and transcripts are encrypted in transit and at rest, with a lawful basis for processing. The data is stored in the client’s CRM and helpdesk, not in the AI layer, which reduces the data footprint and simplifies the compliance review. The team documents the logic of the AI system in a Data Protection Impact Assessment, which is required if the system makes decisions with legal or similar significant effects. The voice agent does not make such decisions; it provides information and captures data, with a human agent handling any action that touches money or account changes. The system offers a human review option for any caller who requests it, and the team maintains a log of all human reviews. The data retention policy is aligned with the client’s existing GDPR compliance program, with a maximum retention period of 12 months for voice recordings and 24 months for transcripts. The team conducts a quarterly review of the data processing activities, with a focus on the error rate and the customer satisfaction scores. The compliance review is documented in a report that is shared with the client’s data protection officer.

    Risk Mitigation and Error Handling

    The main risk is the voice agent providing incorrect information about order status or returns policy. Mitigation includes a human-in-the-loop approval for any action that touches money or account changes, a confidence threshold that routes low-confidence calls to humans, and a 24-hour review window where a support lead audits a sample of AI-handled calls for accuracy. The team monitors the error rate and the customer satisfaction scores during the pilot and rollout, with a focus on the error types and the root causes. The error analysis is documented in a report that is shared with the support team, with a focus on the corrective actions and the preventive measures. The team conducts a monthly review of the system’s performance, with a focus on the cycle time, the error rate, and the customer satisfaction scores. The review produces a report that includes the metrics, the error analysis, and a recommendation for improvement. The team maintains a knowledge base of common issues and their solutions, which is updated monthly based on the error analysis. The knowledge base is used to train the support team and to improve the prompt templates for the voice agent.

  • Six Ways Forfis Automates Ticket Triage for Swiss Fintechs in a 3-Month Sprint

    1. Triage eats senior hours that should go to disputes

    A 2,000-employee payments firm in Zurich runs Zendesk as its primary helpdesk. Senior agents spend 40% of their day re-routing misclassified tickets and drafting first responses that follow the same template every time. The process audit identifies ticket triage and routing as the highest-impact workflow: 12,000 tickets per month, a median cycle time of 4.2 hours from receipt to first response, and a 14% error rate on routing. The AI layer classifies by intent, urgency, and department, then routes to the correct queue. After the pilot, median cycle time drops to 38 minutes and routing errors fall to 2.1%. The senior agents who previously handled triage now focus on complex disputes and fraud escalations, work that actually requires their judgment. The 3-month sprint covers audit, pilot, and rollout, with every decision logged for ISO 27001 audit trails.

    2. Workflow orchestration, not a chatbot wrapper

    The orchestration layer sits between Zendesk’s API and the model inference endpoint. Incoming tickets trigger a webhook that passes the ticket body, metadata, and customer history to the classifier. The model returns a structured JSON object with intent, urgency score, and recommended queue. The orchestrator validates the output against a schema, checks confidence thresholds, and routes the ticket accordingly. If confidence falls below 0.85, the ticket flags for human review. Every step logs a timestamp, model version, and input hash. This architecture means the client can swap the classifier model without touching the Zendesk integration or the routing logic. The orchestration layer is the stable contract; the model is a pluggable component.

    3. On-premise open-weight models keep regulated data local

    Swiss data protection law and the client’s ISO 27001 certification require that customer payment data never leaves the building. Forfis deploys an open-weight model on the client’s own GPU cluster, handling all ticket payloads that contain account numbers, transaction IDs, or personal identifiers. The model runs on-premise, so no regulated data crosses a network boundary. For non-sensitive workflows, such as routing a general FAQ ticket, the orchestrator can route to a cloud API where latency and cost are less critical. The model-agnostic design means the client chooses the model per workflow, not per project. This split keeps the ISO 27001 statement of applicability clean: the on-premise path satisfies Annex A.8.22 (use of cryptography) and A.8.15 (access control) without requiring a separate risk assessment for cloud data transfer.

    4. A 3-month sprint with a measured before/after baseline

    The pilot runs on one workflow for six weeks. The baseline is measured in the first two weeks: 12,000 tickets, 4.2-hour median cycle time, 14% routing error rate. The AI layer goes live in week three, handling triage and routing with human approval on any ticket flagged below the confidence threshold. By week six, the metrics show a 38-minute median cycle time and a 2.1% error rate. The before/after comparison is documented in a one-page report that the client’s CFO uses to justify the rollout budget. The pilot also surfaces edge cases: 3% of tickets contain multilingual content that the model misclassifies, prompting a fine-tuning pass before full rollout. This measured approach means the client sees ROI before committing to broader automation across invoice processing or document extraction.

    5. Human-in-the-loop by default, not as an afterthought

    The AI layer classifies and routes, but a human approves any action that touches money, health data, or a contract. In a payments context, this means the model drafts a refund response or flags a fraud-related ticket, but a senior agent signs off before the action executes. The approval threshold is not arbitrary; it is set based on the pilot’s error-rate data. If the model’s routing accuracy on fraud-related tickets is 97%, the human-in-the-loop threshold applies to that subset. For general FAQ tickets where accuracy is 99.5%, the system can auto-route without approval. This tiered approach frees senior staff from routine work while keeping them in the loop for high-stakes decisions. The approval log feeds directly into the ISO 27001 audit trail, showing who approved what and when.

    6. Plugs into Zendesk or Intercom without replacing them

    The integration sprint adds a new processing layer on top of the existing Zendesk or Intercom instance. No data migration is required; the AI layer reads tickets through the helpdesk’s native API and writes routing decisions back through the same API. The client’s existing workflows, SLAs, and reporting dashboards continue to function unchanged. The orchestration layer exposes a REST API that the helpdesk calls, so the integration is a few lines of configuration in Zendesk’s webhook settings. This means the client does not need to retrain agents on a new interface or rebuild their ticket taxonomy. The AI layer is invisible to the end customer; it simply makes the existing system faster and more accurate. The 3-month timeline includes two weeks of integration hardening after the pilot, where edge cases from the pilot are addressed and the system is stress-tested under production load.