Forfis Blog

Tag: Order and Shipment Status Updates

  • RAG Assistant vs Customer-Facing AI: Automating Reporting in UK Healthcare

    What Is Being Compared

    The two options under evaluation are a retrieval-augmented knowledge assistant (RAG assistant) built on LangChain and LangGraph that operates over the company’s internal documentation, CRM records, and ERP data, and a customer-facing AI assistant that handles ticket triage, first-response, and voice interactions with patients or clients. Both are deployed by a dedicated AI team with a 6-month timeline, integrating via custom REST APIs and webhooks into existing systems. The company is a 501-2000 employee healthcare and medtech firm in the UK, operating under HIPAA compliance requirements, with the specific need to automate monthly reporting and order and shipment status updates as part of scaling operations and supply chain without new hires. The RAG assistant is an internal tool; the customer-facing assistant is an external interface. This distinction drives every criterion that follows.

    Evaluation Criteria

    The evaluation uses seven criteria, each tied to the scenario dimensions:

    • HIPAA compliance and data residency: Can the system handle PHI without violating UK data protection rules? Does data stay on-prem?
    • Integration complexity: How many custom REST API and webhook integrations are required to connect to existing CRMs, ERPs, and helpdesks?
    • Cycle time reduction: Measured before/after baseline on monthly reporting and order status update turnaround.
    • Error rate: Transcription and data-entry error rates in the automated output versus manual processing.
    • Human-in-the-loop overhead: Time and headcount required for approval of outputs touching money, health data, or contracts.
    • Model-agnostic architecture: Ability to use OpenAI/Anthropic APIs for quality tasks and open-weight models on client hardware for regulated data.
    • Scalability without new hires: Can the system absorb 20-50% volume growth without additional FTEs?

    Side-by-Side Comparison

    Criterion RAG Knowledge Assistant Customer-Facing AI Assistant
    HIPAA compliance Open-weight models on client hardware; PHI tokenized before model access; BAA with vendor Cloud-hosted models typically cannot sign BAA; PHI exposure risk in ticket/voice channels
    Integration surface Custom REST APIs to ERP, CRM, document stores; webhooks for report triggers Helpdesk APIs, messaging platforms, voice gateways; fewer internal system touchpoints
    Cycle time (monthly report) 3-5 days manual → 4-8 hours with RAG draft + human approval Not applicable; does not generate internal reports
    Cycle time (order status) 5-10 min manual lookup → under 30 sec per order via API extraction 2-5 min per ticket with triage + first-response automation
    Error rate (data entry) 2-5% manual → under 0.5% with API-based extraction 1-3% on ticket classification; higher on free-text responses
    Human-in-the-loop Required for any output touching PHI, money, or contracts; 1-2 hr review per report Required for escalations and sensitive patient queries; 30-60 sec per ticket
    Scalability (20-50% volume) Absorbs via parallel API calls; no new hires needed Absorbs via queue management; may need 1-2 additional support FTEs at 50%+ growth

    Scenario-by-Scenario Verdict

    When the RAG assistant wins: The RAG assistant is the correct choice when the primary need is automating monthly reporting and order and shipment status updates from internal systems. It operates on the company’s own documentation, CRM, and ERP data, which is exactly where the cycle time and error rate pain points live. The HIPAA requirement forces open-weight models on client hardware, which the RAG architecture supports natively through LangGraph’s stateful orchestration: the model retrieves, drafts, and routes to a validation node where a human approves before the output reaches the ERP. The custom REST API and webhook integrations pull data directly from source systems, eliminating manual copy-paste. For a 501-2000 employee company scaling operations and supply chain without new hires, the RAG assistant reduces monthly reporting from 3-5 days to 4-8 hours and order status lookups from 5-10 minutes to under 30 seconds per order. The dedicated AI team ships a measured before/after baseline in the pilot phase, making the ROI case concrete.

    When the customer-facing assistant wins: The customer-facing assistant is the right choice when the bottleneck is patient or client interaction volume — ticket triage, first-response, and voice channels. It reduces time-to-first-response from 4-8 hours to under 5 minutes and handles 60-80% of routine queries without human intervention. However, it does not address the internal reporting and order status workflows that are the stated need in this scenario. It also introduces a different compliance surface: GDPR and the UK Data Protection Act 2018 for patient communications, plus voice-channel-specific requirements. For a company whose primary pain is back-office cycle time rather than customer interaction volume, the customer-facing assistant solves a different problem.

    Recommendation

    The RAG knowledge assistant is the correct option for this scenario. The stated need — automate monthly reporting and order and shipment status updates — is an internal operations problem, not a customer interaction problem. The HIPAA compliance requirement eliminates most cloud-hosted customer-facing assistant products because they cannot sign a BAA or guarantee UK data residency. The RAG architecture, built on LangChain and LangGraph, supports the model-agnostic approach: OpenAI or Anthropic APIs for high-quality summarization and classification tasks, and open-weight models (Llama 3 70B, Mistral 7B) on the client’s own hardware for any task touching PHI. The dedicated AI team follows a fixed-scope pilot on one reporting workflow, ships with a measured before/after baseline on cycle time and error rate, and rolls out to the order status workflow in months 4-6. The custom REST API and webhook integrations connect to the existing ERP, CRM, and logistics systems without replacing them. The result: monthly reporting cycle time drops from 3-5 days to 4-8 hours, order status turnaround drops from 5-10 minutes to under 30 seconds per order, and data-entry error rates fall from 2-5% to under 0.5%. No new hires are required to absorb 20-50% volume growth. The customer-facing assistant can be added in a second phase if patient interaction volume becomes the next bottleneck, but it is not the solution to the problem stated in this engagement.

  • Automating Order Status Updates in Austrian Logistics: A 3-Month n8n Pilot

    The Cost of Manual Order Status Updates in Austrian Logistics

    A 120-person logistics operator in Vienna handles 4,000 to 6,000 customer inquiries per month. Each inquiry about order or shipment status requires a support agent to log into the ERP, cross-reference the tracking API, and draft a reply. The average cycle time is 4 to 6 minutes per inquiry, and the error rate on manual data entry sits at 3 to 5 percent. Monthly reporting pulls data from three systems, takes two full days, and still contains inconsistencies. The support team works 9 to 17 CET, but customers expect round-the-clock response. The gap between what the team can do and what customers expect is not a staffing problem; it is a process problem. The workflows are repetitive, data-driven, and well-suited to automation, but nobody has measured the baseline or mapped the dependencies.

    Why Off-the-Shelf Helpdesk Tools and Generic Chatbots Fall Short

    Most mid-sized logistics companies in Austria reach for a helpdesk ticketing system with basic automation rules. These tools route tickets by keyword and send canned responses, but they do not enrich data or clean records. A customer asking “Where is my shipment?” gets a template reply with no real-time tracking data. The second common approach is a custom script that pulls data from the ERP and pushes it to a dashboard. This works for one report but does not scale to customer-facing channels. The third approach is a generic AI chatbot trained on public data. It sounds helpful but hallucinates delivery dates, violates EU AI Act transparency requirements, and cannot access the company’s own CRM or ERP. None of these approaches measure cycle time or error rate before and after, so the business case remains unproven.

    A Fixed-Scope n8n Pilot with Human-in-the-Loop Controls

    The path that works starts with a process audit that maps the order status workflow end to end, measures baseline cycle time and error rate, and identifies the data enrichment steps that consume the most manual effort. The pilot then builds an n8n workflow on the client’s own infrastructure: it ingests shipment records from the ERP, enriches them with carrier tracking data, normalizes formats, and routes the result to Slack or Microsoft Teams for the support team. A human approves any response that touches a contract, a refund, or a health-related shipment. The AI drafts the status update; the agent reviews and sends it. Every automated response is logged with a timestamp, the model version, and the input data, satisfying EU AI Act Article 50 transparency and audit trail requirements. The pilot runs for 8 to 12 weeks, and the go/no-go decision is based on measured before/after metrics, not anecdote.

    Three Concrete First Steps to Start the Pilot

    Week 1: run the process audit. Map every step of the order status workflow, measure baseline cycle time and error rate, and document the data sources. Week 2: define the pilot scope. Pick one workflow, one customer-facing channel, and one data enrichment task. Write the success criteria: target cycle time, acceptable error rate, and the EU AI Act controls required. Week 3 to 4: build the n8n workflow. Integrate the ERP, the tracking API, and the messaging channel. Add logging and human approval gates. Week 5 to 8: run the pilot in parallel with the manual process. Measure every automated response against the baseline. Week 9 to 12: tune the workflow, document the handover, and make the go/no-go decision for rollout. The 3-month timeline assumes the client provides API access and one point of contact for approvals.

  • Deploying a RAG Assistant for Order Status Updates in Swiss E-Commerce

    The Problem: Senior Support Staff Buried in Routine Order Status Tickets

    Your support team at a 2,000+ employee e-commerce company in Switzerland handles thousands of order and shipment status inquiries weekly. Senior agents spend 40-60% of their time on routine lookups: “Where is my package?” “Why is my order delayed?” This work does not require judgment, but it consumes the people who should be handling complex escalations, refund disputes, and customer retention conversations. The EU AI Act, which applies to Swiss companies serving EU customers, requires transparency when AI systems interact with users. You need a retrieval-augmented knowledge assistant that drafts accurate responses from your order-management system and shipping carrier data, integrates with Zendesk or Intercom, and keeps a human in the loop for anything touching refunds or contract terms. The goal: cut first-response time from hours to minutes, reduce error rate on shipping information, and free senior staff for high-value work within a 3-month integration sprint.

    Prerequisites: What You Need Before the Sprint Starts

    Before starting the integration sprint, confirm these are in place:

    • Zendesk or Intercom API access: OAuth 2.0 tokens with read/write permissions for tickets, macros, and webhooks. Test with a sandbox account first.
    • Order-management system (OMS) API: Read access to order status, tracking numbers, and shipping carrier data. If you use Shopify, SAP Commerce, or a custom OMS, document the endpoint schema.
    • Shipping carrier APIs: Integration with at least your top two carriers (e.g., Swiss Post, DHL) for real-time tracking events.
    • PostgreSQL 15+ with pgvector extension: CREATE EXTENSION vector; Run on a dedicated instance with at least 16 GB RAM for 500k+ vectors.
    • LLM endpoint: OpenAI API key (gpt-4o or claude-3-5-sonnet) for drafting, or an on-prem Llama 3 70B instance if customer PII cannot leave your infrastructure.
    • EU AI Act compliance documentation: A data-protection impact assessment (GDPR Article 35) and a model card for each LLM endpoint.
    • Baseline metrics: Export 30 days of ticket data from Zendesk/Intercom. Calculate average first-response time, resolution rate, and error rate on shipping-related tickets.

    Step 1: Audit the Workflow and Establish a Baseline

    Run a process audit on your last 90 days of support tickets. Filter for order and shipment status inquiries: “Where is my order?” “Tracking number not working” “Delivery delayed.” Count the volume, measure average handling time, and identify the top five questions. For a 2,000+ employee e-commerce company, this typically represents 35-50% of total ticket volume. Export the data to a CSV with columns: ticket_id, subject, category, first_response_time, resolution_time, agent_id, error_flag. Calculate the baseline: if your average first-response time is 4 hours and error rate on shipping information is 8%, those are your targets to beat. Document this baseline in a one-page report. This becomes the measurement framework for the pilot and rollout phases.

    Step 2: Build the RAG Pipeline with pgvector

    Build the retrieval layer using pgvector. Chunk your knowledge base: shipping policies, carrier SLAs, return procedures, and order status definitions. Use a 512-token chunk size with 50-token overlap. Generate embeddings with OpenAI text-embedding-3-small (1536 dimensions) or bge-base-en-v1.5 (768 dimensions) if you prefer open-weight models. Load into PostgreSQL:

    CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  metadata JSONB,
  embedding vector(1536)
);
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

    Set ef_search = 64 for sub-10 ms recall. Test with 20 sample queries: “Where is my order with tracking number XYZ?” Verify that the top-5 retrieved chunks contain the relevant shipping policy and carrier SLA. If recall is below 90%, adjust chunk size or add metadata filters (e.g., WHERE metadata->>'carrier' = 'DHL').

    Step 3: Integrate with Zendesk or Intercom via Webhooks

    Connect the RAG pipeline to Zendesk or Intercom. For Zendesk: create a webhook on ticket creation that triggers your RAG service. The service retrieves relevant chunks, calls the LLM endpoint with a system prompt: “You are a support assistant for [Company]. Use only the retrieved context to draft a response. If the context does not contain the answer, say so. Do not invent tracking numbers or delivery dates.” Post the drafted response to the ticket via the API with a RAG-drafted tag. For Intercom: use the Events API to trigger on ticket.created and the Agent Inbox API to post the draft. Store the correlation ID (ticket_id + timestamp) in a log table for audit trails. This satisfies EU AI Act Article 50 transparency requirements: users are informed they are interacting with an AI, and every response is traceable to its source documents.

    Step 4: Add Human-in-the-Loop Approval for Sensitive Actions

    Implement the human-in-the-loop approval workflow. Any RAG-drafted response that touches refunds, address changes, or contract terms must be approved by a human before sending. In Zendesk, create a custom field ai_approval_status with values: pending, approved, rejected. When the RAG service posts a draft, set ai_approval_status = pending and assign the ticket to a supervisor queue. The supervisor reviews the draft, the retrieved context, and the LLM’s confidence score. If approved, the ticket moves to approved and the response sends. If rejected, the supervisor edits or reassigns. Log every approval decision with the supervisor’s user ID and timestamp. This workflow is mandatory under EU AI Act Article 50 for any AI system that makes decisions affecting consumers. For a 3-month sprint, build a simple approval UI in React or use Zendesk’s built-in ticket views filtered by ai_approval_status = pending.

    Step 5: Pilot with 10-20% of Tickets and Measure

    Run the pilot with 10-20% of order-status tickets for two weeks. Route a subset of tickets (e.g., all tickets tagged order_status from a specific region or carrier) to the RAG assistant. Measure: first-response time (target: under 15 minutes vs. baseline 4 hours), resolution rate (target: 80%+ first-contact resolution), and error rate on shipping information (target: under 2% vs. baseline 8%). Sample 5% of AI-drafted responses weekly. Compare each against the OMS and carrier API data. If the assistant states a delivery date, verify it matches the carrier’s tracking event. If error rate exceeds 2%, pause the pilot, re-index the knowledge base, and adjust the LLM prompt to require citation of specific tracking events. Document every error in a log with the ticket ID, the incorrect claim, and the correct data from the OMS. This log feeds into the EU AI Act model card and the GDPR Article 35 impact assessment.

  • Healthcare Logistics AI Glossary: 15 Terms for Order-Status Automation

    Scope and Conventions

    The terms below are alphabetized and defined in the context of a 501-2000 employee healthcare and medtech logistics firm in the USA that is deploying a retrieval-augmented knowledge assistant to handle order and shipment status updates across English, Spanish, and Mandarin. The assistant integrates with the firm’s ERP, CRM, and Slack or Microsoft Teams, uses the Anthropic Claude API for drafting, and operates under a human-in-the-loop approval model to satisfy GDPR. Each entry gives a definition and a one- or two-sentence example showing how the term applies to this specific scenario. The glossary is intended for operations leads, compliance officers, and technical buyers who are evaluating or running an 8-week pilot and need a shared vocabulary before the process audit begins.

    A through M

    Anthropic Claude API is a hosted large-language-model endpoint used for high-quality natural-language generation and classification. In this scenario, it drafts multilingual shipment-delay notices from structured ERP data. Before/after baseline is the set of metrics (cycle time, error rate, language accuracy) captured before the pilot and compared after. Data-processing agreement (DPA) is the GDPR Article 28 contract between the healthcare logistics firm and Forfis as processor. GDPR Article 22(1) prohibits solely automated decisions with legal or similarly significant effects; the human-in-the-loop design keeps the assistant within this boundary. Human-in-the-loop means a person approves any output touching money, health data, or a contract before it sends. Isolated pilot is a fixed-scope, 8-week deployment on one workflow with a measured baseline. Managed AI operations is the delivery model where Forfis owns ongoing monitoring, integration maintenance, and incident response for a monthly fee. Model-agnostic architecture means the language model can be swapped without rewriting the retrieval layer or Slack/Teams integration. Process audit is the structured review of existing workflows that measures cycle time, error rate, and manual touchpoints before automation is designed. Retrieval layer is the component that searches the ERP and CRM for passages relevant to the user’s query and returns them as context for the model. Retrieval-augmented knowledge assistant is the overall system that combines retrieval and a language model to generate grounded, auditable responses. Slack or Microsoft Teams integration is the channel through which the assistant delivers drafts and captures human approvals. Multilingual support coverage requires the system to produce accurate, culturally appropriate responses in English, Spanish, and Mandarin for a US-based healthcare logistics operation. Scaling operations without new hires means using AI to absorb increased order volume without proportionally increasing headcount. 8-week timeline is the pilot duration: week 1 audit, weeks 2-3 build, weeks 4-6 live run, week 7 measurement, week 8 review and roadmap.

    N through Z

    N through Z are not present in this glossary because the 15 terms above cover the full scope of the scenario. However, two additional terms that a compliance officer or technical buyer might encounter in the same engagement are worth noting. Sub-processor is a third party that processes personal data on behalf of the processor (Forfis); under GDPR Article 28(2), the controller must authorize each sub-processor, and the DPA must list them. In this scenario, Anthropic is a sub-processor if patient-identifiable data is sent to its servers; if the data is de-identified before the API call, Anthropic is not a sub-processor for that data. Data-subject-access request (DSAR) is a GDPR Article 15 request from a patient or clinic to see what personal data the firm holds. The AI assistant’s logs (drafted messages, approval timestamps, retrieved context) may contain personal data, so the firm must be able to produce those logs within 30 days. Forfis, as processor, must assist the controller in responding to DSARs under Article 28(3)(e). These two terms are not part of the core 15 but appear in the compliance review that follows the 8-week pilot.

  • GDPR-Compliant RAG Assistant for Fintech Order Status: 6-Month Rollout

    Process Audit and Pilot Scope

    Fintech companies with 11-50 employees face a specific challenge: customer support teams handle repetitive order and shipment status queries that consume 40-60% of agent time. A retrieval-augmented knowledge assistant can automate these routine interactions while maintaining compliance with GDPR and industry regulations. The key is building a system that grounds AI responses in your own operational data rather than relying on pre-trained model knowledge.

    The architecture uses LangChain for modular LLM components and LangGraph for stateful, multi-step orchestration. This combination handles the complex retrieval and validation logic required for order status updates, pulling live data from your ERP and logistics systems via APIs. The assistant integrates with Slack or Microsoft Teams, responding to customer queries within the existing communication channel while logging interactions for audit trails.

    For a 6-month rollout, the timeline breaks down as follows:

    • Weeks 1-2: Process audit to identify high-volume, low-complexity workflows
    • Weeks 3-6: Fixed-scope pilot on one workflow with baseline metrics
    • Weeks 7-14: Integration with existing CRMs, ERPs, and helpdesks
    • Weeks 15-24: Managed operation with continuous monitoring and human-in-the-loop oversight

    The pilot phase establishes measurable before/after baselines on cycle time and error rate, ensuring the AI assistant delivers tangible improvements before scaling to full deployment.

    GDPR Compliance and Data Handling

    GDPR compliance requires implementing data minimization, purpose limitation, and lawful basis for processing customer data. For a RAG assistant handling order and shipment status updates, this means ensuring that customer data used for training or inference is encrypted, access-controlled, and that you maintain records of processing activities. The system must not retain personal data longer than necessary for the stated purpose.

    For US-based fintech companies serving EU customers, GDPR applies alongside state privacy laws like CCPA/CPRA. The architecture must support data residency requirements, with options to run open-weight models on the client’s own hardware where regulated data cannot leave the building. This model-agnostic approach allows using OpenAI and Anthropic APIs where quality matters, while keeping sensitive data on-premises.

    Key compliance controls include:

    • Data encryption at rest and in transit
    • Access controls limiting who can view customer data
    • Audit logs tracking all AI interactions and data access
    • Data retention policies automatically purging data after the required period
    • Privacy by design ensuring minimal data collection from the start

    The human-in-the-loop model adds an additional layer of compliance: the AI drafts or classifies responses, but a human approves anything touching money, health data, or contracts. For order status updates, the AI can respond automatically for routine queries, but escalates to a human for exceptions, refunds, or complex shipping issues.

    LangChain and LangGraph Architecture

    LangChain provides the modular foundation for building LLM applications, with components for model calls, data retrieval, and prompt management. LangGraph adds stateful, multi-step orchestration, enabling complex workflows that maintain context across multiple interactions. For customer support with order status updates, this combination handles the multi-step retrieval and validation logic required to pull live data from your ERP and logistics systems.

    The workflow for an order status query looks like this:

    1. Language detection identifies the customer’s language and routes to the appropriate model
    2. Retrieval pulls relevant order and shipment data from your ERP via API
    3. Validation checks data freshness and completeness before generating a response
    4. Response generation formats the answer in the customer’s language
    5. Escalation triggers human review for exceptions or complex issues

    LangGraph manages the state across these steps, ensuring the assistant maintains context if the customer asks follow-up questions. LangChain handles the underlying model calls, using OpenAI and Anthropic APIs for high-quality responses where data sensitivity allows, and open-weight models on-premises for regulated data.

    The integration with Slack or Microsoft Teams is straightforward: the assistant listens for customer queries in the designated channel, processes them through the LangGraph workflow, and responds in the native interface. All interactions are logged for compliance and audit trails, with the option to export data to your CRM for further analysis.

    Human-in-the-Loop and Escalation Logic

    Human-in-the-loop is the default delivery model for Forfis, ensuring that the AI drafts or classifies responses while a human approves anything touching money, health data, or contracts. For order and shipment status updates, this means the AI can respond automatically for routine queries like “Where is my order?” but escalates to a human for exceptions like delayed shipments, returns, or international logistics complications.

    The escalation logic is built into the LangGraph workflow. The assistant evaluates the query against a set of rules:

    • Routine queries (order status, estimated delivery date) are handled automatically
    • Exception queries (delayed shipment, damaged goods, return request) trigger human review
    • High-value transactions (orders over a certain threshold) always require human approval
    • Sensitive data (payment information, personal details) is never processed by the AI without human oversight

    This model reduces agent workload by 40-60% while maintaining compliance and customer trust. The human team focuses on complex issues that require judgment, empathy, or specialized knowledge, while the AI handles the repetitive, high-volume queries.

    For a company with 11-50 employees, this means a small support team can handle a larger volume of customer interactions without sacrificing quality. The managed operations model includes ongoing monitoring of escalation rates, response accuracy, and customer satisfaction, with regular reviews to adjust the escalation rules based on real-world data.

    Multilingual Support and Language Routing

    Multilingual support requires training or fine-tuning the model on customer queries in multiple languages, ensuring the RAG system retrieves and processes data accurately across languages. For US-based fintech serving international customers, this includes Spanish, French, German, and other common languages, with language detection and routing built into the workflow.

    The architecture handles multilingual support in three layers:

    1. Language detection identifies the customer’s language using a lightweight classifier
    2. Model routing directs the query to the appropriate model or fine-tuned version for that language
    3. Response generation formats the answer in the customer’s language, maintaining consistency with the brand’s tone and style

    For order and shipment status updates, the data itself is language-neutral (order numbers, dates, tracking numbers), but the response must be in the customer’s language. The RAG system retrieves the same data regardless of language, but the response generation layer adapts the phrasing and formatting to match the customer’s linguistic context.

    This approach ensures that customers in different regions receive consistent, accurate information while feeling understood in their own language. The managed operations model includes monitoring of multilingual response accuracy, with regular reviews to identify and address any language-specific issues or cultural nuances that the model may miss.

    6-Month Rollout Timeline

    The 6-month rollout timeline is structured to minimize risk and maximize learning. The process audit in weeks 1-2 identifies the high-volume, low-complexity workflows worth automating, focusing on order and shipment status updates as the pilot scope. This phase involves mapping the current process, identifying pain points, and establishing baseline metrics for cycle time and error rate.

    The fixed-scope pilot in weeks 3-6 tests the AI assistant on one workflow, measuring performance against the baseline. The pilot includes integration with your existing CRM, ERP, and helpdesk via APIs, ensuring the assistant pulls live data and responds within the existing communication channel. The goal is to validate that the AI can handle routine queries accurately and efficiently before scaling.

    Weeks 7-14 focus on integration and testing, expanding the assistant to handle additional workflows and languages. This phase includes load testing, security audits, and compliance reviews to ensure the system meets GDPR and industry requirements. The human-in-the-loop model is refined based on pilot feedback, with escalation rules adjusted to balance automation and oversight.

    Weeks 15-24 are the managed operation phase, where the assistant runs in production with continuous monitoring. The managed operations model includes regular reviews of response accuracy, escalation rates, and customer satisfaction, with ongoing model updates and data quality improvements. This phase ensures the AI assistant continues to perform as business data changes and new workflows are added.

  • RAG Assistant for Order Status: 2-Week Pilot in Austrian E-commerce

    The Problem: Manual Order Status Queries in a 25-Person E-commerce Team

    A 25-person e-commerce operation in Vienna handles 400-600 customer inquiries daily, most of them asking where their order is. The support team spends 3-4 hours per agent per day on these repetitive queries, pulling up order management screens, checking carrier tracking numbers, and drafting responses. First-response time averages 6 hours, and document turnaround for shipping confirmations takes 1-2 business days. The business function is customer support, but the bottleneck is manual data retrieval and response drafting, not the actual customer interaction. The need is clear: cut first-response time to under 2 minutes and reduce document turnaround to same-day processing, without adding headcount or replacing existing systems. The solution must work within PCI DSS constraints because the support team occasionally handles refund requests that touch cardholder data, and it must integrate with Google Workspace, which the team already uses for email and calendar management. The pilot scope is one specific workflow: order and shipment status updates, chosen because it is high-volume, rule-based, and has clear before/after metrics to measure success.

    Architecture: Open-Weight Models On-Premise for PCI DSS Compliance

    The architecture uses open-weight models running on the client’s own hardware, not cloud APIs. This is a deliberate choice driven by PCI DSS compliance: cardholder data and transaction details must not leave the client’s controlled infrastructure. The model is a 7B-parameter open-weight variant, fine-tuned on the client’s historical support tickets and order management documentation. It runs on a single GPU server in the client’s data center, with all inference happening locally. The retrieval layer connects to the client’s order management system and shipping carrier APIs via standard REST endpoints, pulling real-time order status, tracking numbers, and delivery windows for each query. The assistant does not store transaction data; it retrieves it on demand, which means the model never has persistent access to sensitive information. This architecture satisfies PCI DSS requirement 3.4, which mandates that cardholder data be rendered unreadable at rest, and requirement 4, which requires encryption of data in transit. The model-agnostic design means that if the client later wants to use a different model for a different workflow, the retrieval layer and integration code remain unchanged.

    Pilot Scope: Two-Week Deployment on Order Status Queries

    The pilot runs for two weeks, starting with a process audit that maps the current workflow for order status queries. The audit identifies the specific data points the support team needs: order ID, current status, carrier name, tracking number, estimated delivery date, and any delay flags. The assistant is configured to retrieve these data points from the order management system and shipping carrier APIs, then draft a response in English. The integration with Google Workspace connects to Gmail for inbound customer emails and Google Calendar for scheduling follow-ups if a human agent needs to step in. The assistant drafts the response, and a human agent approves it before it is sent. This human-in-the-loop design ensures that any message involving refunds, compensation, or contract changes remains under human control, which is a PCI DSS requirement for payment-related communications. The pilot measures three metrics: first-response time, document turnaround time, and error rate. The baseline is established during the first three days of the pilot, before the assistant is fully active, so the before/after comparison is clean and measurable.

    Delivery Model: Dedicated AI Team for Full-Cycle Deployment

    The dedicated AI team handles the full lifecycle of the pilot. Week one covers the process audit, model deployment on the client’s on-premise hardware, and integration with the order management system and shipping carrier APIs. The team configures the retrieval layer, fine-tunes the model on the client’s historical support tickets, and sets up the Google Workspace integration. Week two is the active pilot period, during which the assistant handles live customer queries under human supervision. The team monitors performance daily, adjusting prompts and retrieval logic as needed. The team also documents the before/after metrics, including first-response time, document turnaround time, and error rate, so the client has a clear measurement of the pilot’s impact. The team operates as an extension of the client’s internal staff, attending daily standups and providing a weekly summary of performance and issues. The client does not need to hire ML engineers or manage infrastructure; the dedicated team handles all technical aspects of the deployment and operation.

    Measured Outcomes: Cycle Time and Error Rate Reduction

    The pilot targets a 60-80% reduction in manual ticket handling for order status queries. First-response time drops from 6 hours to under 2 minutes, because the assistant answers instantly from live data. Document turnaround for shipping confirmations and return authorizations drops from 1-2 business days to same-day processing. The error rate, measured as the percentage of responses that require human correction, is expected to be under 5% after the first week of tuning. The pilot establishes a clear baseline during the first three days, so the before/after comparison is measurable and defensible. If the metrics show a clear improvement, the next phase expands to additional workflows such as returns processing, product recommendations, or bilingual support for German-language queries. The dedicated AI team continues to monitor performance and adjust prompts as the client’s business processes evolve, ensuring that the assistant remains accurate and relevant as the order management system and shipping carrier APIs change.

  • Austrian Fintech Automates Order Status with a Voice Agent in Four Weeks

    The Support Team Is Drowning in Status Inquiries

    A 15-person fintech in Austria handles 300-500 customer support tickets per week. The majority are order and shipment status inquiries. Each inquiry takes a support agent 5-7 minutes to resolve: they check the ERP for order status, the CRM for customer history, and the carrier API for shipment tracking. The agent then drafts a response, reviews it for accuracy, and sends it. This process is repetitive, data-driven, and error-prone. The support team is stretched thin, and the company cannot hire more agents without breaking the budget. The pain is not a lack of technology; it is a lack of time and bandwidth to handle the volume of routine inquiries.

    Why Existing Solutions Fall Short

    The company has tried two approaches. First, they built a custom chatbot using a rule-based system. The chatbot handles simple inquiries but fails on complex ones. It cannot query the ERP or CRM in real time, so it provides outdated or inaccurate information. Second, they considered a generic AI chatbot. The chatbot can draft responses, but it lacks the context to handle the specific data sources the company uses. It also cannot meet the company’s ISO 27001 compliance requirements, because it stores data in the cloud and does not provide the audit logging the company needs. Both approaches fail because they do not integrate with the company’s existing systems or meet its compliance requirements.

    A Voice Agent That Integrates With Existing Systems

    The proposed approach is a voice agent that integrates with the company’s existing ERP, CRM, and carrier APIs. The agent uses the OpenAI API to understand the customer’s inquiry and draft a response. It queries the ERP for order status, the CRM for customer history, and the carrier API for shipment tracking. The agent then sends the response to the customer. The human-in-the-loop model ensures that any response touching financial data is approved by a person before it reaches the customer. The agent is deployed on the company’s own infrastructure, which meets the ISO 27001 requirements for data access, encryption, and audit logging. The custom REST API and webhooks connect the agent to the company’s systems, so the agent can query and update data in real time.

    How to Start: Four Concrete Steps

    The first step is a process audit. The dedicated AI team maps the current manual process, identifies the data sources, and defines the success metrics. The second step is the pilot design. The team selects one workflow (order and shipment status updates) and defines the scope, timeline, and success criteria. The third step is the pilot deployment. The team builds the voice agent, integrates it with the company’s systems, and runs the pilot for two weeks. The fourth step is the measurement. The team measures the cycle time and error rate before and after the pilot. The fifth step is the rollout. If the pilot meets the success criteria, the team scales the automation to other support channels.

  • Cutting First-Response Time from 38 Hours to 4 in a German Medtech Distributor

    Background: A Mid-Size Medtech Distributor in Southern Germany

    This case study is a composite. It draws on patterns Forfis has observed across multiple engagements in German healthcare and medtech distribution. No named customer is represented; the company, metrics, and timeline are representative of the work we deliver, not a single identifiable client.

    The company in question is a mid-size medtech distributor in southern Germany, roughly 340 employees, operating across two regional warehouses and a central back office in Stuttgart. It handles order intake, shipment coordination, and after-sales support for orthopedic and diagnostic equipment. The ERP is SAP S/4HANA, the helpdesk is a legacy on-premises ticketing system, and the CRM is Microsoft Dynamics 365. The company had been running on a paper-and-email hybrid for inbound purchase orders and shipment confirmations for over a decade. No prior AI or automation project had been attempted; the operations team had flagged the bottleneck in internal reviews for three consecutive quarters without a funded solution.

    Challenge: A 24-Hour SLA the Manual Process Could Not Meet

    The trigger was a contractual deadline. A major hospital group, representing roughly 18 percent of the company’s annual revenue, issued a service-level agreement requiring order-status acknowledgments within 24 hours and shipment confirmations within 4 hours of dispatch. The existing process could not meet either threshold. Inbound purchase orders arrived as scanned PDFs, emailed attachments, and occasionally physical mail. A team of four operators manually transcribed each order into SAP, cross-referenced it against the shipment plan, and drafted a status email to the customer. The median first-response time was 38 hours. The 95th percentile was 72 hours. The error rate on transcribed fields was 6.2 percent, and each correction required a second pass through the approval chain.

    The operational pressure was compounded by GDPR. The documents contained patient identifiers, billing addresses, and in some cases clinical context. The company’s data protection officer had flagged the manual process as a compliance risk: paper documents were stored in unsecured filing cabinets, and email attachments were not consistently encrypted. The deadline was not optional. The hospital group had indicated that non-compliance would trigger a contract review in the following quarter.

    Approach: A Six-Week Integration Sprint on SAP and Claude

    Forfis ran a six-week integration sprint. The first week was a process audit: mapping every document type, every handoff, every approval gate, and every data field that touched the ERP. The audit identified 14 distinct document formats across purchase orders, packing lists, customs declarations, and shipment confirmations. The team selected the three highest-volume formats for the pilot, covering roughly 70 percent of inbound documents.

    The extraction pipeline used the Anthropic Claude API for document parsing and field classification. The model was prompted with structured output schemas matching the SAP data model. The orchestration layer, built on a workflow engine, routed each extracted record through a confidence check. Records above a 92 percent confidence threshold and containing no patient identifiers or payment amounts were auto-approved. Everything else went to a human approver in a queue built into the existing helpdesk. The SAP integration used the OData API to write order and shipment records directly into S/4HANA, bypassing the manual entry step entirely. The first-response template engine pulled the enriched record from SAP and generated a status email within 90 seconds of approval.

    Outcome: 38 Hours to 4 Hours, 6.2 Percent to 0.9 Percent

    The pilot went live in week seven on a subset of order types from two regional warehouses. The full rollout followed in weeks eight and nine, extending to all document types and both warehouses. The two-month stabilization phase that followed focused on reducing the human-review rate and tuning extraction thresholds per document type.

    The measured outcomes, tracked against the pre-pilot baseline, were as follows:

    • Median first-response time fell from 38 hours to 4 hours. The 95th percentile dropped from 72 hours to 11 hours.
    • Error rate on extracted fields fell from 6.2 percent to 0.9 percent.
    • Cycle time per document, from receipt to ERP entry, dropped from 4.5 hours to 22 minutes.
    • Human-review rate settled at 15 to 20 percent of records in steady state, down from the initial 25 percent.
    • Customer satisfaction for order-status inquiries rose by 11 points on a 100-point scale over the first quarter after go-live.

    Two full-time operators were redirected from manual data entry to exception handling and quality review. The GDPR compliance work, including the DPIA under Article 35 and the pseudonymization pipeline, was completed before go-live and required no rework during the stabilization phase.

    Lessons for Similar Teams in Healthcare and Medtech

    Five lessons from this engagement generalize to similar teams in healthcare and medtech distribution:

    • Start with the SLA, not the technology. The hospital group’s 24-hour acknowledgment requirement defined the success criterion. The technology choice followed from the constraint, not the other way around. Teams that start with a model demo and work backward to a business need tend to over-build and under-deliver.

    • The process audit is not optional. The 14 document formats, the unsecured filing cabinets, the inconsistent email encryption — none of this was visible from a technology specification. The audit took one week and saved an estimated three weeks of rework later in the sprint.

    • Human-in-the-loop is a design decision, not a fallback. The confidence threshold and the data-sensitivity routing were defined in week two, before any code was written. Teams that treat the human gate as an afterthought end up with either over-automation (errors in production) or under-automation (the human reviews everything, and the cycle time does not improve).

    • Model-agnostic architecture protects the client’s future. The client’s data protection officer asked, in week four, whether the pipeline could run on an open-weight model if the hospital group’s contract was renegotiated. Because the orchestration layer was decoupled from the model API, the answer was yes, and the rework estimate was under two weeks. A hard-coded dependency on a single vendor API would have made that conversation much harder.

    • The baseline is the deliverable. The before/after measurement on cycle time and error rate was agreed in the audit phase and tracked from day one of the pilot. Without that baseline, the 38-to-4-hour improvement would have been anecdotal. With it, the client could present the numbers to the hospital group’s procurement team with confidence.

  • Four-Week AI Pilot: Automating Order-Status Data Entry in a UK Medtech Firm

    The Problem: Manual Order-Status Data Entry in a Regulated UK Medtech Firm

    A 51-200 person UK medtech company handling order and shipment status updates for customer support is drowning in manual data entry. Every time a customer emails or calls about an order, an operator opens the CRM, searches for the order reference, checks the logistics provider’s tracking page, types the status back into the ticket, and logs the interaction. At 12-18 minutes per request and 3-5 percent transcription error rate, this single workflow consumes 15-25 percent of the support team’s capacity. The problem is not the volume alone; it is that the data is unstructured (email bodies, PDF attachments, voice notes) and the regulatory environment (ISO 27001, UK GDPR) means you cannot simply pipe customer emails into a third-party API without a documented risk assessment. The pilot targets this one process, automates the extraction and classification, and ships with a measured before/after baseline that proves the case for rollout.

    Prerequisites Before Week 1

    Before the dedicated AI team begins the four-week pilot, you need the following in place:

    • One named process owner from the customer support team who can answer questions about the current workflow and approve the pilot scope.
    • Access to historical documents: at least 200-500 examples of customer emails, PDFs, or spreadsheets containing order and shipment status requests, exported from Google Workspace or the CRM.
    • CRM API credentials with read/write permissions for the order and ticket objects, scoped to the pilot’s data set.
    • Google Workspace API access: Gmail API and Google Drive API scopes for the pilot mailbox, with data residency set to the UK or EU region.
    • A GPU server or cloud instance with at least 80 GB of VRAM (e.g., an A100 or H100) for running the open-weight model on-premise, or a confirmed decision to use a cloud GPU for the pilot phase only.
    • ISO 27001 documentation access: the client’s current statement of applicability and any existing risk assessments covering customer data handling, so the pilot’s controls align with the existing certification scope.

    Step 1: Run the Process Audit and Capture the Baseline

    The dedicated AI team maps every manual step in the order-status workflow and captures the baseline metrics. You export 200-500 historical requests from Google Workspace and the CRM, and the team tags each one with cycle time (from email receipt to ticket closure), error type (wrong order reference, missed shipment detail, incorrect status), and number of human touches. The output is a one-page scorecard: for a typical UK medtech firm, the baseline shows 14 minutes average cycle time, 4.2 percent error rate, and 3.1 human touches per request. This scorecard becomes the denominator for the before/after report and the justification for the pilot’s scope. The team also identifies which fields in the extracted data touch money, health data, or contracts, because those fields will require human-in-the-loop approval in the next step.

    Step 2: Select and Fine-Tune the Open-Weight Model On-Premise

    The team selects an open-weight model that fits the client’s GPU and data constraints. For a UK medtech firm where patient identifiers and order details cannot leave the building, the default is Llama 3 70B or Mistral 8x7B running on the client’s on-premise A100 server. The model is fine-tuned on the 200-500 historical documents from Step 1, using a supervised fine-tuning (SFT) dataset where each example pairs the raw email or PDF with the correctly extracted fields (order reference, shipment ID, status, date, customer name). The fine-tuning runs for 2-3 epochs on the client’s GPU, taking 4-8 hours. The team evaluates the fine-tuned model on a held-out set of 50 documents, targeting a field-level accuracy of 95 percent or higher before moving to integration. If accuracy falls below 95 percent, the team iterates on the SFT dataset or switches to a larger model variant.

    Step 3: Build the Google Workspace and CRM Integration

    The pipeline connects to Google Workspace through the Gmail API and Google Drive API. Incoming emails to the pilot mailbox trigger a push notification; the pipeline fetches the message body and any attached PDFs or spreadsheets, passes them to the on-premise inference endpoint, and receives structured JSON output containing the extracted fields. The pipeline then calls the CRM’s REST API to look up the order by reference, pulls the current shipment status from the logistics provider’s API (DHL, DPD, or the 3PL system), and merges the two data sets. The output is a draft customer-facing update and a structured record for the CRM. All API calls are logged with timestamps, request IDs, and data classification tags, feeding directly into the client’s ISO 27001 audit trail. The integration uses the client’s existing service accounts, not new credentials, to minimize the attack surface.

    Step 4: Configure the Human-in-the-Loop Approval Gate

    The approval interface is a simple web dashboard where the support operator sees a diff view: the source document on the left, the model’s extracted fields on the right, and a highlight on any field classified as touching money, health data, or a contract. The operator can approve, edit, or reject each field. In practice, 70-85 percent of routine order-status updates pass without human intervention because the model’s confidence score exceeds the threshold (typically 0.92) and no sensitive fields are present. The remaining 15-30 percent route to the approval queue with a 4-hour SLA. The queue is monitored by the process owner, and any rejection is logged with a reason code that feeds back into the SFT dataset for the next model iteration. This loop ensures the model improves with each week of live operation.

    Step 5: Run the Pilot and Produce the Before/After Report

    The pilot runs on a controlled sample of 50-100 live requests over two weeks. The measurement harness captures the same metrics as the baseline: cycle time, error rate, and human touches per request. The team compares the pilot results against the Step 1 scorecard and produces a before/after report. A typical result for a UK medtech firm is a 65 percent reduction in cycle time (from 14 minutes to 5 minutes) and a 50 percent drop in transcription errors (from 4.2 percent to 2.1 percent). The report also documents the ISO 27001 controls in place: on-premise data residency, access controls on the inference server, audit logging, and the human-in-the-loop gate for sensitive fields. This report becomes the business case for rollout to additional workflows, such as invoice processing or document extraction for clinical trial records.

  • Cutting First-Response Time on Order-Status Tickets with LangGraph and RAG

    The Problem: Serial Ticket Handling in High-Volume E-commerce Support

    A 2,000+ employee e-commerce company in the USA handles roughly 50,000 support tickets per month. A significant share of those are order and shipment status inquiries: “Where is my package?” “Why is my order delayed?” “I haven’t received my confirmation email.” Each one lands in a shared Gmail inbox, gets picked up by an agent, who logs into the order management system, checks the shipment tracker, drafts a reply, and sends it. Average first-response time sits at 4-6 hours during peak season, and the cost per ticket is driven almost entirely by agent labor.

    The problem is not that agents are slow. It is that the workflow is serial: a human must read the ticket, decide what data to pull, pull it from two or three systems, compose a response, and send it. The AI opportunity is not to replace the agent but to collapse the serial steps into a parallel pipeline where the machine does the retrieval and drafting, and the human does the approval. Forfis approaches this as a workflow orchestration problem, not a chatbot problem. The goal is to cut first-response time from hours to minutes while keeping a human in the loop for anything that touches money or a customer commitment.

    The Mechanism: LangGraph Orchestration with a RAG Retrieval Layer

    The architecture rests on three layers. The orchestration layer uses LangGraph to define a stateful graph where each node is a discrete step: classify the ticket, retrieve order data, draft a response, check the approval gate, and send. Edges between nodes encode the control flow, including branches for escalation to a human agent when confidence is below threshold. LangChain sits underneath, providing the abstractions for LLM calls, prompt management, and document retrieval.

    The retrieval layer is a RAG pipeline. The company’s order management system, shipment tracking data, and policy documents are chunked at the record level and embedded into a vector store. When a ticket arrives, the system retrieves the relevant order record and passes it as context to the LLM. The integration layer connects to Google Workspace via the Gmail API and Google Chat API using OAuth 2.0 with least-privilege scopes. The AI does not replace the mailbox; it drafts responses that a human agent reviews and sends through the existing interface.

    The model choice is deliberately model-agnostic. Classification and retrieval run on an open-weight model on the client’s hardware where data residency matters. Final response drafting uses a frontier API (OpenAI or Anthropic) for quality. LangGraph abstracts this, so swapping models does not require re-architecting the graph.

    Trade-offs: Latency, Data Residency, and Automation Depth

    The first trade-off is latency versus accuracy. A frontier API produces better-drafted responses but adds 1-3 seconds of network latency per call. For a first-response-time target of under 10 minutes, this is acceptable. For a real-time voice channel, it would not be. The second trade-off is data residency versus model quality. Running the RAG pipeline on an open-weight model on-premises keeps customer order data inside the building, satisfying ISO 27001 data classification controls, but the model’s drafting quality is lower than a frontier API. The hybrid approach — on-premises retrieval, cloud drafting — splits the difference.

    The third trade-off is automation depth versus risk. Auto-approving every AI-drafted response would cut first-response time to under 2 minutes, but it violates the human-in-the-loop requirement for anything touching a refund or a contract. Forfis sets the approval gate at the record level: routine order-status queries auto-approve above a confidence threshold, but any response that mentions a refund, a delay compensation, or a policy exception routes to a human. This keeps the 90% of tickets that are simple status checks fast while protecting the 10% that carry financial or legal risk.

    The fourth trade-off is integration scope versus timeline. A four-week sprint cannot rebuild the CRM or the order management system. The integration is read-only on the data sources and write-only on the Gmail outbox. This constraint is a feature: it keeps the pilot reversible and the blast radius small.

    Recommendation: Start with a Fixed-Scope Pilot on Order-Status Tickets

    For a 2,000+ employee e-commerce company in the USA targeting ISO 27001 compliance, the recommendation is to start with a fixed-scope pilot on order and shipment status tickets only. Do not attempt to automate refund processing, returns, or policy exceptions in the first sprint. The pilot should measure three baselines before the AI goes live: average first-response time, average handling time, and error rate (wrong order number cited, incorrect shipment status, policy misstatement). After four weeks, compare the post-pilot numbers against the baseline.

    The integration sprint should follow this sequence: Week one is the process audit and baseline measurement. Weeks two and three build the LangGraph graph, wire the RAG pipeline to the order and shipment data, and connect the Google Workspace API. Week four is the pilot with the human-in-the-loop gate active. The pilot ships with a documented before/after report on cycle time and error rate.

    Two specific recommendations. First, chunk the RAG index at the record level, not the paragraph level. Order data is structured; the LLM needs the full order record to answer accurately. Second, log every AI-drafted response, every retrieval, and every approval decision. ISO 27001 requires documented evidence of information security controls, and the audit log is that evidence. The log should capture the ticket ID, the retrieved records, the model used, the confidence score, and the approver’s identity. This log is also the foundation for the managed operation phase after the pilot.