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.
Leave a Reply