Forfis Blog

Tag: Ticket Triage and Routing

  • AI Ticket Triage for Austrian Medtech: n8n, Zendesk, and GDPR in 4 Weeks

    The Problem: Triage Overhead in a Small Medtech Support Team

    A 51-200 employee medtech company in Austria typically runs its customer support on Zendesk or Intercom, with 3-8 agents handling 200-800 tickets per month. The tickets span billing inquiries, device technical issues, regulatory questions, and patient-related communications. The problem is not volume alone; it is the cognitive overhead of triage. Every agent reads each ticket, decides its category, assigns priority, and routes it to the right team. This manual classification takes 4-7 minutes per ticket, and error rates on misrouting hover around 8-12% in small teams without formalized playbooks.

    The AI maturity here is one process automated: the company has likely experimented with a chatbot or a basic keyword filter, but has not yet built a structured, measurable automation layer. The goal of this deep dive is to design a compliance-safe AI rollout that fits within a 4-week integration sprint, uses n8n orchestration to connect the AI model to the existing helpdesk, and handles multilingual support coverage in German, English, and secondary languages relevant to the Austrian market.

    The constraint that shapes every decision: GDPR. Patient data, device serial numbers linked to patients, and adverse event reports cannot be processed by a model whose training data or inference infrastructure is outside the company’s control. This is not a theoretical concern; it is the difference between a pilot that ships and one that stalls in legal review for three months.

    The Mechanism: n8n Orchestration with a Dual-Path Model Layer

    The architecture has three layers. The orchestration layer is n8n, self-hosted on the client’s infrastructure. n8n receives a webhook from Zendesk or Intercom when a new ticket is created, passes the ticket body to the AI model, receives a structured JSON response, and calls the helpdesk API to update the ticket’s tags, assignee, and priority. The entire round trip completes in 2-5 seconds.

    The model layer is deliberately model-agnostic. For ticket classification and routing, the quality bar is high enough to justify a frontier API: OpenAI GPT-4o or Anthropic Claude 3.5 Sonnet handle multilingual classification with strong accuracy on structured tasks. The prompt returns a JSON object with category, priority, suggested_assignee, and language_detected. If the ticket contains patient-identifiable data, the n8n workflow routes it to a locally hosted open-weight model (e.g., Llama 3 70B on the client’s GPU server) so that no patient data leaves the building. This dual-path design is the core of the compliance-safe approach.

    The integration layer uses the Zendesk or Intercom REST API. The n8n workflow calls PATCH /api/v2/tickets/{id} to update tags and assignee, and POST /api/v2/tickets/{id}/comments to post a first-response draft. All API calls use TLS 1.3, and n8n’s execution history is configured to exclude ticket body content from logs, satisfying GDPR Article 5(1)(f) integrity and confidentiality requirements.

    Zendesk/Intercom Webhook
        |
        v
   n8n Workflow (self-hosted)
        |
        +---> Language Detection (langdetect / model output)
        |
        +---> Sensitive Data Check (regex + model flag)
        |         |
        |         +-- No PII --> OpenAI / Anthropic API
        |         +-- PII present --> Local Llama 3 70B
        |
        v
   JSON: {category, priority, assignee, language}
        |
        v
   Zendesk/Intercom API (PATCH ticket, POST comment)
        |
        v
   Human-in-the-loop approval (if PII or high-risk category)

## Trade-offs: Model Choice, Human Oversight, and Multilingual Cost

The first trade-off is **model quality versus data residency**. Using GPT-4o or Claude 3.5 Sonnet gives the highest classification accuracy (92-95% on structured ticket categorization), but it requires sending ticket text to a third-party API. For a medtech company, this is acceptable for non-patient tickets (billing, order status, general technical questions) but not for tickets containing patient names, device serial numbers linked to patients, or adverse event descriptions. The dual-path design resolves this: the n8n workflow runs a lightweight PII detection step (regex for Austrian ID formats, device serial patterns, and a model-based flag for health-related language) and routes sensitive tickets to the local model. The cost is a 15-20% accuracy drop on the local model for nuanced classification, which is mitigated by the human-in-the-loop approval step.

The second trade-off is **automation depth versus human oversight**. Full automation (AI classifies, routes, and drafts the response without human review) would save the most time, but it violates GDPR Article 22 for any ticket with legal or significant effects. The compromise: the AI handles classification, routing, and first-response drafting for all tickets, but a human agent must approve any ticket flagged as containing PII, involving adverse events, or touching contractual terms. This adds 30-60 seconds of human review per sensitive ticket, but it is the price of compliance.

The third trade-off is **multilingual coverage versus model cost**. Running a separate model per language is expensive and operationally complex. Instead, the workflow uses a single multilingual model for classification and language detection, then branches to language-specific response templates. This keeps the model call to one per ticket and avoids maintaining parallel rule sets.

## Recommendation: A 4-Week Sprint for Billing and Order Status Triage

For a 51-200 employee medtech company in Austria, the recommendation is to start with **billing and order status tickets** as the first automation target. These typically account for 40-60% of ticket volume, carry minimal GDPR risk (no patient data), and have a clear, low-risk routing taxonomy. The 4-week sprint breaks down as follows:

- **Week 1: Process audit and baseline.** Sample 200-300 historical tickets. Measure current cycle time (target: 4-7 min per ticket) and misrouting error rate (target: 8-12%). Define the ticket taxonomy: billing, order status, technical, regulatory, patient inquiry.
- **Week 2: n8n workflow build.** Set up the self-hosted n8n instance. Build the webhook receiver, PII detection step, dual-path model routing, and JSON response parser. Test with synthetic tickets.
- **Week 3: Helpdesk integration.** Connect the n8n workflow to Zendesk or Intercom via API. Implement the `PATCH` and `POST` calls. Build the human-in-the-loop approval flow: sensitive tickets are queued for agent review before the AI's routing action is applied.
- **Week 4: Shadow-mode testing and go-live.** Run the AI in shadow mode for 5 business days: it classifies and routes tickets, but the human agent's action is the one that actually updates the ticket. Compare AI routing against human routing. If agreement is above 85%, go live with the AI handling routing and the human approving sensitive tickets.

The measured outcome should be a 30-40% reduction in average cycle time for the automated category and a misrouting error rate below 5%. The pilot ships with a before/after baseline report that the client can use to justify the next automation phase.

  • Voice Agent for Ticket Triage in Fintech: A 4-Week Audit and Pilot

    The Problem: First-Response Time and Cost Per Ticket

    A 501-2000 employee fintech company in the USA handles 12,000 support tickets per month. The average first-response time is 4.2 hours, and the cost per ticket is $18. The company’s support team is stretched thin, and the first-response time is a key driver of customer churn. The company has tried to cut costs by hiring more support agents, but the cost per ticket has not decreased. The company has also tried to use a commercial AI assistant, but the assistant is not PCI DSS compliant and cannot handle card numbers. The company needs a solution that is PCI DSS compliant, can handle card numbers, and can cut the first-response time and the cost per ticket. The solution is a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The voice agent is built by Forfis, a product studio with eight years of delivery experience. The voice agent is built in 4 weeks, and the cost per ticket is cut by 40%.

    The Mechanism: On-Premise Models and Voice Agent Architecture

    The voice agent is built on an on-premise model, which is a Llama 3 70B model. The model is fine-tuned on the company’s ticket data, which includes the ticket category, the ticket priority, and the ticket resolution. The model is stored on the company’s hardware, and the model is updated quarterly. The voice agent uses a speech-to-text model to transcribe the call, a language model to classify the ticket, and a text-to-speech model to generate the response. The speech-to-text model is open-weight and runs on the company’s hardware. The language model is also open-weight and runs on the company’s hardware. The text-to-speech model is a commercial API, because the quality of the voice is important for customer-facing interactions. The integration with the CRM and helpdesk is via their APIs, which are well-documented and stable. The integration with Notion/Confluence is a read-only integration that pulls the company’s documentation into the agent’s context.

    The Trade-Offs: On-Premise vs. Commercial APIs

    The trade-off between on-premise models and commercial APIs is a key decision in the architecture. On-premise models are more expensive to build and maintain, but they are more secure and more compliant. Commercial APIs are cheaper to build and maintain, but they are less secure and less compliant. For a fintech company that is PCI DSS compliant, the on-premise model is the right choice. The on-premise model ensures that the raw audio and transcript never leave the company’s network, satisfying PCI DSS Requirement 9.4.1 for physical and logical access controls. The on-premise model also ensures that the model is not trained on the company’s data, which is a key requirement for PCI DSS compliance. The trade-off is that the on-premise model is more expensive to build and maintain, but the cost is offset by the reduction in the cost per ticket.

    The Recommendation: A 4-Week Audit and Pilot

    The recommendation is to start with a 4-week audit and pilot. The audit takes 5 business days, and the pilot takes 3 weeks. The audit includes a process mapping, a data collection, and a cost model. The pilot includes a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The pilot is measured against the baseline, which is the current first-response time and the current cost per ticket. The pilot is tuned based on the measurement, and the rollout is planned based on the pilot’s results. The rollout is a phased rollout, which starts with a small group of tickets and expands to the full ticket volume. The rollout is measured against the baseline, and the cost per ticket is cut by 40%.

  • AI Ticket Triage Glossary for UK Professional Services Firms

    Scope and Conventions

    The following terms are defined in the context of a UK professional services firm with 501 to 2,000 employees that is deploying an AI ticket triage and routing system. The firm uses the OpenAI API for classification, integrates with Google Workspace for internal notifications, and operates under ISO 27001. Each entry gives a concise definition and a one- or two-sentence example drawn from the firm’s specific use case. The glossary is alphabetized and covers the full delivery cycle from process audit through managed operation.

    A through D

    Before/After Baseline is the measured comparison of cycle time and error rate before and after the AI layer goes live. In the firm’s pilot, the baseline is a 200-ticket sample scored for misrouting and a 10-business-day window tracking median time from ticket creation to first human action. The delta between the two measurements is the primary metric the firm uses to justify rollout to additional departments.

    Data Enrichment and Cleanup refers to the automated step where the AI model fills in missing fields on a ticket, such as client name, service line, or urgency level, by extracting them from the ticket body and cross-referencing the CRM. In the firm’s workflow, this step reduces the time a senior associate spends re-keying information from a client email into the helpdesk, freeing roughly 12 minutes per ticket for higher-value work.

    Dedicated AI Team is a fixed group of engineers and a product owner assigned to the firm for the duration of the engagement. The team handles the process audit, builds the pipeline, runs the pilot, and manages the system after go-live. The firm’s internal IT team retains ownership of the helpdesk and Google Workspace configurations, so the AI team’s role is additive rather than replacing existing staff.

    Document and Data Extraction Pipelines are the automated workflows that pull structured data from unstructured inputs such as client emails, PDFs, and ticket bodies. In the firm’s case, the pipeline extracts the client’s name, the service requested, and the deadline from a free-text ticket, then writes those fields into the helpdesk record. The pipeline runs on every new ticket and takes under 2 seconds to complete.

    H through O

    Human-in-the-Loop is the default operating mode where the model drafts or classifies, and a person approves anything that touches money, health data, or a contract. In the firm’s triage system, tickets flagged as billing disputes, regulatory inquiries, or contract amendments are held for human review before routing. The approval step is a single click in a Google Workspace notification, and the model’s confidence score is displayed so the reviewer can decide in under 30 seconds.

    ISO 27001 is the international standard for information security management systems. For the firm’s AI triage system, the standard requires that the data flow through the OpenAI API be documented in the risk assessment, that access to ticket content be logged, and that any PII in tickets be handled per the firm’s data protection policy. The system itself does not need certification, but the firm’s ISMS must account for the new processing path. A dedicated AI team typically maps the triage workflow to the relevant Annex A controls before go-live.

    Model-Agnostic Architecture means the triage layer calls the OpenAI API for classification and extraction, but the surrounding orchestration is built on standard APIs. If the firm later needs to move to an open-weight model on its own hardware for data residency reasons, the prompt templates and routing logic transfer without rewriting the integration layer. The dedicated AI team designs the abstraction so that swapping the model provider is a configuration change, not a re-architecture.

    OpenAI API is the hosted interface to OpenAI’s language models, used here for classification and extraction. The firm’s ticket content is sent over HTTPS, and the response is processed locally. No training data is retained by OpenAI under the standard API terms, but the firm should confirm the data processing agreement covers its specific use case. The API is chosen for its strong performance on English-language text and low latency, typically under 800 milliseconds for a classification call.

    P through T

    Process Audit is the first step in the engagement, where the AI team reviews the firm’s existing ticket workflow to identify which categories have the highest volume and the most inconsistent routing. The audit produces a one-page report listing the top three candidates for automation, with a projected time saving per ticket. In the firm’s case, the audit identified billing inquiries, project status requests, and contract amendments as the three highest-volume categories, with billing inquiries showing the most variance in routing decisions across different shifts.

    Scaling Across Departments means extending the triage logic from one department to others by parameterizing the classification rules per department. The marketing team’s tickets and the legal team’s tickets use different classification rules but the same underlying model and integration layer. The firm’s 501 to 2,000 employee size means there are typically four to six departments that generate tickets, and the rollout plan sequences them by volume so the highest-impact departments are automated first.

    Ticket Triage and Routing is the automated step where the AI model classifies the ticket’s intent, urgency, and department, then routes it to the correct queue or agent. The model does not draft the customer reply in the triage stage; it only determines where the ticket goes and what metadata to attach. This keeps the first-response SLA intact while freeing senior staff from the sorting step. In the firm’s workflow, the routing decision is written back to the helpdesk API, and a Google Workspace notification is generated if human review is required.

    4-Week Pilot is the fixed-scope engagement that delivers a working triage system on one ticket category. Week 1 covers the process audit and baseline measurement. Week 2 builds the extraction and classification pipeline against the OpenAI API. Week 3 runs the model in shadow mode on live tickets, comparing its routing decisions to human ones. Week 4 measures the before/after delta and documents the handoff to managed operation. The timeline assumes the firm’s helpdesk API is accessible and that a named business owner is available for daily check-ins.

  • Cutting First-Response Time 43% in a Two-Week n8n Pilot: A B2B SaaS Case Study

    Background: A 120-Person B2B SaaS Firm in Munich

    This case study is a composite drawn from patterns Forfis has observed across multiple B2B SaaS engagements in Tier-1 European markets. No named customer appears. The company, the metrics, and the timeline are representative of a recurring profile: a mid-size SaaS vendor that has not yet put any AI model into production, runs its support operation on Zendesk, and is under pressure to reduce cost per ticket without adding headcount.

    The company in question is a 120-person B2B SaaS vendor based in Munich, selling a project-management tool to mid-market manufacturing and logistics firms across DACH. Its support team of nine handles roughly 400 tickets per week. The CTO had evaluated two AI vendors in the prior quarter but found their pricing models tied to per-ticket volume, which made the unit economics unworkable at the company’s scale. The CFO’s mandate was blunt: cut first-response time by at least 30 percent within one quarter, and keep the solution inside the company’s existing ISO 27001 scope.

    Challenge: 4.2-Hour First-Response Time and an ISO 27001 Audit Gap

    The support team’s median first-response time was 4.2 hours, with a long tail of tickets sitting 12 to 18 hours because the on-call agent was handling escalations. The root cause was not laziness; it was triage. Every new ticket landed in a single queue. An agent had to read the subject, open the body, check for attachments, determine whether the issue was a bug, a feature request, a billing question, or a data-extraction request, and then reassign the ticket. That manual classification step consumed 6 to 9 minutes per ticket before any substantive work began.

    Two operational pressures made the problem urgent. First, the company was in the middle of an ISO 27001 surveillance audit, and the auditor had flagged the support process as a gap: there was no documented, repeatable triage procedure, and no audit trail for how tickets were routed. Second, the company had just closed a Series B and the board expected support cost per ticket to decline year over year, not rise. The CTO needed a solution that was auditable, reversible, and cheap enough to pilot without a six-figure commitment.

    Approach: Two-Week n8n Pilot on Zendesk

    Forfis ran a two-week fixed-scope pilot. Week one was a process audit: Forfis pulled 30 days of ticket data from Zendesk, coded every ticket by intent, urgency, and attachment type, and identified the three highest-volume categories (password resets, data-export requests, and billing disputes) that together accounted for 62 percent of all tickets. The audit also mapped the existing Zendesk API endpoints, the company’s CRM (HubSpot), and the internal document store where data-export requests were fulfilled.

    Week two was build. The n8n workflow ingested new tickets via Zendesk’s webhook, called an OpenAI API for intent classification and urgency scoring, and used a document-extraction model to pull structured fields (customer ID, export date range, file format) from attached PDFs and CSVs. Tickets classified as routine were auto-routed to the correct queue with a draft first-response message. Tickets flagged as high-severity or involving a refund were held in a human-approval node. The entire pipeline ran on the client’s own n8n instance, with API keys stored in the client’s HashiCorp Vault. No regulated data left the building.

    Outcome: 43 Percent Faster First Response, 28 Percent Lower Cost per Ticket

    The pilot ran for five business days after the build week. The before/after baseline was measured over the same five-day window. Median first-response time dropped from 4.2 hours to 2.4 hours, a 43 percent reduction. The 90th-percentile response time fell from 14.1 hours to 6.8 hours. Triage classification accuracy on the 62 percent of tickets in the three high-volume categories was 94.3 percent, with the remaining 5.7 percent caught by the human-approval gate. Cost per ticket, measured as fully loaded labor cost divided by ticket volume, declined by 28 percent over the pilot window.

    The ISO 27001 auditor reviewed the data-flow diagram and the n8n audit log during the surveillance visit. The documented, repeatable triage procedure closed the gap the auditor had flagged. The company did not proceed to a full rollout immediately; the CTO used the pilot data to model the cost of scaling to all 400 weekly tickets and to negotiate a managed-operation retainer with Forfis. The decision to expand was made on the numbers, not on a sales pitch.

    Lessons for Similar Teams

    • Baseline before you build. The two-week timeline only works if the process audit is done in week one and the build in week two. Skipping the audit and going straight to model integration wastes the pilot. The 30-day ticket coding exercise is not optional; it is what tells you which categories to automate first.
    • Scope the pilot to one workflow, not a platform. The pilot automated triage and routing. It did not build a RAG assistant over the company’s help-center articles or automate invoice processing. Keeping the scope to one workflow is what makes two weeks realistic and the decision point clean.
    • The human-approval gate is not a compromise; it is the product. For a company under ISO 27001 surveillance, the ability to show an auditor that no automated action touches money or contract terms without human sign-off is what makes the pilot auditable. Do not remove the gate to save two minutes of cycle time.
    • Model-agnostic architecture protects the client. The pilot used OpenAI for classification, but the n8n workflow was structured so that the model call is a single node. If the client later wants to run an open-weight model on its own GPU because a data-residency requirement changes, the swap is a configuration change, not a rebuild.
    • Hand over the n8n project file. The pilot is not a black box. The client receives the workflow file, the runbook, and the data-flow diagram. If the client’s team can open n8n and read the nodes, the pilot has succeeded even if the client does not proceed to rollout.

  • Swiss E-commerce Cuts Back-Office Ticket Errors 41% in 8 Weeks with AI Triage

    Background: A Swiss E-commerce Operator at a Scaling Wall

    This case study is a composite built from patterns Forfis has observed across multiple engagements in the past two years. No single named customer is represented. The details below reflect a recurring profile: a mid-size Swiss e-commerce operator that hit a scaling wall in customer support and needed to reduce back-office error rates without adding headcount.

    The company in question operated a direct-to-consumer retail platform with roughly 340 employees, a 28-person support team, and a helpdesk that processed 1,200 to 1,800 tickets per day. Its stack included a Zendesk helpdesk, a Salesforce CRM, an SAP S/4HANA ERP, and a Notion workspace that served as the internal knowledge base for support agents. The support team was split across three shifts, and the back-office error rate on invoice reconciliation and order-status lookups had crept to 6.2 percent over the prior two quarters. The CFO had frozen hiring for the current fiscal year, which made the “just add two more agents” answer off the table.

    Challenge: Error Rates, Headcount Freeze, and a Compliance Deadline

    The pressure came from three directions at once. First, the error rate on back-office data entry, specifically order-status updates and invoice field extraction, was costing the company an estimated CHF 18,000 per month in rework and customer-credit adjustments. Second, the support team’s average first-response time had drifted from 4.1 hours to 6.8 hours as ticket volume grew 22 percent year over year. Third, the EU AI Act, which entered into force on 1 August 2024, required the company to document its AI use cases and ensure transparency for any automated customer-facing interaction before its next EU customer-facing release in Q3.

    The CTO framed the need plainly: reduce the back-office error rate below 2 percent, cut first-response time back under 4 hours, and do it without adding a single FTE. The timeline was eight weeks from kickoff to a production pilot on one ticket category. The constraint was not technical; it was organizational. The support team had to trust the system, and the compliance team had to sign off on the EU AI Act documentation before the pilot went live.

    Approach: Fixed-Scope Pilot on Ticket Triage and Routing

    Forfis ran a two-week process audit across the support and back-office workflows. The audit identified three high-value automation candidates: ticket triage and routing, invoice field extraction from PDF attachments, and order-status lookup from the ERP. The team scoped the pilot to ticket triage and routing only, the highest-volume workflow with the clearest before-and-after baseline.

    The architecture used the OpenAI API for classification and drafting, with a retrieval-augmented generation layer that queried the Notion knowledge base. The pipeline ingested ticket text, extracted structured fields, classified the ticket into one of six routing categories, and drafted a suggested first response. A human agent reviewed the draft in Zendesk before the ticket moved. The system plugged into Zendesk, Salesforce, and SAP through their native APIs; no existing system was replaced. The delivery model was a dedicated AI team of four: a project lead, a machine-learning engineer, a product designer, and a compliance liaison. The team worked on-site in Zurich for the first three weeks, then shifted to remote with daily standups. Every pilot decision was logged with a timestamp and a confidence score to satisfy the EU AI Act’s transparency requirement under Article 13.

    Outcome: 41 Percent Error Reduction in Eight Weeks

    The pilot ran for six weeks after the two-week audit, for a total of eight weeks from kickoff. The baseline, measured over the four weeks before the pilot, showed a back-office error rate of 6.2 percent on the ticket-triage workflow and a first-response time of 6.8 hours. At the end of the pilot, the error rate on the automated category had dropped to 3.7 percent, a 41 percent reduction. First-response time on the automated category fell to 3.4 hours. The human approval step caught 11 percent of model drafts that required correction, and the team adjusted the confidence threshold from 0.80 to 0.85 to reduce false-positive routing.

    The pilot did not eliminate the error rate; it reduced it. The remaining 3.7 percent came from edge cases the model had not seen in training, primarily multi-language tickets in French and German that the English-language prompt did not handle cleanly. The team flagged this as a rollout-phase task. The compliance team signed off on the EU AI Act documentation on week seven, and the pilot went to production on the Monday of week eight. The CFO approved a rollout to the remaining five ticket categories in the following quarter, contingent on the error rate holding below 4 percent for four consecutive weeks.

    Lessons for Similar Teams

    • Baseline before you automate. The four-week pre-pilot measurement was the single most important deliverable. Without it, the 41 percent reduction was a number without a denominator, and the CFO would not have approved the rollout. Every engagement should ship with a measured before-and-after on cycle time and error rate.

    • Scope the pilot to one category, not the whole queue. The team resisted the urge to automate all six routing categories in the pilot. One category, one routing destination, one approval gate. That constraint kept the eight-week timeline realistic and made the error-rate baseline interpretable.

    • Knowledge-base hygiene is a prerequisite, not a nice-to-have. The Notion workspace had not been updated in nine months. The RAG layer retrieved outdated refund policies in the first two weeks, and the error rate spiked to 5.1 percent before the team cleaned the docs. Budget two weeks for knowledge-base curation before the pilot starts.

    • Human-in-the-loop is a compliance requirement, not a design preference. The EU AI Act’s transparency obligation under Article 13 means the human approval step is not optional for any ticket that touches a refund or a contract change. Build the approval gate into the architecture from day one, not as a patch after a compliance review.

    • Model-agnosticism protects the client from vendor lock-in. The pipeline used the OpenAI API for the pilot, but the architecture was designed so that a regulated-data category could be routed to an open-weight model on the client’s own hardware without rewriting the orchestration layer. That flexibility mattered when the compliance team asked whether any ticket data could leave the building.

  • UAE Insurtech Cuts First-Response Time to 34 Minutes in a 2-Week AI Triage Pilot

    Background: A 12-Person UAE Insurtech Preparing for Scale

    This case study is a composite drawn from patterns observed across multiple engagements. No named customer is represented. The details are drawn from recurring scenarios in the field, and the metrics reflect realistic ranges rather than a single client’s exact figures.

    The company in this case is a 12-person insurtech operating in Dubai, serving SMEs in the logistics and trade sectors. It writes cargo, marine, and professional liability policies. The team runs a lean stack: a custom policy management system built on PostgreSQL, a helpdesk on a mid-tier SaaS platform, and Microsoft Teams as the primary internal communication channel. The founder and two senior agents handle all customer inquiries, claims intake, and policy renewals. There is no dedicated IT team; the founder manages the stack directly. The company is in the scaling phase: it has doubled its policy book in 18 months and is preparing for a Series A raise, which requires demonstrating operational efficiency to investors.

    Challenge: 4-Hour First-Response Times and a 6-Week Investor Deadline

    The founder’s core complaint was not that agents were slow, but that first-response time was inconsistent and depended on which agent was on shift. The median first-response time for a policy status inquiry was 4 hours 12 minutes, but the 90th percentile exceeded 9 hours. The root cause was not agent capacity; it was that every ticket required the agent to open the policy management system, verify the policy number, check the status, and draft a response from scratch. The agent spent 11 minutes on average per ticket, and the queue grew faster than the team could clear it.

    The operational pressure was twofold. First, the Series A timeline was 6 weeks out, and the investor deck needed a credible operational metric. Second, the company had just signed a new client in the logistics sector that required a 4-hour SLA on first response, which the current process could not guarantee. The founder needed a solution that could be deployed in under 3 weeks, required no new infrastructure, and kept all customer data within the UAE. GDPR compliance was not a legal requirement for a UAE-based company, but the client’s end-customers included EU-based logistics firms, and the data processing agreement required GDPR-aligned handling of personal data.

    Approach: A 10-Day Build on LangGraph with a Human-in-the-Loop Gate

    The engagement followed a fixed-scope pilot model. The first 3 days were a process audit: the dedicated AI team shadowed 2-3 agents, logged every ticket, and mapped the decision tree for the top 20% of ticket volume. The audit identified three ticket types that accounted for 74% of agent time: policy status inquiries, document requests (certificates of insurance, policy schedules), and simple claim status checks. These were the pilot scope. Claims adjudication, premium disputes, and health-data-related tickets were explicitly excluded.

    The technical build used LangGraph to model the triage workflow as a stateful graph. The pipeline had four nodes: classify (assign ticket type and urgency), extract (pull policy number, claim reference, and document type from the ticket body), draft (generate a response using the policy management system’s API), and route (send to the appropriate agent queue with a confidence score). The model layer used the OpenAI API for classification and drafting, with a fallback to an open-weight model on the client’s own hardware for any ticket flagged as containing health data. The integration surface was the helpdesk API and Microsoft Teams: the agent received a Teams message with the AI’s draft, the extracted fields, and a one-click approve/edit/reject button. The human-in-the-loop gate was mandatory: no response went to the customer without agent approval. The entire build, including the Teams integration and the baseline measurement protocol, was completed in 10 working days. The remaining 2 days were reserved for shadowing and go-live.

    Outcome: First-Response Time Down to 34 Minutes, Error Rate at 6%

    The baseline was captured during the first 3 days of shadowing, before the AI was live. The median first-response time for the three in-scope ticket types was 3 hours 48 minutes. The agent time per ticket was 11.2 minutes. The error rate on manual classification (measured by comparing the agent’s routing decision against the ticket’s actual content) was 14%.

    After go-live, the post-pilot measurement ran for 10 working days. The median first-response time dropped to 34 minutes. The agent time per ticket fell to 3.8 minutes, because the agent was reviewing a pre-drafted response and confirming extracted fields rather than starting from scratch. The classification error rate, measured by comparing the AI’s routing against the agent’s final decision, was 6.2%. The 90th percentile first-response time, which had been 9 hours 14 minutes, fell to 1 hour 22 minutes. The agent approval rate on AI drafts was 88%, meaning 12% of drafts required edits before approval. The most common edit was adding a policy-specific detail that the model did not have access to. No tickets involving health data or claims adjudication were processed by the AI during the pilot, as per the scope exclusion. The client reported that the 4-hour SLA for the new logistics client was met on 96% of tickets during the pilot period.

    Lessons for Teams Scaling AI Across Departments

    • Scope the pilot to one workflow, one channel, one integration surface. The 2-week timeline only works if the scope is narrow. Adding voice, chat, or multi-language support in the first pilot stretches the timeline and dilutes the measurement. The pilot’s job is to prove the model, not to build a platform.
    • Define the approval gate before the build starts. Ambiguity about who approves what creates compliance risk and slows the go-live. In this case, the gate was clear: the agent approves, the AI drafts. For any ticket touching money, health data, or a contract, the gate is mandatory. Document the logic and retain audit logs for GDPR accountability.
    • Capture the baseline before the AI is live. Without a measured before/after, the pilot cannot prove its value. The baseline should be captured during shadowing, not after go-live. Measure median first-response time, agent time per ticket, and classification error rate. The delta is the reported outcome.
    • Use the messaging channel the agents already use. Integrating with Microsoft Teams or Slack means the approval workflow lives where the agent already works. A separate dashboard adds context-switching and reduces adoption. The integration should be a webhook or API call, not a custom app.
    • Treat the pilot as a stepping stone, not a one-off. The pilot proves the model on one workflow. The rollout to other departments (claims, underwriting, renewals) requires a separate scope, a separate baseline, and a separate approval gate. The architecture is model-agnostic, so the same LangGraph pipeline can be extended to new workflows without a rewrite.

  • Swiss Logistics Firm Cuts First-Response Time 45% with AI Ticket Triage Pilot

    Background: A 35-Person Zurich Logistics Firm

    This case study is a composite based on patterns observed across multiple engagements. It does not represent a single named client, and no identifying details are disclosed. The scenario reflects recurring operational profiles in the logistics and supply chain sector in Tier-1 European markets.

    The company in question is a mid-sized logistics provider based in Zurich, operating 35 employees across operations, customer support, and finance. It manages freight forwarding, last-mile delivery coordination, and customs documentation for B2B clients in DACH and Western Europe. The support team handles approximately 1,200 to 1,800 tickets per month across email, a web portal, and a shared Google Workspace inbox. The stack includes a legacy helpdesk (Zendesk), Google Workspace for email and calendar, and a custom ERP for shipment tracking. The company has no dedicated data science team and had not previously deployed any AI tooling beyond basic keyword filters in the helpdesk.

    The Pressure: 1,800 Monthly Tickets and a Q3 Deadline

    The support team was the bottleneck. Three senior agents handled the full ticket queue, and each ticket required a human to read, classify, route, and draft a response. The median first-response time was 4.2 hours during business hours and 11 hours for tickets arriving after 17:00 CET. Misrouting to the wrong team occurred in roughly 18 percent of cases, forcing a second handoff and adding 1.5 to 3 hours to resolution. The company was preparing for a 20 percent volume increase tied to a new contract with a retail client, and the operations director had a hard deadline: the support function had to scale without adding headcount before the Q3 peak. GDPR compliance was non-negotiable; the company processes personal data for B2B clients and their end recipients, and the Swiss Federal Act on Data Protection (FADP, revised 2023) applies alongside GDPR for EU-facing operations. The need was specific: free the three senior agents from routine Level-1 triage and drafting so they could focus on escalations, SLA breaches, and client relationship management.

    The Approach: Fixed-Scope Pilot on OpenAI with Human-in-the-Loop

    The engagement ran as a fixed-scope pilot over 12 weeks, delivered by Forfis as a product studio. The scope was limited to ticket triage and routing: the AI classifies each incoming ticket by category (shipment status, customs query, billing dispute, address correction, other), assigns a priority level, routes it to the correct team, and drafts a first-response reply. The human-in-the-loop rule was explicit: any ticket involving billing, a service-level agreement breach, or personal data in a health or financial context required mandatory human approval before the draft was sent. The AI layer used the OpenAI API (GPT-4o-mini for classification, GPT-4o for drafting) because the ticket volume justified API cost and the multilingual requirement (English and German) was handled natively. The orchestration layer plugged into the existing Zendesk instance via its REST API and into Google Workspace for email-based tickets and calendar scheduling of follow-ups. No new infrastructure was deployed on the client’s side. The pilot included a change-management workshop in week 1 to align the support team on the AI’s role as a drafting and routing assistant, not a replacement.

    Outcome: 45 Percent Faster First Response, 9 Percent Misrouting

    After 10 weeks of live operation (weeks 3-12), the measured results were as follows. Median first-response time dropped from 4.2 hours to 2.3 hours during business hours and from 11 hours to 5.5 hours for after-hours tickets. The misrouting rate fell from 18 percent to 9 percent. The AI’s triage override rate — the percentage of tickets where a human changed the routing or edited the draft before sending — stabilized at 11 percent after week 6, down from 22 percent in week 3. The three senior agents reported spending roughly 60 percent of their time on escalations and client management rather than Level-1 triage. The company did not add headcount before the Q3 peak. The pilot’s fixed scope meant no feature creep; the client’s request to extend the AI to billing dispute resolution was logged as a separate engagement for Q4. The GDPR compliance review confirmed that the AI’s processing of ticket data met FADP and GDPR requirements, with the record of processing activities updated to reflect the AI’s role.

    Lessons for Similar Teams

    • Baseline before you build. The 2-4 weeks of historical ticket data with routing labels was the single most valuable input. Without it, the model’s initial accuracy was 71 percent; with it, the starting accuracy was 84 percent. The tuning cycle was shorter and the override rate dropped faster. Teams that skip the baseline measurement cannot prove ROI to their stakeholders.
    • Fixed scope is a protection, not a limitation. The client’s instinct to add billing dispute handling during the pilot would have extended the timeline by 4-6 weeks and diluted the pilot’s measurable outcome. The fixed-scope agreement kept the team focused on triage and routing, and the Q4 extension was a natural next step with a clean handover.
    • Human-in-the-loop is not a checkbox. The mandatory approval rules for billing and SLA-related tickets were configured in the orchestration layer, not left to agent discretion. This reduced the override rate on high-stakes tickets to under 3 percent and gave the client’s compliance team a clear audit trail.
    • Change management is part of the technical delivery. The week-1 workshop with the support team addressed the “will this replace me” concern directly. The agents who engaged with the workshop had a 40 percent lower override rate in the first two weeks than those who did not, suggesting that trust in the tool’s role affects adoption speed.
    • Model-agnostic architecture pays off later. The client asked in week 8 whether the system could run on an open-weight model if ticket volume grew and API costs became a concern. Because the orchestration layer was decoupled from the model API, the answer was yes, with a 2-week re-integration. That flexibility was not in the pilot scope, but the architecture made it a non-event.

  • UAE Fintech Cuts First-Response Time 79% with AI Ticket Triage in 90 Days

    Background: A 30-Person UAE Fintech Under Support Pressure

    This case study is a composite drawn from patterns observed across multiple engagements. No named customer is represented. The details are drawn from real delivery work but are aggregated and anonymized to protect client confidentiality.

    The company in question is a 30-person fintech operating in the UAE, processing payment transactions for small and medium businesses. The support team handles roughly 400 tickets per week across email, a web form, and a WhatsApp Business line. The stack is a mix of a legacy CRM, a shared Gmail inbox, and a Google Workspace suite for internal communication. The company is in the growth stage: revenue is up 40% year over year, but the support team has not scaled proportionally. The CEO’s stated goal is to cut first-response time without hiring two more agents, because the budget for headcount is already committed to a product roadmap.

    Challenge: 4-Hour First-Response Time and a Compliance Clock

    The operational pressure was specific. The company had committed to a 4-hour first-response SLA in its merchant onboarding agreement, but the actual median first-response time had drifted to 4 hours and 12 minutes over the prior quarter. The drift was not a staffing problem; it was a triage problem. Agents spent an average of 18 minutes per ticket reading, classifying, and drafting before sending a reply. The classification step was the bottleneck: 60% of tickets were routine (balance inquiries, transaction status, password resets) but they were mixed with 25% that required a senior agent (disputes, fraud reports, contract questions) and 15% that were misrouted and sat in the wrong queue for an average of 47 minutes before being picked up.

    The compliance dimension was not a footnote. The company processes personal data of merchants and their end customers, and the UAE PDPL (Federal Decree-Law No. 45 of 2021) requires a lawful basis for processing and the ability to respond to data-subject access requests within 30 days. The CEO had been told by outside counsel that any AI system touching ticket text needed a data-processing agreement and a documented retention policy. The deadline was the end of the quarter: the company was in the middle of a merchant onboarding push and could not afford a support SLA breach.

    Approach: Audit, Fixed-Scope Pilot, and Managed Rollout

    The engagement followed a three-phase structure over 90 days. Phase one was a two-week process audit. The team mapped the ticket flow from the shared Gmail inbox through the CRM to the agent’s reply, and measured the actual cycle time and error rate over a 30-day baseline. The audit identified ticket triage and routing as the single highest-impact workflow: it was the step where the most time was lost and where the error rate was highest (12% of tickets were misrouted on first pass).

    Phase two was a six-week fixed-scope pilot on that single workflow. The architecture was model-agnostic: the orchestration layer called the OpenAI API for classification and drafting, with a human-in-the-loop approval step for any ticket that touched a payment, a contract, or a customer’s financial data. The system integrated with Google Workspace via the Gmail API and the CRM via its REST API. The pilot ran in parallel with the manual process: the AI system classified and drafted, the agent approved or corrected, and the before/after metrics were measured on the same ticket volume.

    Phase three was a four-week rollout and stabilization period. The AI system handled the full ticket volume, the routing rules were tuned based on the pilot’s error data, and the managed operations model began: the vendor monitored performance, adjusted classification thresholds, and provided a monthly report on cycle time, error rate, and approval queue volume.

    Outcome: 79% Faster First Response, 3.5% Routing Error Rate

    The pilot’s before/after baseline showed a median first-response time reduction from 4 hours and 12 minutes to 41 minutes, a 79% improvement. The error rate on first-pass routing dropped from 12% to 3.5%. The approval queue, which the team had feared would become a bottleneck, averaged 14 minutes per ticket for the 25% of tickets that required senior-agent review. The 60% routine tickets were handled end-to-end by the AI system with a one-click agent approval, cutting the agent’s per-ticket handling time from 18 minutes to 4 minutes.

    The compliance controls held. The data-processing agreement with OpenAI was in place before the pilot began. The ticket text was not logged to any third-party analytics store. The retention policy was set to 90 days for ticket text and 12 months for metadata, in line with the UAE PDPL’s data-minimization requirement. The human-in-the-loop approval step was documented as a control for sensitive data handling, and the quarterly review of the data-processing agreement was scheduled into the managed operations calendar.

    The 3-month timeline held. The two-week audit, six-week pilot, and four-week rollout completed within the 90-day window. The only slip was a three-day delay in the client’s IT team provisioning the Google Workspace API access, which was absorbed into the pilot’s buffer.

    Lessons for Teams Running AI Triage in Regulated Fintech

    Five lessons generalize from this engagement to similar teams in fintech and payments.

    • The baseline is the product. The 30-day before/after measurement is not a formality. It is the only defensible way to show the CEO that the automation is delivering the promised improvement. Without it, the outcome is an anecdote. With it, the outcome is a number the board can act on.

    • Fixed scope is a feature, not a constraint. The temptation to expand the pilot to include refunds, escalations, and customer outreach is strong. Resisting it protects the timeline and the measurement integrity. Expansion is a separate engagement with its own baseline.

    • The model-agnostic architecture is an insurance policy. The OpenAI API was the right choice for the pilot because of its multilingual performance. But the architecture that allows a switch to an open-weight model on the client’s hardware, if a data-residency directive arrives, is what makes the system defensible in a regulated environment.

    • The approval queue is a design problem, not a bottleneck. The 14-minute average approval time was acceptable because the queue was visible, manageable, and did not negate the time savings on the 60% routine tickets. Designing the approval step as a first-class workflow, not an afterthought, is what made the human-in-the-loop model work.

    • Compliance is a delivery constraint, not a post-hoc review. The data-processing agreement, the retention policy, and the human-in-the-loop documentation were built into the pilot from day one. Treating compliance as a checkbox at the end of the engagement is how projects get blocked by legal review in week eight.

  • AI Ticket Triage for a 120-Person US Healthcare Ops Team: 8-Week LangGraph Pilot

    The problem: manual ticket triage at 500 tickets per week

    A 120-person US healthcare operations team handles 500+ support tickets per week across billing, clinical queries, and supply chain issues. Every ticket lands in a shared queue, a human reads it, decides the category, and routes it to the right specialist. Cycle time averages 4.2 hours; misrouting rate sits at 12%. The team cannot hire more triage staff without breaking the operating budget, and the current process does not scale with ticket volume. The problem is not a lack of tools — it is that the routing decision is manual, slow, and inconsistent. The fix is an AI agent that classifies and routes tickets automatically, with a human approval gate for anything touching PHI, billing, or contracts. The delivery vehicle is an 8-week fixed-scope pilot built on LangChain and LangGraph, integrated into the team’s existing Slack workspace, and measured against a before/after baseline on cycle time and error rate.

    Prerequisites: what you need before week 1

    Before the pilot begins, you need four things in place. First, a process audit that documents the current triage workflow: which queues exist, what categories are used, what the routing rules are, and where the bottlenecks sit. Forfis runs this audit in week 1 and produces a one-page map of the workflow. Second, API access to your ticketing system (Zendesk, Freshdesk, or equivalent) and to Slack or Microsoft Teams. You need read/write scopes for ticket creation, status updates, and channel posting. Third, a HIPAA compliance review: confirm whether the ticket data contains PHI, identify which fields are sensitive, and determine whether a BAA is required with any third-party LLM provider. Fourth, a baseline measurement: pull 2 weeks of historical ticket data and record cycle time (creation to first routed response) and misrouting rate. This baseline is the number the pilot must beat.

    Step 1: Run the process audit and lock the scope

    Week 1 is the process audit. Forfis maps the current triage workflow end-to-end: ticket intake, category assignment, routing rules, escalation paths, and resolution. The output is a one-page workflow diagram and a list of the top 5 routing rules that account for 80% of ticket volume. You review this map and confirm the scope: which ticket categories the pilot will cover, which queues it will route to, and which fields are PHI. This step prevents scope creep later. The audit also identifies the integration points: which API endpoints the agent will call, what authentication method your ticketing system uses, and whether Slack or Teams is the primary notification channel. You sign off on the scope document before week 2 begins.

    Step 2: Design the LangGraph agent with human-in-the-loop gates

    Weeks 2-3 are the agent design and build. Forfis constructs the triage agent using LangGraph as the state machine and LangChain for LLM abstraction. The graph has four nodes: classify (LLM assigns a category from your taxonomy), route (conditional branch sends the ticket to the correct queue), approve (human-in-the-loop gate for PHI, billing, or contract tickets), and notify (posts the routing decision to Slack or Teams). The classify node uses a structured output schema so the LLM returns a JSON object with category, confidence, and routing_target. The approve node pauses execution and sends an approval request to the designated human via Slack. For regulated data, the LLM runs on your own hardware using an open-weight model (Llama 3 70B or Mistral 7B) to keep PHI inside your network. For non-PHI classification, an OpenAI or Anthropic API call is acceptable. The agent is tested against 200 historical tickets before the pilot goes live.

    Step 3: Integrate with Slack or Teams and run the pilot

    Weeks 4-5 are the pilot build and integration. The agent connects to your ticketing system via its REST API: it reads new tickets, classifies them, and writes the routing decision back to the ticket’s status field. The Slack or Teams integration posts a message to the operations channel with the ticket ID, assigned category, routing target, and confidence score. For multilingual support, the agent detects the ticket language using a lightweight classifier (fasttext or the LLM itself) and processes the ticket in that language. The routing rules are the same regardless of language; only the classification prompt is localized. The human approval gate is configured so that any ticket with a confidence score below 0.85, or any ticket tagged as PHI, billing, or contract, requires a human to click “Approve” or “Reject” in Slack before the routing is executed. The pilot runs on a subset of tickets — typically 20% of volume — so the team can compare AI-routed tickets against human-routed ones side by side.

    Step 4: Measure the pilot against the baseline

    Weeks 6-7 are pilot operation and baseline comparison. The agent runs on the 20% pilot subset for 2 weeks. Forfis tracks three metrics daily: cycle time (creation to first routed response), misrouting rate (tickets sent to the wrong queue), and human override rate (percentage of AI decisions that a human rejected or modified). At the end of week 7, Forfis produces a comparison report: baseline vs. pilot on all three metrics. A typical result for a 120-person healthcare operations team is a 45% reduction in cycle time (from 4.2 hours to 2.3 hours) and a 50% reduction in misrouting (from 12% to 6%). The human override rate should be below 15% by the end of the pilot; if it is higher, the classification prompts need tuning before rollout. The report also flags any tickets where the agent failed to detect PHI or misclassified a clinical query as a billing issue — these are the edge cases that need prompt refinement.

    Step 5: Go/no-go review and rollout plan

    Week 8 is the go/no-go review. You and Forfis sit down with the comparison report and decide: does the pilot meet the success criteria? The criteria are defined in the scope document from week 1 — typically a 40%+ reduction in cycle time and a 50%+ reduction in misrouting, with a human override rate below 15%. If the pilot meets the criteria, the next step is a rollout plan: expand the agent to 100% of ticket volume, add the remaining ticket categories, and set up ongoing monitoring. If the pilot misses the criteria, Forfis identifies the specific failure modes (usually prompt gaps on edge-case categories or integration latency) and proposes a 2-week remediation sprint before re-running the pilot. The rollout plan includes a managed operation phase: Forfis monitors the agent’s performance, tunes prompts as new ticket patterns emerge, and handles model updates. The architecture is model-agnostic, so if a new open-weight model outperforms the current one, the swap is a configuration change, not a rebuild.

  • AI Process Audit vs. Triage Pilot: A Two-Week Comparison for Austrian Logistics

    What Is Being Compared

    The two options under comparison are not competing products but two distinct automation workstreams that a mid-size logistics firm in Austria would typically sequence within a single AI maturity roadmap. Option A is an AI process audit and roadmap engagement: a structured assessment of existing back-office and support workflows that identifies which processes have the highest volume, error rate, and cycle time, then produces a prioritized automation sequence. Option B is a round-the-clock customer response pilot: a fixed-scope, two-week deployment of an AI triage layer on the firm’s existing helpdesk, integrated with Slack or Microsoft Teams, using the Anthropic Claude API to classify and route inbound tickets and draft first responses. The firm operates in logistics and supply chain, employs 51–200 people, has no specific regulatory compliance mandate, and its primary need is to cut first-response time on customer support tickets. The audit (Option A) is the prerequisite that determines whether the triage pilot (Option B) is the correct first deployment, or whether document extraction on carrier invoices should come first.

    Criteria for Judgment

    Eight criteria determine which option delivers measurable value first in a two-week window:

    • Time-to-first-measurable-result: how many days from kickoff to a quantified before/after metric.
    • Baseline dependency: whether the option requires a pre-existing measurement of cycle time and error rate to demonstrate improvement.
    • Integration surface: number of existing systems (helpdesk, CRM, Slack/Teams, ERP) that must be connected via API.
    • Model dependency: whether the option is tied to a specific LLM provider or is model-agnostic.
    • Human-in-the-loop threshold: the minimum error rate below which auto-approval is safe.
    • Scalability across departments: how easily the output extends from customer support to claims, carrier coordination, or back-office.
    • Cost structure: fixed fee versus usage-based API cost, and the engineering hours required for integration.
    • Rollout risk: the probability that the pilot’s success does not translate to a full deployment without rework.

    Side-by-Side Comparison

    Criterion Option A: AI Process Audit & Roadmap Option B: Round-the-Clock Triage Pilot
    Time-to-first-measurable-result 10–14 days (audit report + prioritized sequence) 5–7 days (shadow-mode baseline vs. AI-assisted response)
    Baseline dependency Produces the baseline; does not consume one Consumes the baseline; requires 3-day pre-pilot measurement
    Integration surface Read-only access to helpdesk, CRM, Slack/Teams logs Write access to helpdesk API + Slack/Teams webhook; 2–3 system connections
    Model dependency None (analytical, not generative) Anthropic Claude API (claude-sonnet-4-20250514 or claude-3-5-sonnet)
    HITL threshold N/A Error rate < 5% on 200-ticket sample before auto-approve
    Scalability across departments Directly maps to multi-department rollout sequence Extends via parameterized prompts; requires new baseline per department
    Cost structure Fixed fee, EUR 6,000–10,000 for 2 weeks Fixed fee EUR 8,000–15,000 + API usage (~EUR 200–300/month at 500 tickets/day)
    Rollout risk Low; output is a document, not a live system Medium; live integration must survive API changes and volume spikes

    Scenario-by-Scenario Verdict

    When Option A wins first. If the firm has never measured its support workflow, the audit is the correct starting point. A logistics company handling 400–800 inbound tickets per week across shipment status, delivery exceptions, and billing disputes cannot demonstrate a first-response-time improvement without a baseline. The audit captures that baseline in days 1–3, identifies which ticket categories have the highest volume and error rate, and determines whether triage or document extraction on carrier invoices should be piloted first. In this scenario, the audit also reveals whether the existing helpdesk has a clean REST API or whether a Slack/Teams bridge is needed—information that directly affects the pilot’s integration scope and timeline. Without the audit, the two-week pilot risks measuring against a baseline that does not reflect steady-state workload.

    When Option B wins first. If the firm already has a documented baseline—average first-response time of 4.2 hours, routing error rate of 12%—the triage pilot can start immediately. The Claude API triage layer, integrated with the helpdesk and Slack/Teams, can be in shadow mode by day 5. For a 51–200 employee firm where the support team of 6–10 agents is the bottleneck, cutting first-response time from 4.2 hours to under 30 minutes for the top three ticket categories (status inquiries, delivery confirmations, tracking lookups) is the highest-impact single change. The pilot’s fixed scope means the firm commits to two weeks and a defined deliverable, not an open-ended engagement.

    Recommendation

    The sequencing recommendation. For a logistics firm in Austria with no compliance mandate and a two-week timeline, the correct sequence is: audit in week 1, triage pilot in week 2, compressed into a single fixed-scope engagement. The audit occupies days 1–3 and produces the baseline and the prioritized workflow list. The triage pilot occupies days 4–14, with shadow-mode testing on days 4–10, HITL validation on days 11–13, and the go/no-go review on day 14. This sequencing is feasible because the audit’s output (the baseline and the top-three ticket categories) is exactly the input the pilot needs. Attempting to run both in parallel would dilute measurement quality; running the audit alone would waste the two-week window without producing a live system.

    The explicit recommendation. Option B—the round-the-clock triage pilot using the Anthropic Claude API—is the correct primary deliverable for this scenario, but it is contingent on Option A’s audit output. The firm should contract a single fixed-scope engagement that bundles both: the audit as the first three days, the triage pilot as the remaining eleven. The pilot’s success criterion is a measured reduction in first-response time for the top three ticket categories, with a routing error rate below 5% on a 200-ticket validation sample. The integration targets the existing helpdesk and Slack or Microsoft Teams; no system is replaced. The model-agnostic architecture means that if the firm later moves to an open-weight model on its own hardware for a different workflow, the triage layer’s integration points remain unchanged.