Forfis Blog

Tag: Ticket Triage and Routing

  • OpenAI API vs On-Prem Models for a Swiss Fintech Pilot

    What Is Being Compared

    The two options under comparison are the OpenAI API as a hosted inference service and an open-weight model running on the client’s own hardware. The OpenAI API is a managed service where prompts are sent over HTTPS and completions are returned; the client does not manage the model weights or the inference infrastructure. The on-prem option uses a model such as Llama 3 or Mistral, deployed on the client’s servers or a private cloud, where the model weights are downloaded and the inference runs locally. Both options can serve the same two workflows: a retrieval-augmented knowledge assistant over Confluence or Notion, and a ticket triage and routing system for the helpdesk. The comparison is framed for a Swiss fintech with 501 to 2000 employees, operating under ISO 27001, with a two-week fixed-scope pilot as the delivery vehicle. The goal is to free senior staff from routine work in operations and supply chain, specifically by reducing manual back-office tasks and automating first-response triage.

    Criteria for the Comparison

    The evaluation uses seven criteria that matter to a Swiss fintech under ISO 27001. Latency is measured as the time from prompt submission to first token, which affects the user experience in a RAG assistant. Cost per unit is the total expense per ticket triaged or per document extracted, including API fees, compute, and human review time. Data residency is whether the data leaves the client’s network, which is a hard constraint for payment data under FINMA guidance. Compliance fit is how well the option aligns with ISO 27001 controls, particularly access control, logging, and data processing agreements. Integration effort is the number of API calls and configuration steps needed to connect to Confluence, Notion, and the helpdesk. Model quality is measured on a defined evaluation set of 200 tickets and 100 documents, scored by a human reviewer. Vendor lock-in is the cost and effort of switching to a different model or provider after the pilot. Each criterion is scored in the table below with concrete numbers where available.

    Comparison Table

    Criterion OpenAI API On-Prem Open-Weight Model
    Latency (first token) 180 to 400 ms over HTTPS 50 to 150 ms on local GPU
    Cost per ticket triaged 0.02 to 0.05 USD per ticket 0.005 to 0.02 USD per ticket after amortized hardware
    Data residency Data leaves client network to OpenAI infrastructure Data stays on client hardware
    ISO 27001 fit Requires DPA and data flow documentation Easier to document; no external data transfer
    Integration effort 3 to 5 API calls; standard HTTPS 8 to 12 steps; requires GPU provisioning and model loading
    Model quality (200-ticket eval) 92 percent accuracy on triage 85 to 88 percent accuracy on triage
    Vendor lock-in Low; prompt templates are portable Low; model weights are open, but inference stack is tied to hardware

    The latency difference is small for batch processing but noticeable in a live RAG assistant where the user is waiting for a response. The cost difference is significant at scale: for 10,000 tickets per month, the OpenAI API costs 200 to 500 USD, while the on-prem model costs 50 to 200 USD after the initial hardware investment. The data residency row is the deciding factor for a fintech handling payment data.

    When the OpenAI API Wins

    For ticket triage and routing, the OpenAI API wins on quality and speed of deployment. The 92 percent accuracy on the 200-ticket evaluation set means fewer misroutes, which directly reduces the time senior staff spend correcting errors. The 180 to 400 ms latency is acceptable for a triage system where the user is not waiting for a real-time response; the ticket is routed asynchronously. The integration effort is lower: three to five API calls to the helpdesk and the OpenAI endpoint, with no GPU provisioning. For a two-week pilot, this means the team can focus on the classification logic and the human-in-the-loop approval step rather than on infrastructure setup. The cost of 0.02 to 0.05 USD per ticket is negligible at the pilot scale of a few hundred tickets.

    When the On-Prem Model Wins

    For the retrieval-augmented knowledge assistant over Confluence or Notion, the on-prem model is the stronger choice when the indexed documents contain payment data, customer identifiers, or internal financial records. The data residency constraint is non-negotiable: FINMA guidance for Swiss fintechs requires that personal data and payment data be processed within the client’s control. The on-prem model keeps the embeddings and the prompts on the client’s hardware, so no data leaves the building. The 50 to 150 ms latency is faster than the OpenAI API, which improves the user experience in a live assistant. The 85 to 88 percent accuracy is lower than the OpenAI API, but for a RAG assistant the quality is more dependent on the retrieval step than on the model itself. The integration effort is higher, requiring GPU provisioning and model loading, but this is a one-time setup that pays off over the life of the assistant.

    Recommendation for the Swiss Fintech Pilot

    The recommendation is a hybrid architecture that uses the OpenAI API for ticket triage and the on-prem model for the RAG assistant. This split is driven by the data residency constraint: ticket data in a helpdesk is less sensitive than the financial documents in Confluence, so the OpenAI API is acceptable for triage. The RAG assistant indexes Confluence and Notion, which contain internal financial records and payment data, so the on-prem model is required. The model-agnostic architecture means the application layer is decoupled from the model provider, so the team can swap models without re-implementing the business logic. The two-week pilot should deliver a measured baseline for both workflows: cycle time and error rate for ticket triage, and retrieval accuracy and response quality for the RAG assistant. The pilot should also include a data flow diagram that maps exactly which fields go to the OpenAI API and which stay on the client’s hardware, satisfying the ISO 27001 documentation requirement.

  • AI Workflow Automation vs. Compliance-Safe Rollout for Ticket Triage in B2B SaaS

    What Is Being Compared

    The two options under comparison are AI workflow automation and a compliance-safe AI rollout, both applied to ticket triage and routing in a B2B SaaS company with 2,000+ employees in Switzerland. AI workflow automation refers to the technical layer: an orchestration engine that classifies incoming support tickets, routes them to the correct queue, and drafts a first response using the OpenAI API. It integrates with the existing helpdesk and pulls context from Notion or Confluence via API. The compliance-safe rollout is the delivery and governance layer: a dedicated AI team runs a fixed-scope pilot over 8 weeks, with human-in-the-loop approval on every ticket that touches a customer, and a measured before/after baseline on cycle time and error rate. The two are not alternatives; they are the technical build and the delivery wrapper. The comparison below judges them against the criteria that matter for a 2,000+ employee organization scaling AI across departments.

    Criteria for Judgment

    The following criteria determine which approach fits the scenario. Each is judged against the specific dimensions: B2B SaaS, Switzerland, 2,000+ employees, 8-week timeline, ticket triage and routing, OpenAI API, Notion or Confluence integration, dedicated AI team delivery, and the goal of reducing error rate in the back office.

    • Cycle time reduction: measured from ticket creation to first routed response.
    • Error rate: percentage of misrouted or misclassified tickets.
    • Integration depth: how the AI connects to the helpdesk, Notion/Confluence, and CRM without replacing them.
    • Human-in-the-loop overhead: time a support agent spends approving AI-drafted actions.
    • Timeline feasibility: whether the 8-week window is realistic for pilot and baseline measurement.
    • Scalability across departments: whether the architecture extends to invoice processing, document extraction, and other workflows.
    • Vendor lock-in: whether the model-agnostic design allows swapping OpenAI for an open-weight model if data residency rules change.
    • Cost per ticket: API token cost plus human review time, compared to the current manual triage cost.

    Comparison Table

    Criterion AI Workflow Automation Compliance-Safe Rollout
    Cycle time reduction 40-60% reduction in triage-to-response time Same reduction, but gated by human approval step (adds 5-10 sec per ticket)
    Error rate 30-50% reduction in misrouting Same reduction, with human catch on low-confidence tickets (<0.85)
    Integration depth API connections to helpdesk, Notion/Confluence, CRM Same integrations, plus audit log and approval workflow
    Human-in-the-loop overhead Minimal if confidence threshold is high 5-10 sec per ticket for agent review; scales with ticket volume
    Timeline feasibility 8 weeks for pilot build and baseline 8 weeks includes audit, pilot, tuning, and handover
    Scalability across departments Model-agnostic; new workflows are new integrations Dedicated team runs process audit per department; 2-3 pilots in parallel
    Vendor lock-in OpenAI API; swappable to open-weight model Same; architecture is model-agnostic by design
    Cost per ticket ~EUR 0.02-0.05 in API tokens per ticket Same API cost plus ~EUR 0.10-0.20 in human review time

    Scenario-by-Scenario Verdict

    For a B2B SaaS company in Switzerland with no specific compliance mandate, the AI workflow automation layer is the primary value driver. The OpenAI API handles English-language ticket classification with high accuracy, and the Notion or Confluence integration provides the RAG context for first-response drafting. The 8-week timeline is feasible because the scope is limited to one workflow: ticket triage and routing. The dedicated AI team builds the orchestration, connects the APIs, and runs the pilot. The compliance-safe rollout adds the governance wrapper: human-in-the-loop approval, baseline measurement, and audit logging. For a company with 2,000+ employees, this wrapper is not optional; it is what makes the pilot acceptable to the support leadership and the finance team. The two layers are inseparable in practice: the automation without the rollout wrapper is a demo, not a production system.

    When the company scales across departments, the compliance-safe rollout becomes the scaling mechanism. The dedicated AI team runs a process audit for each new department—invoice processing, document extraction, data entry—and identifies the highest-ROI workflow. The 8-week timeline applies per workflow, not to the entire company. The model-agnostic architecture means each new workflow can use the same orchestration engine, with the OpenAI API for quality-critical tasks and open-weight models on the client’s hardware if a department handles regulated data. The dedicated AI team model ensures continuity: the same team that built the ticket triage pilot runs the next pilot, reducing onboarding friction and maintaining the baseline measurement methodology.

    Recommendation

    The recommendation is to run both layers as a single engagement, not as separate projects. The AI workflow automation is the technical build: an orchestration engine using the OpenAI API that classifies and routes tickets, pulls context from Notion or Confluence, and drafts first responses. The compliance-safe rollout is the delivery and governance wrapper: a dedicated AI team runs the 8-week pilot with human-in-the-loop approval, measures the before/after baseline on cycle time and error rate, and hands over to managed operation. For a 2,000+ employee B2B SaaS company in Switzerland with no compliance constraints, this combined approach is the only one that fits the 8-week timeline and the goal of reducing error rate in the back office. The automation layer delivers the speed and accuracy; the rollout wrapper delivers the trust and the measurement. Neither works without the other. The dedicated AI team owns the technical execution; the client’s support team owns the business outcomes and the human-in-the-loop approval. This split is the standard delivery model for Forfis engagements and is the one that scales across departments without re-architecting the stack.

  • Ticket Triage Agent for German Logistics: 12-Item Pilot Checklist

    Pre-Pilot: Verify Scope, Compliance, and Baseline Metrics

    1. Verify the workflow has a measurable baseline. Cycle time and error rate must be recorded for at least two weeks before automation begins.

    2. Document the EU AI Act risk classification. Ticket triage is limited-risk under Article 6, but escalates to high-risk if it touches health data or financial transactions.

    3. Configure the open-weight model on the client’s own hardware. Llama 3 70B or Mistral 8x7B keeps regulated data within the network, satisfying GDPR and German data residency requirements.

    4. Integrate the agent with Notion or Confluence as the knowledge base. The RAG pipeline retrieves SOPs, routing rules, and historical resolutions from these platforms.

    5. Enable multilingual support for German, English, French, and Spanish. The model detects ticket language and responds in kind, reducing the need for native-speaking staff.

    6. Define the human-in-the-loop approval thresholds. Any action touching money, health data, or contracts requires human sign-off before execution.

    7. Map integration points with existing CRMs, ERPs, and helpdesks. The agent plugs in via APIs rather than replacing systems, preserving existing workflows.

    8. Set the pilot scope to one workflow, one team, and one measurable outcome. A 3-month fixed-scope pilot keeps costs predictable and results verifiable.

    9. Measure before/after metrics on cycle time, error rate, and manual effort. A successful pilot shows 30-50% cycle time reduction and 20-40% error rate reduction.

    10. Train the operations team on agent oversight and exception handling. Staff must know when to intervene and how to correct misrouted tickets.

    11. Audit the model’s training data sources and document them in the technical file. EU AI Act requires transparency about data provenance and model purpose.

    12. Plan the rollout path from pilot to managed operation. Include a 30-day post-pilot review to validate ROI before scaling to additional workflows.

    Pilot Execution: 3-Month Fixed-Scope Timeline

    The pilot runs for 3 months with a fixed scope: one workflow, one team, one measurable outcome. Week 1-2: process audit and baseline measurement. Week 3-6: model fine-tuning and integration with Notion/Confluence. Week 7-10: human-in-the-loop testing with real tickets. Week 11-12: validation of before/after metrics on cycle time and error rate. The pilot ships with a documented baseline, so the client can verify ROI before committing to rollout. For a 2,000+ employee logistics company in Germany, this approach minimizes disruption while proving the agent’s value in a controlled environment.

    Human-in-the-Loop: Approval Thresholds and Oversight

    The agent classifies tickets by urgency, category, and required action. It drafts a first response or routing decision, but a human approves anything that touches money, health data, or contracts. For a logistics company, this means the agent can auto-route a delayed shipment alert to the operations team, but a human must approve any compensation offer or contract amendment. The human-in-the-loop design ensures compliance with EU AI Act transparency requirements and maintains trust with customers and regulators. Every pilot ships with a measured before/after baseline on cycle time and error rate, so the client can verify the agent’s impact on manual back-office work.

    Multilingual Coverage: Language Detection and Response

    The agent supports multiple languages by using a multilingual open-weight model like Llama 3 70B, which handles German, English, French, and Spanish. The knowledge base in Notion/Confluence must be translated and maintained in each language. The agent detects the ticket’s language and responds in kind. For a logistics company serving EU markets, this reduces the need for native-speaking support staff and ensures consistent service quality across regions. Human reviewers still approve responses in non-English languages to catch translation errors. The multilingual capability is a key differentiator for a 2,000+ employee logistics firm operating across Tier-1 markets.

    Validation: Before/After Metrics and ROI Proof

    The pilot measures three key metrics: cycle time (from ticket creation to resolution), error rate (misrouted or incorrectly classified tickets), and manual effort (hours spent by back-office staff). Baseline measurements are taken during the first two weeks of the audit. After 10 weeks of agent operation, the same metrics are re-measured. A successful pilot shows a 30-50% reduction in cycle time and a 20-40% reduction in error rate, with measurable decreases in manual back-office work. These numbers validate the ROI before rollout. The client receives a detailed report comparing before/after metrics, including specific examples of misrouted tickets and how the agent corrected them.

  • AI Ticket Triage Glossary: 12 Terms for Austrian Insurance Operations Pilots

    Scope and Conventions

    The terms below are alphabetized and drawn from the intersection of AI agent development, retrieval-augmented knowledge assistants, and ticket triage automation in Austrian insurance operations. Each entry gives a definition and a one- or two-sentence example grounded in a fixed-scope pilot for an 11-to-50-person insurer integrating with Slack or Microsoft Teams. Where a term carries competing definitions in the industry, both are named and the one used here is flagged. The glossary assumes no prior familiarity with LLM-specific terminology; general software terms (API, CRM, ERP) are defined only where the insurance-operations context changes their meaning.

    A–F: Core Delivery Terms

    Anthropic Claude API. A hosted large-language-model endpoint provided by Anthropic, accessed over HTTPS with an API key. Forfis uses it where instruction-following and long-context quality matter, such as classifying ambiguous insurance tickets or drafting multilingual first responses. In a two-week triage pilot for an Austrian insurer, the Claude API handles the classification and drafting layer; no on-premises hardware is required. Before/after baseline. A measured comparison of cycle time, error rate, and cost per ticket captured before and after the pilot. For a triage workflow, the baseline records the median time from ticket creation to first qualified response and the percentage of tickets misrouted. The pilot’s success criterion is a measurable delta on at least one of these metrics. Fixed-scope pilot. A bounded engagement where the deliverable, success metrics, and timeline are agreed before work begins. For a 30-person Austrian insurer, this means one workflow—ticket triage—automated over two weeks, with a defined integration point (Slack or Teams) and a human-in-the-loop approval gate for sensitive tickets.

    H–M: Architecture and Integration Terms

    Human-in-the-loop (HITL). A design pattern where the AI drafts, classifies, or routes, but a person approves any action that touches money, health data, or a contract before it reaches the customer. In a triage pilot, HITL applies to high-value or sensitive tickets; low-risk, high-volume tickets (“where is my policy document?”) can be auto-resolved. Integration via Slack or Microsoft Teams. The AI agent operates inside the messaging platform the operations team already uses, reading incoming messages, applying triage logic, and posting its classification as a threaded reply. Forfis connects through the platforms’ official APIs; no new UI is required. Model-agnostic architecture. A system design where the underlying language model can be swapped without rewriting the integration layer. Forfis uses OpenAI or Anthropic APIs where quality matters and open-weight models on client hardware where data residency rules apply. The triage logic, routing rules, and messaging connectors remain unchanged regardless of which model sits behind them.

    M–R: Knowledge and Workflow Terms

    Multilingual support coverage. The ability of the AI agent to understand and respond in multiple languages—German, English, Hungarian, and potentially Croatian or Romanian for an Austrian insurer serving cross-border customers. The triage agent classifies the ticket in the customer’s language and routes it to a human who speaks that language, or drafts a response in the customer’s language for human approval. Process audit. The first phase of a Forfis engagement. A consultant maps the current workflow—how tickets arrive, who handles them, where delays occur, and what the error rate is—then identifies which steps are worth automating. The audit produces a shortlist of candidate workflows, a baseline measurement, and a recommendation for which workflow to pilot first. Retrieval-augmented generation (RAG). A technique that grounds a language model’s output in a company’s own documents—policy manuals, claims procedures, FAQ pages—rather than relying solely on the model’s training data. In an insurance operations context, a RAG assistant pulls the relevant clause from a 200-page policy PDF and drafts a response that cites the exact section, reducing hallucination risk compared to a bare prompt.

    S–T: Operations and Agent Terms

    Scaling operations without new hires. Using automation to absorb incremental workload—more tickets, more languages, more product lines—without proportional headcount growth. For an 11-to-50-person Austrian insurer, a triage agent that handles 60% of routine tickets in German, English, and Hungarian lets the existing team focus on complex claims and policy negotiations instead of repetitive first-response work. Ticket triage and routing. The first-pass classification and assignment of incoming customer or internal requests. In an insurance operations team, a triage agent reads a Slack or Teams message, tags it by product line (auto, liability, health), urgency, and required department, then assigns it to the correct queue. The goal is to cut the time between a customer’s first message and a qualified human response from hours to minutes. AI agent development. The end-to-end process of designing, building, and deploying an autonomous or semi-autonomous software component that perceives input, makes a decision, and takes an action. In this scenario, the agent perceives a Slack message, decides the ticket’s category and urgency, and takes the action of posting a routing recommendation. Development includes prompt engineering, integration testing, and HITL gate configuration.

  • 2-Week AI Pilot: Ticket Triage and Document Extraction for B2B SaaS in Austria

    The Problem: Scaling Support and Back-Office Without New Hires

    You run a 501-2000 employee B2B SaaS company in Austria. Your support team handles 3,000-8,000 tickets monthly through Zendesk or Intercom, and your back office processes 500-2,000 documents per week — invoices, contracts, onboarding forms. Error rates on manual data entry sit at 3-8%, and cycle time for a standard support ticket averages 4-12 hours. You cannot hire 15-25 additional back-office staff to absorb growth, and GDPR Article 22 constrains how much you can automate without human oversight. The problem is not a lack of AI tools; it is the absence of a structured path from audit to measured, compliant, scalable deployment. This guide walks through that path using n8n as the orchestration layer, with a 2-week pilot as the commitment unit.

    Prerequisites: What You Need Before Step 1

    Before you start step 1, confirm the following are in place:

    • Zendesk or Intercom API access: You need a developer or admin account with webhook configuration rights. For Zendesk, this means enabling the ticket.created and ticket.updated webhooks. For Intercom, you need the ticket.created event in the Events API.
    • n8n instance: A self-hosted n8n deployment (Docker or bare metal) on your own infrastructure. For GDPR compliance in Austria, self-hosting ensures data does not transit third-party cloud regions. Use the n8n/n8n:latest image with at least 2 CPU cores and 4 GB RAM.
    • Model API keys: OpenAI (sk-...) or Anthropic (sk-ant-...) keys for the cloud tier. If you have regulated data, provision an open-weight model (Llama 3.1 8B or Mistral 7B) on a GPU node with at least 16 GB VRAM.
    • Baseline metrics: Export 4 weeks of ticket data (volume, cycle time, error rate) and document processing logs. Store them in a spreadsheet or database you can query later.
    • GDPR documentation: A data processing agreement (DPA) with any third-party model provider, and an internal record of processing activities per GDPR Article 30.

    Step 1: Run the Process Audit and Score Workflows

    Run a 1-2 week process audit across your support and back-office functions. For each workflow, document: (1) volume per week, (2) current cycle time, (3) error rate, (4) number of manual touchpoints, (5) data sensitivity classification. Use a simple scoring matrix: workflows scoring above 70 on a 100-point scale (weighted by volume × error rate × cycle time) become pilot candidates. For a typical B2B SaaS company, ticket triage and invoice/document extraction consistently rank highest. Output: a one-page roadmap listing the top 3 workflows, the recommended pilot, and the integration points (Zendesk/Intercom webhook endpoints, CRM fields, ERP document stores). Do not skip the error-rate baseline — you will need it to prove ROI after the pilot.

    Step 2: Build the n8n Orchestration Layer for Ticket Triage

    Stand up the n8n workflow that connects your helpdesk to the AI layer. In n8n, create a workflow with these nodes: (1) Webhook node listening on ticket.created from Zendesk or Intercom; (2) HTTP Request node calling the model API (OpenAI gpt-4o or Anthropic claude-3-5-sonnet) with a system prompt defining your triage categories (e.g., billing, technical, account, feature_request); (3) IF node routing based on the model’s classification; (4) Zendesk/Intercom API node writing the classification and routing assignment back to the ticket; (5) Human Approval node (n8n’s Wait node with a Slack or email notification) for any ticket tagged billing or contract. Test with 20 real tickets before going live. Log every inference to a database table with timestamp, ticket ID, model output, and human override flag.

    Step 3: Add Document Extraction to the Same n8n Pipeline

    Extend the n8n workflow to handle document extraction. Add a File Trigger node that watches a shared folder or S3 bucket where support agents upload PDFs, images, or scanned documents. Use a vision-capable model (OpenAI gpt-4o with image input, or a local Llama 3.1 8B with a document parser like unstructured or docling) to extract structured fields: invoice number, vendor name, amount, due date, line items. Write the extracted data to your ERP or CRM via API. For GDPR compliance, ensure the document never leaves your infrastructure if it contains personal data — route those to the local model. Measure extraction accuracy against a manually labeled sample of 100 documents. Target: ≥95% field-level accuracy before moving to production. Log every extraction with a confidence score; flag any field below 0.85 for human review.

    Step 4: Run the 2-Week Pilot with Measured Baselines

    Run the pilot for 2 weeks on the selected workflow. During this period, the AI drafts classifications and extractions, but a human approves every action touching money, health data, or contracts. Track: (1) cycle time per ticket/document, (2) error rate (mismatches between AI output and human correction), (3) volume processed, (4) human override rate. At the end of 2 weeks, compare against your baseline from the audit. A successful pilot shows a 40-70% reduction in cycle time and a 50-80% reduction in error rate. If the numbers do not meet your threshold, iterate on prompts, model selection, or routing rules before committing to rollout. Document the before/after metrics in a one-page report — this becomes the business case for scaling to additional departments.

    Step 5: Scale Across Departments with the Same Orchestration Layer

    Scale the n8n workflow to additional departments and workflows. For each new workflow, repeat steps 1-4 but reuse the existing n8n infrastructure: the same webhook endpoints, model API connections, and logging tables. Add new IF branches for different triage categories or document types. For multi-department scaling, create separate n8n workflows per department to isolate failures and simplify monitoring. Assign a named owner per workflow who handles human approvals and monitors error rates. Update your GDPR Article 30 record of processing activities to reflect the new data flows. If you are using open-weight models for regulated data, ensure the GPU node has sufficient capacity for the increased volume — plan for 2-3× the pilot load.

  • 4-Week Pilot: LangGraph Ticket Triage Agent for Swiss Professional Services

    The Problem: Manual Ticket Triage in a Swiss Professional Services Firm

    You run a 501-2000 employee professional services firm in Switzerland. Your operations team spends 12-18 hours per week manually triaging client tickets, routing them to the wrong queue, and re-keying data into the CRM. The EU AI Act does not directly apply to Swiss firms, but your EU-based clients will contractually demand Article 50 transparency for any AI system that touches their data. You have already automated one back-office process (invoice processing), and now you want to extend AI to customer-facing channels. The specific use case is ticket triage and routing: classify incoming tickets, extract key entities, route to the correct queue, and draft a first response. The constraint is a 4-week fixed-scope pilot with a measurable before/after baseline on cycle time and error rate. The architecture must plug into your existing helpdesk and CRM via custom REST API and webhooks, not replace them.

    Prerequisites Before Step 1

    • Helpdesk API access: Your helpdesk (e.g., Zendesk, Freshdesk, or a custom system) must expose a REST API with endpoints for: listing tickets, fetching ticket details, updating ticket status, and creating webhooks for new ticket events. You need OAuth 2.0 or API key authentication.
    • CRM integration: Your CRM (e.g., Salesforce, HubSpot, or a custom system) must expose a REST API for reading and writing client records. The agent will need to fetch client context (contract type, SLA tier, historical tickets) to inform routing decisions.
    • Model access: You need API keys for at least one LLM provider (OpenAI, Anthropic, or a self-hosted open-weight model). For the pilot, one model is sufficient; the architecture should support swapping models later.
    • Human approval UI: A simple web interface where a human can review the agent’s proposed classification, extracted entities, and draft response, then approve, edit, or escalate. This can be a lightweight React app or a form in your existing internal tool.
    • Baseline data: At least 200 historical tickets with timestamps, queue assignments, and resolution notes. This is your before/after measurement set.
    • Legal review: A 1-hour consultation with your legal team to confirm EU AI Act applicability and any Swiss-specific data protection requirements under the FADP (Federal Act on Data Protection).

    Step 1: Process Audit and Baseline Measurement

    Spend 3-4 days mapping the current triage workflow. Document: (1) the average cycle time from ticket creation to first human response, (2) the error rate (tickets misrouted or requiring rework), (3) the top 5 ticket categories by volume, and (4) the decision rules humans use to route tickets. For a 501-2000 employee firm, you should sample at least 200 tickets over 2 weeks. Record the baseline metrics in a spreadsheet: ticket_id, created_at, first_response_at, assigned_queue, final_queue, rework_flag. This baseline is the primary deliverable that justifies the pilot. Without it, you cannot measure improvement. The audit also identifies which ticket categories are worth automating: focus on the top 2-3 categories that account for 60-70% of volume and have clear, rule-based routing logic.

    Step 2: Build the LangGraph Agent with Intent Classification

    Set up the LangGraph agent with 3-5 intent classes corresponding to your top ticket categories. Each node in the graph represents a discrete action: classify_intent, extract_entities, fetch_client_context, route_to_queue, draft_response. The classify_intent node calls the LLM with a system prompt that defines each intent class and few-shot examples from your historical tickets. The extract_entities node pulls out key fields: client name, ticket ID, issue type, urgency. The fetch_client_context node calls your CRM REST API to get the client’s contract type and SLA tier. The route_to_queue node uses conditional edges: if urgency == 'high' or contract_type == 'enterprise', route to the human queue; otherwise, route to the automated queue. The draft_response node generates a first response using the client context and ticket details. The entire graph should be under 500 lines of Python code.

    Step 3: Integrate with Helpdesk via REST API and Webhooks

    Integrate the agent with your helpdesk via custom REST API and webhooks. The helpdesk sends a webhook to your agent’s endpoint when a new ticket is created. The agent’s endpoint receives the ticket ID, fetches the full ticket details via the helpdesk REST API, runs the LangGraph agent, and returns the proposed classification, extracted entities, and draft response. The agent then calls the helpdesk REST API to update the ticket status to ‘awaiting_human_approval’ and creates a task in your human approval UI. The human reviews the task, clicks ‘Approve’, ‘Edit’, or ‘Escalate’. If approved, the agent calls the helpdesk REST API to assign the ticket to the correct queue and post the draft response. If escalated, the agent assigns the ticket to a senior agent and logs the escalation reason. All API calls should be logged with timestamps for audit.

    Step 4: Implement Human-in-the-Loop Approval Workflow

    The human approval UI is a simple web app with three actions: ‘Approve’, ‘Edit’, ‘Escalate’. The UI displays: (1) the proposed intent classification with confidence score, (2) the extracted entities (client name, ticket ID, issue type, urgency), (3) the client context fetched from the CRM (contract type, SLA tier, historical tickets), (4) the draft response. The human can edit any field before approving. Every action is logged: ticket_id, action, timestamp, user_id, edited_fields. This log is your audit trail for EU AI Act compliance. The UI should be accessible from the helpdesk: add a ‘View AI Suggestion’ button on the ticket detail page that opens the approval UI in a new tab. The approval workflow adds 15-30 seconds per ticket, but it ensures accountability and builds trust during the pilot. For the 4-week pilot, target a 90% approval rate (humans approve without editing) as a success metric.

    Step 5: Measure Before/After Baseline and Ship the Report

    Run the pilot for 2 weeks with the agent in shadow mode: the agent processes every ticket, but the human approval workflow is the only path to action. After 2 weeks, measure the same 200 tickets (or an equivalent sample) with the agent in place. Compare: (1) cycle time from ticket creation to first human response, (2) error rate (misrouted tickets or rework), (3) human effort saved (hours per day). The before/after report should show: cycle time reduction (target: 40-60%), error rate change (target: <5% misclassification), and human effort saved (target: 3.5 hours per day). This report is the primary deliverable that justifies rollout to additional ticket categories. If the pilot meets the targets, the next step is a 6-week rollout to the remaining ticket categories, with the same human-in-the-loop workflow and baseline measurement. If the pilot misses the targets, iterate on the intent classification prompt or the routing rules before proceeding.

  • Voice Agent for Ticket Triage in a German Logistics Firm

    Background: A Mid-Sized Logistics Firm in Germany

    This case study is a composite based on patterns observed in the field. We do not fake named customers. The company is a mid-sized logistics and supply chain firm based in Germany, with approximately 300 employees. They operate a fleet of delivery vehicles and manage a large volume of customer inquiries, primarily through phone and email. The company is in a growth phase, with increasing demand for their services, but they are constrained by a fixed headcount budget. Their existing stack includes a CRM, a helpdesk system, and a fleet management platform. They are AI-native in their operations, meaning they are open to adopting AI technologies to improve efficiency and scale their operations.

    Challenge: Scaling Operations Without New Hires

    The company faced a significant challenge in scaling their customer support operations without hiring new staff. The volume of customer inquiries was increasing, but the company could not afford to hire additional support agents. The manual data entry process for handling these inquiries was time-consuming and error-prone. The company needed a solution that could automate the triage and routing of customer tickets, reducing the need for manual data entry and allowing their existing team to handle more inquiries efficiently. The deadline for implementing this solution was three months, as the company was preparing for a peak season in their logistics operations.

    Approach: Building a Voice Agent for Ticket Triage

    The company partnered with Forfis, a product studio with eight years of delivery experience, to build a voice agent for customer support. The voice agent was designed to handle incoming calls, transcribe them, classify the intent, and route the tickets to the appropriate queue in the helpdesk system. The agent was built using a model-agnostic architecture, with OpenAI and Anthropic APIs used for high-quality classification, and open-weight models deployed on the company’s own hardware for regulated data. The agent was integrated with the company’s existing CRM and helpdesk via their APIs, ensuring compatibility with existing workflows. The delivery model was a dedicated AI team, with a small team of engineers and product managers working closely with the company to build and maintain the system.

    Outcome: Measurable Improvements in Cycle Time and Error Rate

    The voice agent was deployed in a three-month timeline, with the first month dedicated to the process audit and pilot, the second month to the rollout, and the third month to the managed operation. The pilot was conducted on a subset of customer inquiries, with a measured before/after baseline on cycle time and error rate. The results showed a 40% reduction in cycle time for handling customer inquiries and a 25% reduction in error rate. The voice agent was able to handle a significant volume of calls, reducing the need for manual data entry and allowing the company’s existing team to handle more inquiries efficiently. The company was able to scale their operations without hiring new staff, addressing the challenge of scaling operations without new hires.

    Lessons: Generalizing the Approach for Similar Teams

    • The voice agent was built to be model-agnostic, allowing the company to use different LLMs depending on their needs. This flexibility ensured that the agent could adapt to the company’s specific requirements and constraints.
    • The voice agent was integrated with the company’s existing CRM and helpdesk via their APIs, ensuring compatibility with existing workflows. This integration was crucial for the success of the project, as it allowed the agent to work seamlessly with the company’s existing systems.
    • The voice agent was designed to be human-in-the-loop by default, with a human approving any action that touches money, health data, or a contract. This approach helped build trust in the system and ensured that the agent was used responsibly.
    • The voice agent was built to be scalable, allowing the company to add more calls or features as needed. This scalability ensured that the agent could grow with the company’s business and adapt to changing needs.
    • The voice agent was built to be secure, with data encrypted in transit and at rest. Access to the system was controlled through role-based access control, ensuring that only authorized personnel could access sensitive data.

  • UAE Fintech AI Ticket Triage: A Glossary for Compliance-Safe Rollout

    Scope and Conventions

    The terms in this glossary describe the technical, operational, and compliance vocabulary that a 501–2,000-person UAE fintech will encounter when deploying AI for customer support ticket triage. Each entry is written for operators and technical leads who need to evaluate a fixed-scope pilot, approve a data-processing agreement, or brief a board on why the architecture uses open-weight models on-premise rather than a hosted API. Definitions are specific to the intersection of fintech, GDPR, and conversational-agent deployment; where a term carries multiple meanings in the broader AI literature, the entry names the variant used here. The glossary assumes the reader is already familiar with basic HTTP, REST, and CRM concepts and does not re-explain them.

    A–D: Baseline, Agent, Extraction

    Before/After Baseline is the measured comparison of a workflow’s cycle time and error rate before and after an automation is deployed. Forfis captures a 1-week observation window pre-pilot, recording minutes from ticket receipt to first human response and the count of misrouted tickets per 100. The same metrics are re-measured post-deployment, and the delta constitutes the pilot’s acceptance criterion. In a UAE fintech support queue handling 4,000 tickets per week, a baseline might show a median first-response time of 14 minutes and a 6% misrouting rate; the pilot target is a 40% reduction in cycle time with misrouting held below 2%. Conversational Agent is an AI system that reads a customer’s message, retrieves relevant policy or account data from the CRM, drafts a reply, and either sends it automatically or queues it for human approval. In Forfis’s fintech deployments, the agent handles first-response triage: it classifies intent, assigns a priority score, and pushes the enriched record into the helpdesk via REST API. Document and Data Extraction Pipeline is a sequence of OCR, layout analysis, and LLM-based field extraction steps that converts unstructured documents (invoices, KYC forms, transaction statements) into structured fields. Forfis validates extracted values against business rules before writing to the ERP via API, and flags any field with confidence below 0.92 for human review.

    F–H: Pilot, GDPR, HITL

    Fixed-Scope Pilot is a bounded engagement with a defined deliverable, a 2-week timeline, and a fixed fee. Forfis commits to auditing one workflow, building the automation, and delivering a measured before/after baseline within that window. No hourly billing; the client pays a single amount, and the contract converts to a rollout phase only if the success metric is met. GDPR (Regulation (EU) 2016/679) is the EU data-protection framework that, through its extraterritorial reach under Article 3(2), applies to any organization processing personal data of EU residents, including a UAE fintech serving European customers. Key obligations relevant to an AI triage system include Article 5 (lawful purpose, data minimization), Article 28 (processor agreements), and Article 30 (records of processing). The UAE Data Protection Law (Federal Decree-Law No. 45 of 2021) mirrors these provisions for domestic processing. Human-in-the-Loop (HITL) means a person reviews and approves AI-generated output before it takes effect. Forfis applies HITL by default: the model drafts a triage label or customer reply, but a support agent confirms it before the ticket is routed or the message is sent. This is non-negotiable for anything involving payments, disputes, or personal data.

    M–T: Model-Agnostic, On-Premise, Triage

    Model-Agnostic Architecture means the system can swap between different AI providers or models without rewriting application logic. Forfis abstracts the model call behind an internal interface, so the same triage pipeline can use OpenAI’s GPT-4o for high-accuracy classification on low-sensitivity tickets or a Llama 3 70B instance on the client’s hardware for data-residency compliance on high-sensitivity ones. The routing decision is made per ticket based on a data-classification tag. Open-Weight Models On-Premise refers to self-hosting AI models whose weights are publicly available (Llama 3, Mistral, Qwen) on the client’s own servers or a private cloud within the UAE. This ensures that cardholder data, account numbers, and customer names never cross a network boundary to a third-party API. Forfis deploys these models when the client’s data-classification policy prohibits sending regulated records externally, and the inference latency target is 18 ms per token on an A100 GPU. Ticket Triage and Routing is the first step in customer support: classifying an incoming inquiry by intent, urgency, and required skill set, then routing it to the correct queue or agent. Forfis builds a conversational agent that reads the ticket, assigns a category and priority score, and pushes the enriched record into the helpdesk via REST API. A human reviews any ticket flagged as high-risk before it reaches a customer.

    C–S: Integration, Rollout, Scaling

    Custom REST API and Webhooks is the integration pattern Forfis uses to connect to the client’s existing helpdesk, CRM, and ERP through their native HTTP endpoints rather than replacing them. The AI agent reads tickets via the helpdesk’s REST API, writes enriched fields back, and triggers webhooks to notify downstream systems. No data migration or platform swap is required; the integration layer is a thin middleware service that Forfis builds and maintains. Compliance-Safe AI Rollout is a deployment sequence that satisfies data-protection, industry-regulatory, and internal governance requirements before the AI touches production data. Forfis sequences the rollout as: (1) data classification and DPA execution, (2) on-premise model deployment if required, (3) shadow-mode testing on 30 days of historical tickets, (4) HITL-enabled live operation, and (5) full automation only after error rates stabilize below the agreed threshold for two consecutive weeks. Scaling Across Departments means extending a proven AI workflow from one team (customer support) to others (back-office invoice processing, compliance monitoring) using the same architectural patterns. Forfis structures the pilot so that the integration layer, HITL workflow, and monitoring dashboard are reusable, reducing the cost and risk of the second and third deployments. Free Senior Staff from Routine Work is the business objective: by automating triage, first-response drafting, and data entry, senior support agents and operations managers are freed to handle escalations, process design, and customer relationships that require judgment and empathy.

  • How a 340-Person B2B SaaS Firm Cut Monthly Reporting from 14 Days to 36 Hours

    Background: A 340-Person B2B SaaS Firm in the Scaling Phase

    This case study is a composite drawn from patterns observed across multiple engagements. No named customer is represented. The company described here is a fictional but plausible B2B SaaS firm operating in the USA, with 340 employees, a Microsoft Dynamics 365 ERP, and a Zendesk helpdesk. It sells a project-management platform to mid-market logistics and manufacturing clients. The operations team of 28 people handles monthly reporting, ticket triage, and supply-chain coordination. The company is in the scaling phase: it has outgrown its manual processes but has not yet standardized AI tooling across departments.

    Challenge: 14-Day Reporting Cycles and Misrouted Tickets

    The operations director flagged two problems. First, the monthly operations report took 14 business days to compile. Analysts pulled data from Dynamics 365, cross-referenced it with Zendesk ticket logs, and assembled a 40-page deck by hand. Second, ticket triage was inconsistent: 22% of tickets were routed to the wrong queue, and first-response time averaged 4.2 hours. The company was also preparing for a GDPR audit because it processes EU customer data through its US-based infrastructure. The operations team had no dedicated data engineer and no internal AI capability. The deadline was tight: the next board review was in 11 weeks, and the director needed a measurable improvement in reporting cycle time before that meeting.

    Approach: Process Audit, pgvector Build, and a 12-Week Pilot

    The engagement followed a three-phase structure. Phase one, weeks one through four, was a process audit. The team mapped the monthly reporting workflow end-to-end, identified which data points came from Dynamics 365, which came from Zendesk, and which required manual judgment. They also audited the ticket triage process and measured the baseline: 4.2-hour first response, 22% misrouting rate. Phase two, weeks five through eight, was the build. The team embedded the company’s operations runbooks, policy documents, and historical reports into a pgvector table in PostgreSQL. They wired the assistant to Dynamics 365 through its REST API and to Zendesk through its webhook endpoints. The assistant was configured to draft the monthly report and propose ticket routing, with a human approval step before any output was finalized. Phase three, weeks nine through twelve, was the pilot run. The assistant handled the monthly report and ticket triage in parallel with the existing manual process, so the team could compare before/after metrics directly.

    Outcome: 36-Hour Reports and a 7% Misrouting Rate

    The pilot ran for four weeks, covering one full monthly reporting cycle and approximately 1,800 support tickets. The monthly report cycle time dropped from 14 business days to 36 hours. The assistant drafted 85% of the report content, and the analyst spent the remaining time verifying figures and adding narrative context. The error rate on the drafted report was 3.1%, compared to 6.8% in the manual baseline. For ticket triage, first-response time fell from 4.2 hours to 1.1 hours, and the misrouting rate dropped from 22% to 7%. The assistant proposed routing for 94% of tickets; a human approved or adjusted the remaining 6%. The GDPR audit found no violations in the assistant’s data handling, because PII was scrubbed from documents before embedding and all queries were logged. The company decided to extend the assistant to two additional departments in the following quarter.

    Lessons for Teams Scaling AI Across Departments

    • Start with the process audit, not the model. The audit revealed that 40% of the reporting delay was not data retrieval but manual reconciliation between two ERP modules. Automating the retrieval without fixing the reconciliation would have saved only two days. The audit also identified which data points required human judgment, which shaped the approval workflow.
    • pgvector is sufficient for most B2B SaaS corpora. The document corpus was 120,000 chunks. pgvector handled the similarity search in under 18 ms at p95 latency. A separate vector database would have added operational complexity without a measurable performance gain.
    • Human-in-the-loop is not optional for regulated data. The GDPR audit required that no automated decision touched a customer’s personal data without human review. The approval step was not a formality; it was a compliance requirement.
    • Measure the baseline before you build. The 4.2-hour first-response time and 22% misrouting rate were measured in week one, not assumed. Without that baseline, the pilot outcome would have been uninterpretable.
    • Managed operations matters after the pilot. The company did not have an internal ML engineer. The managed operations model, which included monthly embedding re-indexing and prompt tuning, was the difference between a working pilot and a system that degraded over time.

  • Ticket Triage Automation for UK E-commerce: A 3-Month Fixed-Scope Pilot

    The Problem: Senior Staff Buried in Routine Ticket Triage

    You run a 51-200 person e-commerce operation in the UK. Your support team handles 800 to 1,500 tickets per day across order status, delivery issues, returns, and product questions. Senior staff spend 40-60% of their time on routine triage: reading the ticket, classifying it, routing it to the right queue, and drafting a first response. This work is repetitive, error-prone, and it pulls your most experienced people away from the complex cases that actually need their judgment. The goal is not to replace your support team; it is to free senior staff from routine work so they can focus on escalations, customer retention, and process improvement. The constraint is GDPR: ticket data contains customer names, order numbers, and delivery addresses, so any automation must comply with UK GDPR and the Data Protection Act 2018. The delivery model is a fixed-scope pilot: one ticket category, one helpdesk, one ERP integration, 3 months, measured before/after baselines on cycle time and error rate.

    Prerequisites: What You Need Before Step 1

    Before you write a single line of integration code, you need five things in place. First, a documented list of your top 20 ticket categories with their current routing rules, SLA targets, and escalation paths. This list is your ground truth; without it, the model has no reference for what ‘correct’ routing looks like. Second, API access to your helpdesk (Zendesk, Freshdesk, or similar) and your SAP or Microsoft Dynamics ERP instance. You need read access to order data and write access to ticket status fields. Third, a named GDPR Data Protection Officer or privacy lead who can sign off on the Data Protection Impact Assessment (DPIA). Fourth, a fixed-scope pilot agreement that defines success metrics (cycle time reduction, error rate, cost per ticket), data handling boundaries, and a 3-month timeline. Fifth, a human-in-the-loop approval workflow in your helpdesk UI where agents can accept, edit, or reject the model’s routing suggestion. If any of these are missing, the pilot will stall in week 2 or 3, and you will not have the measured baselines needed to justify scaling.

    Step 1: Audit the Ticket Flow and Define the Baseline

    Run a 2-week process audit on your top 3 ticket categories. Export 500 historical tickets from your helpdesk, tag each one with its final routing destination, cycle time, and error rate (did it go to the wrong queue, get escalated unnecessarily, or take longer than the SLA?). This gives you a baseline: for example, ‘order status’ tickets average 14 minutes from receipt to first response, with a 7% error rate. The audit also reveals which categories are worth automating. If a category has a 90%+ routing accuracy already, the ROI on automation is low. If it has a 40% error rate and a 22-minute cycle time, it is a strong candidate. The output of this step is a one-page brief per category: current metrics, routing rules, and the target metrics for the pilot. This brief becomes the acceptance criteria for the fixed-scope pilot agreement.

    Step 2: Complete the GDPR DPIA and Data Processing Agreement

    Complete a Data Protection Impact Assessment (DPIA) before any ticket data flows through the OpenAI API. The DPIA must document the lawful basis for processing (typically legitimate interest under GDPR Article 6(1)(f)), the categories of personal data involved (names, order numbers, delivery addresses), the retention policy (delete or anonymise ticket payloads after the routing decision is logged), and the security measures (encryption in transit via TLS 1.3, access controls on the API keys). You must also ensure the OpenAI API is covered by a Data Processing Agreement (DPA) with UK Standard Contractual Clauses. If tickets contain health data (e.g., a customer reporting a product caused an injury), Article 9 applies and you need explicit consent or another specific exception. The DPIA is not a one-time document; it must be updated if you change the model, the data flow, or the retention policy. Your DPO signs off on the DPIA before the pilot goes live.

    Step 3: Build the Model-Agnostic Triage Layer

    Build the triage layer as a model-agnostic abstraction. The integration layer calls your helpdesk’s REST API to fetch new tickets, and your SAP or Dynamics ERP’s OData or SOAP endpoints to enrich the ticket with order data (order status, delivery ETA, return eligibility). The enriched ticket payload is sent to the model endpoint, which returns a classification (category, priority, routing destination) and a suggested first-response template. For the pilot, use OpenAI’s GPT-4o API because it requires no GPU infrastructure and provides high-accuracy classification. The model-agnostic design means the routing logic is decoupled from the model: if GDPR or client contracts later demand on-prem inference, you can swap the model endpoint to a locally hosted open-weight model (e.g., Llama 3 70B) without changing the integration layer. The output is written back to the helpdesk via the API, with the model’s confidence score logged for audit.

    Step 4: Integrate with Helpdesk and ERP via API

    Wire the triage layer into your helpdesk and ERP. The helpdesk integration uses the REST API to create a new ticket, update its status, and log the model’s routing decision. The ERP integration uses OData (for Dynamics) or the SAP Business Technology Platform API to fetch order data and update the ticket with order-specific context. The human-in-the-loop approval workflow is critical: the model’s output appears in the helpdesk UI as a suggestion, and a human agent must accept, edit, or reject it before the ticket is routed. For tickets touching money (refunds, chargebacks), health data, or contract terms, the human approval is mandatory and the model’s output is treated as a suggestion only. The approval log feeds back into the model’s prompt engineering in the next sprint, so the system improves over time. This is not a limitation; it is the compliance mechanism that keeps the system within GDPR and internal audit boundaries.

    Step 5: Run the 8-Week Pilot in Three Phases

    Run the pilot in three phases. Phase 1 (weeks 1-2): shadow mode. The model classifies and routes, but a human approves every action. You measure the model’s accuracy against the human-approved outcomes. Phase 2 (weeks 3-6): semi-automated mode. The model handles low-risk categories (e.g., ‘where is my order’, ‘change delivery address’) and escalates the rest to a human. You measure cycle time and error rate for the automated categories. Phase 3 (weeks 7-8): full automation for approved categories with a 5% random sample still routed to a human for quality checks. The pilot ends with a measured before/after report: cycle time reduction (e.g., from 14 minutes to 3 minutes), error rate (e.g., from 7% to 2%), and cost per ticket (e.g., from £4.20 to £2.10). This report becomes the business case for scaling to other departments and ticket categories.