Forfis Blog

Tag: Automate Monthly Reporting

  • 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.

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

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

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

    Prerequisites Before Step 1

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

    Step 1: Process Audit and Baseline Measurement

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

    Step 2: Build the LangGraph Agent with Intent Classification

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

    Step 3: Integrate with Helpdesk via REST API and Webhooks

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

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

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

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

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

  • Automating the Monthly Compliance Report at a 201-500-Person UAE E-Commerce Firm

    The Monthly Report That Eats Fourteen Hours

    The monthly compliance report at a 201-500-person e-commerce firm in the UAE is not a single task. It is a chain of twelve to eighteen manual steps: pulling sales figures from the ERP, reconciling returns from the helpdesk, extracting vendor payment data from the accounting system, formatting the narrative summary, and filing the result with the internal compliance officer. The person who owns this workflow — usually a senior operations analyst or a compliance coordinator — spends 12 to 16 hours per cycle, and the error rate on manual transcription sits between 3 and 7 percent. A single mis-keyed figure can trigger a late filing or a wrong vendor payment, and the cost of a correction is not just the hours to fix it but the reputational friction with the internal audit team.

    The pain is structural, not personal. The analyst is not slow; the data is scattered across four systems that do not talk to each other. The ERP exposes a REST API, but the helpdesk only offers a CSV export. The vendor payment data lives in a spreadsheet that a finance clerk updates by hand. The analyst is, in effect, a human ETL pipeline, and the monthly deadline makes the work feel urgent even though the underlying process has not changed in three years.

    Why RPA and Vendor Reports Do Not Fix This

    The first common response is to buy a RPA tool — UiPath, Automation Anywhere, or a lighter-weight option — and have a consultant build a bot that clicks through the ERP, the helpdesk, and the spreadsheet. RPA works when the screens are stable and the data is in a predictable location. In a 201-500-person e-commerce firm, the screens are not stable. The ERP vendor ships a quarterly UI update. The helpdesk CSV export changes column order when the vendor upgrades. The spreadsheet has a new tab every month because the finance clerk “reorganized” it. The RPA bot breaks, and the consultant is no longer on retainer. The analyst goes back to manual work, now with a broken bot to ignore.

    The second common response is to ask the ERP or helpdesk vendor to build a custom report. This takes six to ten weeks of vendor project time, costs EUR 15 000 to EUR 40 000, and delivers a static PDF that still requires a human to interpret and file. The vendor has no incentive to build a report that spans three of its own products plus a spreadsheet. The result is a report that is accurate but slow, and the analyst still spends four to six hours on interpretation and formatting.

    The third response is to hire another analyst. This doubles the headcount cost without fixing the root cause: the data is still scattered, the process is still manual, and the new analyst inherits the same 14-hour cycle. The firm has bought time, not capacity.

    A Fixed-Scope Pilot on the Claude API

    The path that works for a firm at this stage — no AI in production yet, a 3-month timeline, a fixed-scope pilot — is a workflow-orchestration layer that sits on top of the existing systems rather than replacing them. The architecture is model-agnostic, but for a monthly compliance report where the narrative summary and the exception flagging benefit from strong language understanding, the Anthropic Claude API is the right fit. The system pulls data from the ERP via its REST API, triggers on a webhook from the helpdesk when a new returns batch lands, and reads the vendor payment spreadsheet through a lightweight parser. The Claude API handles the classification of exceptions, the drafting of the narrative summary, and the flagging of any figure that deviates from the prior month by more than a set threshold.

    The human-in-the-loop step is non-negotiable. The model drafts the report; a named compliance officer reviews it, corrects any flagged fields, and signs off. The approval log is stored as part of the audit trail. The system does not file the report automatically. It prepares it, flags it, and waits for the human. This keeps the cycle time low while ensuring that no number reaches the internal audit team without a person having seen it.

    The pilot ships with a measured before/after baseline: cycle time, error rate, and the number of manual steps. The target is to cut the 14-hour cycle to under 2 hours and reduce transcription errors to zero. The scope is locked in writing before development starts.

    From Pilot to Internal Knowledge Search

    The pilot is not the end of the story. The same orchestration layer that automates the monthly report can be extended to the internal knowledge search use case. The firm’s SOPs, vendor contracts, past compliance filings, and CRM records are chunked, embedded, and stored in a vector database. When an analyst asks, “What was the return rate for Q3 in the Gulf region?” the system retrieves the relevant chunks, passes them to the Claude API as context, and generates a cited answer with a link to the source document. This is a retrieval-augmented generation layer, not a chatbot. The accuracy depends on the quality of the source documents, so the process audit includes a document-hygiene pass before the RAG layer is built.

    The integration is through custom REST APIs and webhooks, not through a new middleware platform. The ERP already exposes a REST API. The helpdesk already fires webhooks on new tickets. The vendor payment spreadsheet is read by a parser that runs on a schedule. No new infrastructure is required. The system plugs into what the firm already runs.

    The 3-month timeline is realistic if the source systems expose clean APIs. Month one: process audit, baseline measurement, architecture design. Month two: build and integration. Month three: testing, human-in-the-loop validation, and the before/after measurement. If the audit reveals that data is trapped in PDFs with no API, add two to four weeks for a data-extraction layer.

    Five Steps to Start in Month One

    The first step is a one-to-two-week process audit. The goal is not to design the solution but to measure the baseline: how many hours the current monthly report takes, how many manual steps, the error rate over the last three cycles, and which systems the data comes from. The audit produces a one-page scorecard ranking the workflows by volume, error cost, and data availability. The pilot picks the top-ranked workflow that also has a clean data path.

    The second step is to name a single owner for the workflow. This is the person who will approve the AI’s output, correct flagged fields, and sign off on the report. Without a named owner, the human-in-the-loop step becomes a group chat, and the cycle time does not improve.

    The third step is to confirm API access. The ERP vendor must grant read access to the relevant endpoints. The helpdesk must confirm that webhooks can be configured for the returns batch. The vendor payment spreadsheet must be stored in a location the parser can reach. If any of these are blocked, the timeline stretches, and the pilot scope must be adjusted.

    The fourth step is to lock the pilot scope in writing. The deliverable, the acceptance criteria, the deadline, and the before/after metrics are all specified before development starts. The client pays for a known outcome, not an open-ended retainer.

    The fifth step is to run the pilot and measure. The pilot ships the automation, the integration, and a one-page report comparing baseline to actual. If the numbers move, the firm scales the pattern to adjacent workflows. If they do not, the firm has the baseline data and a clear diagnosis of why.

  • How an Austrian Medtech Firm Cut Compliance Reporting from 16 Hours to 4

    Background: A 30-Person Austrian Medtech Firm

    This case study is a composite built from patterns Forfis has observed across multiple engagements in the field. No named customer appears. The company, metrics, and timeline are representative of a recurring profile: a mid-size medtech firm in a Tier-1 European market running isolated AI pilots and looking to consolidate them into a managed workflow.

    The company is a 30-person Austrian medtech firm, roughly 18 months post-Series A, selling a Class IIa diagnostic device across DACH and Benelux. Its stack is a mix of a legacy CRM, a document management system for contracts, and a spreadsheet-driven compliance calendar. The compliance function is two people: a head of legal and compliance and a junior analyst. Monthly reporting under the EU Medical Device Regulation (MDR) and ISO 27001 requires them to extract obligations from 40+ active contracts, score each against operational status, flag deviations, and file a narrative summary with the quality management system. The cycle takes 14-18 hours per month, and the junior analyst is the single point of failure.

    Challenge: A 16-Hour Monthly Cycle and a Departing Analyst

    The pressure was operational, not strategic. The junior analyst was leaving in 90 days. The head of compliance had no bandwidth to absorb the full reporting cycle. The company was also preparing for an ISO 27001 surveillance audit in 5 months, which required documented, repeatable processes for every compliance activity. A manual, spreadsheet-driven cycle did not meet the audit’s evidence requirements.

    The specific need was to automate the monthly reporting cycle: extract clause-level obligations from contracts, score each against current operational status, flag deviations, and draft the narrative summary. The company had run two isolated AI pilots in the prior year — a ticket triage bot on their helpdesk and a document extraction tool for purchase orders — but neither touched the compliance function. The pilots were running, but they were not integrated, and the compliance team had no visibility into them. The challenge was not to build another isolated pilot but to create a managed, auditable workflow that the compliance team could own.

    Approach: Audit, Fixed-Scope Pilot, and a Dedicated Team

    Forfis ran a process audit in weeks 1-3. The audit mapped every step of the monthly reporting cycle, identified 5 automatable steps, and scored each by volume, error rate, and regulatory sensitivity. The pilot scope was fixed: clause extraction and obligation scoring for one product line, using the OpenAI API for text processing. The architecture was model-agnostic — the same pipeline could swap to an open-weight model on the client’s own hardware if a future contract contained data that could not leave the building. The integration was a custom REST API with webhooks, plugging into the existing CRM and document management system without replacing them.

    The delivery model was a dedicated AI team: three engineers and one product designer embedded with the compliance function for the full 6-month engagement. The team owned the model pipeline, the API, and the tuning loop. The compliance officer owned the approval step and the final report. Every pilot shipped with a measured before/after baseline on cycle time and error rate. The human-in-the-loop design meant the model drafted, the compliance officer approved, and every output was logged for the ISO 27001 audit trail.

    Outcome: 60% Cycle-Time Reduction and a Clean Audit

    The pilot ran for 6 weeks. The before baseline: 14-18 hours of manual work per month, with an error rate of 4-6% of obligations misclassified or missed. The after baseline at the end of the pilot: 4-6 hours of manual review per month, with an error rate of 1-2%. The cycle time dropped by roughly 60%. The compliance officer reported that the draft summaries were accurate enough to use as a starting point, cutting the drafting phase from 3 hours to 45 minutes.

    The go/no-go gate at the end of the pilot passed. Rollout extended the pipeline to all product lines and added the internal knowledge search layer, which indexed the contract corpus, regulatory guidance, CRM records, and past compliance reports. The knowledge search layer turned the monthly cycle into a continuous, queryable knowledge base. The team could answer ad-hoc questions like ‘What are our current MDR obligations for device X?’ in minutes instead of hours. The ISO 27001 surveillance audit, conducted in month 5, passed without findings on the reporting process. The dedicated team transitioned to a managed-operation model in month 7, handling model updates, prompt refinement, and edge-case triage on a monthly cadence.

    Lessons for Similar Teams

    • The audit is the product, not the pilot. The 3-week process audit produced a one-page decision matrix that the compliance team still uses 18 months later. The pilot was the validation, but the audit was the durable deliverable. Teams that skip the audit and jump straight to a pilot end up automating the wrong workflow.

    • Human-in-the-loop is not a compromise; it is the architecture. The model drafts, the human approves. This separation kept the ISO 27001 audit trail clean and ensured the model was never the final authority on a compliance determination. Teams that try to remove the human step for speed end up with an audit finding and a rework cycle.

    • Model-agnostic is a design constraint, not a marketing claim. The pipeline was built so the OpenAI API could be swapped for an open-weight model on the client’s own hardware without rewriting the integration. This mattered when a future contract contained data that could not leave the building. Teams that hard-code a single model API end up with a 3-month rework project when the data classification changes.

    • The knowledge search layer is where the ROI compounds. The monthly reporting cycle was the entry point, but the internal knowledge search layer is what the compliance team uses daily. The reporting cycle runs once a month; the knowledge search runs 20-30 times a week. Teams that stop at the reporting cycle miss the compounding value.

  • Swiss E-commerce Retailer Cuts Reporting Cycle Time 70% with AI Automation

    Background and Challenge

    This case study is a composite based on patterns observed in the field. It does not represent a single named customer but reflects common challenges and solutions in the e-commerce and retail sector in Switzerland.

    Background
    A mid-sized Swiss e-commerce retailer with 1,200 employees operates across DACH markets. The company uses a custom-built CRM and ERP system, with data stored in on-premise servers. The sales team of 45 handles lead qualification and monthly reporting manually, using spreadsheets and email. The company has no AI in production yet and is looking to reduce manual back-office work while improving lead qualification accuracy.

    Challenge
    The sales team spends 12 hours per week on monthly reporting, manually aggregating data from the CRM, ERP, and web analytics. The process is error-prone, with a 10% error rate in data entry. Lead qualification is inconsistent, with 30% of leads being misclassified, leading to lost opportunities. The company faces GDPR compliance requirements and a deadline to implement improvements before the Q4 peak season.

    Approach
    Forfis conducted an AI automation audit, identifying monthly reporting and lead qualification as high-impact use cases. A fixed-scope pilot was designed to automate these workflows using LangChain and LangGraph for workflow orchestration. The system integrates with the existing CRM and ERP via custom REST APIs and webhooks. A human-in-the-loop model ensures that AI-generated reports and lead scores are reviewed by a human before finalization. The pilot was deployed in two weeks, with a measured before/after baseline on cycle time and error rate.

    Outcome
    The pilot reduced monthly reporting cycle time from 5 days to 1 day, a 70% improvement. The error rate decreased from 10% to 2%, an 80% reduction. Lead qualification accuracy improved from 70% to 95%, with a 25% increase in qualified leads passed to sales. The system is GDPR-compliant, with data processed on-premise and no personal data leaving the building.

    Lessons

    • Start with a fixed-scope pilot to demonstrate ROI quickly.
    • Use a human-in-the-loop model to ensure accuracy and compliance.
    • Integrate with existing systems via APIs rather than replacing them.
    • Measure before/after baselines to quantify impact.
    • Choose a model-agnostic architecture to future-proof the solution.

    Approach: AI Automation Audit and Pilot Design

    The AI automation audit identified two high-impact use cases: monthly reporting and lead qualification. The audit mapped existing workflows, identified bottlenecks, and evaluated the feasibility of automating specific tasks. The results were a prioritized list of use cases, with estimated ROI and implementation complexity.

    Monthly Reporting
    The current process involves manually aggregating data from the CRM, ERP, and web analytics. The sales team spends 12 hours per week on this task, with a 10% error rate in data entry. The AI system automates data collection, validation, and report generation. It uses LangChain to chain prompts and tools, and LangGraph to define stateful, multi-step workflows. The system integrates with the existing CRM and ERP via custom REST APIs and webhooks, ensuring data integrity and real-time updates.

    Lead Qualification
    The current process is inconsistent, with 30% of leads being misclassified. The AI system uses a classification model to score leads based on predefined criteria, such as company size, industry, and engagement level. The model is trained on historical data and fine-tuned using feedback from the sales team. A human-in-the-loop model ensures that AI-scored leads are reviewed by a human before they are passed to sales, ensuring accuracy and context.

    GDPR Compliance
    The system is GDPR-compliant, with data processed on-premise and no personal data leaving the building. Data minimization is implemented, and data subjects can exercise their rights. The legal basis for processing is documented, and third-party AI APIs are GDPR-compliant. The system uses open-weight models on the client’s own hardware, ensuring that regulated data does not leave the building.

    Outcome: Measured Impact on Cycle Time and Error Rate

    The pilot was deployed in two weeks, with a measured before/after baseline on cycle time and error rate. The system was integrated with the existing CRM and ERP via custom REST APIs and webhooks, ensuring seamless data flow. The human-in-the-loop model was implemented, with a review dashboard for the sales team to approve AI-generated reports and lead scores.

    Cycle Time
    The monthly reporting cycle time was reduced from 5 days to 1 day, a 70% improvement. The AI system automates data collection, validation, and report generation, eliminating manual data entry and aggregation. The sales team spends 2 hours per week on review and approval, compared to 12 hours previously.

    Error Rate
    The error rate in monthly reporting decreased from 10% to 2%, an 80% reduction. The AI system validates data in real-time, flagging anomalies and inconsistencies. The human-in-the-loop model ensures that errors are caught and corrected before the report is finalized.

    Lead Qualification Accuracy
    Lead qualification accuracy improved from 70% to 95%, with a 25% increase in qualified leads passed to sales. The AI system scores leads based on predefined criteria, and the human-in-the-loop model ensures that misclassified leads are corrected. The sales team reports a 15% increase in conversion rates, attributed to more accurate lead qualification.

    GDPR Compliance
    The system is GDPR-compliant, with data processed on-premise and no personal data leaving the building. The legal basis for processing is documented, and data subjects can exercise their rights. The system uses open-weight models on the client’s own hardware, ensuring that regulated data does not leave the building.

    Lessons for Similar Teams

    The pilot demonstrated significant improvements in cycle time, error rate, and lead qualification accuracy. The system is GDPR-compliant and integrated with existing systems via APIs. The human-in-the-loop model ensures accuracy and compliance, while the model-agnostic architecture provides flexibility and future-proofing.

    Scalability
    The system can be scaled to automate other workflows, such as invoice processing and document extraction. The model-agnostic architecture allows for switching between different AI models, based on cost, performance, and compliance requirements. The system can be extended to other departments, such as marketing and customer service, with minimal changes.

    Cost Efficiency
    The pilot reduced manual back-office work by 80%, saving 10 hours per week. The cost of the AI system is offset by the reduction in manual effort and the increase in qualified leads. The system is cost-effective, with a payback period of less than 3 months.

    Risk Mitigation
    The human-in-the-loop model mitigates the risk of errors and ensures compliance with regulations. The model-agnostic architecture mitigates vendor lock-in and allows for future-proofing. The system is GDPR-compliant, with data processed on-premise and no personal data leaving the building.

    Next Steps
    The company plans to roll out the system to other departments, such as marketing and customer service. The system will be extended to automate other workflows, such as invoice processing and document extraction. The company will continue to measure the impact of the system on key metrics, such as cycle time, error rate, and lead qualification accuracy.

  • Fixed-Scope AI Pilot vs. Full Rollout: A Fintech’s 6-Month Decision

    What Is Being Compared: Fixed-Scope Pilot vs. Full-Scale Rollout

    The two options under comparison are a fixed-scope pilot and a full-scale rollout of AI automation across a 2,000+ employee fintech firm in the UK. The pilot targets one workflow — in this case, monthly reporting compilation and internal knowledge search over Notion and Confluence — with a 6-week delivery window, a measured before/after baseline on cycle time and error rate, and a go/no-go decision at the end. The full-scale rollout deploys AI process automation across multiple departments simultaneously: invoice processing, ticket triage for round-the-clock customer response, HR and recruiting workflow orchestration, and a retrieval-augmented assistant over the company’s documentation. Both options use the same underlying architecture: n8n for workflow orchestration, a model-agnostic AI layer (OpenAI or Anthropic APIs for non-regulated data, open-weight models on the client’s hardware for PCI DSS-sensitive data), and human-in-the-loop approval for anything touching money, contracts, or health data. The difference is scope, timeline, and risk exposure.

    Criteria for the Comparison

    The following criteria determine which option fits a fintech firm’s constraints. PCI DSS compliance is the hard gate: any workflow that touches cardholder data must run on-premises or in a PCI-compliant enclave, which rules out cloud-only model APIs for those specific flows. Cycle time reduction is measured in hours per report or per ticket, not in vague efficiency gains. Error rate is tracked as a percentage of transactions requiring manual correction. Integration depth counts the number of existing systems (CRM, ERP, helpdesk, Notion, Confluence) that the automation must connect to without replacing them. Vendor lock-in is assessed by whether the architecture can swap models or orchestration tools without rework. Timeline is the calendar duration from kickoff to managed operation. Cost is the total engagement fee plus ongoing managed operation, expressed in GBP. Scalability is the number of additional workflows or departments that can be added without rebuilding the core architecture.

    Comparison Table

    Criterion Fixed-Scope Pilot Full-Scale Rollout
    PCI DSS compliance One workflow isolated; open-weight model on-premises for cardholder data Multiple workflows; requires a PCI-compliant enclave for all payment-related flows
    Cycle time reduction Measured on one workflow (e.g., monthly reporting: 14 hrs → 2 hrs) Measured across 4-6 workflows; aggregate reduction depends on each workflow’s baseline
    Error rate Baseline established in week 1; target <2% by week 6 Baselines established per department; target <3% aggregate by month 4
    Integration depth 2-3 systems (Notion, Confluence, one CRM) 6-10 systems (CRM, ERP, helpdesk, Notion, Confluence, HRIS, payment gateway)
    Vendor lock-in Low; n8n workflows are portable; model can be swapped Moderate; more integrations increase switching cost, but n8n remains the orchestration layer
    Timeline 6 weeks to pilot completion; 2 weeks to decision 6 months to full managed operation across departments
    Cost (GBP) £18,000–£35,000 for the pilot £120,000–£250,000 for the full engagement plus £4,000–£8,000/month managed operation
    Scalability One workflow; scaling requires a new pilot per department Multi-department from day one; new workflows added to the existing n8n architecture

    When the Fixed-Scope Pilot Wins

    The fixed-scope pilot wins when the firm has not yet established a baseline for AI automation and needs to prove value before committing to a multi-department rollout. For a 2,000+ employee fintech in the UK, the pilot on monthly reporting and internal knowledge search over Notion and Confluence delivers a measurable result in 6 weeks: cycle time drops from 14 hours to 2 hours per report, and the error rate on data extraction falls from 8% to under 2%. The go/no-go decision is based on these numbers, not on a qualitative assessment. The pilot also validates the n8n orchestration layer and the human-in-the-loop approval gates without exposing the entire back office to change. If the pilot meets its targets, the firm has a proven template for the next workflow.

    The full-scale rollout wins when the firm has already completed a process audit, has identified 4-6 high-impact workflows, and has the IT capacity to manage parallel integrations. For a fintech with PCI DSS obligations, the rollout must include an on-premises open-weight model for any workflow that touches cardholder data, while non-regulated workflows (ticket triage, HR recruiting, knowledge search) can use OpenAI or Anthropic APIs. The 6-month timeline assumes that the process audit is complete, that the n8n environment is provisioned, and that each department has a named owner for the integration work. The rollout delivers aggregate cycle time reduction across the firm, but it requires a managed operation team from month 3 onward to handle model updates, integration drift, and new workflow requests.

    When the Full-Scale Rollout Wins

    The full-scale rollout is the right choice when the firm’s process audit has already identified multiple workflows with high impact and low integration complexity, and when the IT team can support parallel workstreams. For a 2,000+ employee fintech in the UK, this means the audit has scored invoice processing, ticket triage, HR and recruiting workflow orchestration, and internal knowledge search as the top four candidates. The rollout deploys all four within 6 months, with the PCI DSS-sensitive workflows (invoice processing, payment-related ticket triage) running on open-weight models on the client’s hardware, and the non-regulated workflows (HR recruiting, knowledge search) using OpenAI or Anthropic APIs. The n8n orchestration layer is shared across all workflows, so a change to one integration (e.g., a CRM API update) is applied once, not four times. The managed operation team, staffed from month 3, handles model retraining, integration monitoring, and new workflow requests. The cost is higher — £120,000 to £250,000 for the engagement plus £4,000 to £8,000 per month for managed operation — but the aggregate cycle time reduction across four workflows justifies the investment within 12 months for a firm of this size.

    Recommendation for the Scenario

    For a 2,000+ employee fintech in the UK with PCI DSS obligations, the recommendation is a fixed-scope pilot first, followed by a phased rollout. The pilot targets monthly reporting compilation and internal knowledge search over Notion and Confluence, with a 6-week delivery window and a measured baseline on cycle time and error rate. The pilot validates the n8n orchestration layer, the human-in-the-loop approval gates, and the model-agnostic architecture without exposing the payment processing workflows to change. If the pilot meets its targets — cycle time reduced from 14 hours to under 3 hours, error rate below 2% — the firm proceeds to a phased rollout over the remaining 4 months of the 6-month timeline. The rollout adds invoice processing, ticket triage for round-the-clock customer response, and HR and recruiting workflow orchestration, with PCI DSS-sensitive workflows running on open-weight models on the client’s hardware. The total engagement cost is £150,000 to £280,000, with managed operation at £5,000 to £8,000 per month from month 4 onward. This approach limits risk, delivers a measurable result in 6 weeks, and scales the architecture across departments without rebuilding it.

  • Swiss E-commerce Cuts Invoice Processing to 3 Hours with On-Premise AI

    Background: A Swiss E-commerce Operator at 300 Headcount

    This case study is a composite based on patterns observed across Forfis engagements. We do not name real customers. The company described here is a mid-sized Swiss e-commerce operator with roughly 300 employees, running a multi-channel retail operation across DACH and Western Europe. The stack is a mix of a legacy ERP for inventory and finance, a modern CRM for customer relationships, and a helpdesk platform for internal and supplier communications. The operations team handles 1,200 to 1,800 supplier invoices per month, plus a monthly consolidated report that feeds into the finance close. The company is in the AI-native operations stage: leadership has approved AI investment, but the team has not yet built internal capability to deploy and maintain AI workflows. The engagement ran over 8 weeks, delivered by a dedicated Forfis AI team embedded with the client’s operations group.

    Challenge: 12 Hours a Week of Manual Invoice Entry and a Fixed Monthly Close

    The operations team spent an estimated 12 to 15 hours per week on manual invoice processing: extracting line items from PDFs, matching them against purchase orders in the ERP, flagging discrepancies, and entering validated data. The monthly consolidated report required pulling data from three systems, reconciling it, and formatting it for the finance close. The error rate on the baseline was 4.2 percent on invoice line items, with a 3-day average cycle time from receipt to posting. The pressure was twofold: the monthly close deadline was fixed, and the team had lost two senior operators to attrition in the prior quarter. Leadership wanted to reduce manual back-office work without replacing the existing ERP or CRM, and without sending supplier or financial data to a third-party cloud. The compliance posture was internal: no regulatory mandate, but the finance director required that all financial data remain on-premise.

    Approach: On-Premise Open-Weight Models with a Human-in-the-Loop Approval Layer

    Forfis ran a two-week process audit to map the invoice workflow end-to-end and capture baseline metrics. The pilot scope was fixed: automate invoice extraction, PO matching, and discrepancy flagging, plus generate the monthly consolidated report from the same data pipeline. The architecture used open-weight models deployed on the client’s own hardware, so all invoice and financial data stayed on-premise. The AI layer connected to the ERP and helpdesk through custom REST APIs and webhooks: the ERP pushed new invoices via webhook, the AI service processed them, and validated records were written back through the ERP’s REST API. Discrepancies were pushed to the helpdesk as tickets for human review. The human-in-the-loop layer was built into the workflow: the model drafted and classified, a person approved anything touching a financial transaction. The dedicated Forfis team handled technical planning, product design, and full-cycle development over the 8-week timeline.

    Outcome: Cycle Time Down 75 Percent, Error Rate Under 1 Percent

    After the 8-week engagement, the measured results were: cycle time on invoice processing dropped from 12 to under 3 hours per week, a reduction of roughly 75 percent. The error rate on invoice line items fell from 4.2 percent to under 1 percent. The monthly consolidated report, which previously took 2 to 3 days of manual reconciliation, was generated automatically from the same data pipeline and required only a 30-minute human review. The human-in-the-loop approval queue handled roughly 8 to 12 percent of invoices that required manual review, down from 100 percent. The operations team redirected the freed capacity to supplier relationship management and exception handling. The finance director confirmed that all data remained on-premise throughout the pilot and rollout, and the monthly close process was unchanged in structure but faster in execution. The system is now in managed operation with Forfis monitoring model performance and handling drift.

    Lessons for Similar Teams

    • Baseline before you build. The 4.2 percent error rate and 12-hour cycle time were captured during the audit, not estimated. Without that baseline, the outcome metrics would be unverifiable. Any team automating a back-office workflow should measure the current state before touching the process.
    • One workflow, not five. The pilot scope was fixed to invoice processing and monthly reporting. Attempting to automate the entire back-office in 8 weeks would have diluted the team’s focus and made the baseline unmeasurable. Sequence the rollout: prove one workflow, then expand.
    • On-premise is not a constraint, it is a design choice. The open-weight model on the client’s hardware was not a compromise. It was the right fit for the data residency requirement, and the model-agnostic architecture meant the team could swap models without re-architecting the integration layer.
    • Human-in-the-loop is the default, not a fallback. The approval layer was built into the workflow from day one, not added after a failure. The 8 to 12 percent manual review rate is a feature, not a bug: it keeps the team in control of financial transactions while the AI handles the volume.
    • Integration through existing APIs, not replacement. The custom REST API and webhook layer connected to the ERP and helpdesk without requiring data migration. This kept the project within the 8-week timeline and avoided the risk of a parallel system.

  • AI Candidate Screening and HR Reporting for a UK Insurance Firm: A 3-Month Pilot

    The Problem: Scaling HR Operations Without New Hires

    A 2,000+ employee insurance firm in the UK faces a familiar constraint: HR and recruiting teams are stretched thin, and the volume of candidate applications and monthly reporting cycles keeps growing without a corresponding increase in headcount. The firm needs to process more applications, produce more reports, and maintain compliance with GDPR Article 22 on automated decision-making, all within a 3-month window. The solution is not a new HR platform or a full AI transformation. It is a fixed-scope pilot that automates one or two specific workflows, measures the impact, and establishes a foundation for scaling across departments. The pilot targets candidate screening and monthly reporting, using a retrieval-augmented knowledge assistant that reads from the firm’s existing Confluence or Notion workspace. The architecture is model-agnostic: OpenAI or Anthropic APIs for tasks where output quality matters, and open-weight models on the firm’s own hardware for any data that cannot leave the building. The pilot ships with a measured before/after baseline on cycle time and error rate, so the business case is quantified, not assumed.

    Pilot Scope: Candidate Screening and Monthly Reporting

    The pilot begins with a process audit that maps the current candidate screening workflow end to end. The team identifies where manual effort concentrates: parsing application PDFs, matching candidates against job descriptions, flagging compliance issues, and drafting initial feedback. The same audit covers the monthly reporting cycle, which typically involves pulling data from the HR system, formatting it into a template, and writing narrative summaries. The data sources are the firm’s existing Confluence or Notion workspace, which holds job descriptions, screening criteria, and reporting templates. The assistant connects to these platforms through their public APIs, so the HR team continues to maintain content where it already lives. The architecture uses pgvector for embeddings search, storing vector representations of the source documents in a PostgreSQL instance on the firm’s own infrastructure. This keeps the data within the firm’s control, which matters for an insurance company handling regulated data. The model layer is deliberately model-agnostic: the pilot uses OpenAI or Anthropic APIs for drafting and classification tasks, and open-weight models on the firm’s hardware for any step that touches sensitive candidate data.

    Human-in-the-Loop and GDPR Compliance

    The assistant does not make final decisions on candidates. It classifies applications against the screening criteria stored in Confluence, ranks them, and drafts a summary for the recruiter to review. A human recruiter approves or overrides every screening decision before it reaches the candidate. This human-in-the-loop design satisfies GDPR Article 22, which requires human involvement in automated decisions with legal or similarly significant effects. The same principle applies to monthly reporting: the assistant assembles the data, formats the report, and drafts the narrative sections, but a human analyst reviews and approves the final document before distribution. Every pilot ships with a measured before/after baseline. The baseline captures cycle time, the time from application receipt to screening decision, and error rate, the percentage of screening decisions that a human reviewer would overturn. The baseline is measured during the first two weeks of the pilot, before the AI is fully active, so the comparison is direct. The firm gets a quantified picture of the impact, not a qualitative impression.

    3-Month Timeline and Delivery Phases

    The 3-month timeline breaks into three phases. Weeks 1 to 4 cover the process audit and data mapping: the team interviews HR and recruiting staff, maps the current workflow, identifies the data sources in Confluence or Notion, and defines the success metrics. Weeks 5 to 8 are development and integration: the team builds the retrieval-augmented assistant, connects it to the HR system and the documentation platform, and configures the model layer. Weeks 9 to 12 are user testing and measurement: the HR team uses the assistant in a live environment, the team captures the before/after baseline, and the firm makes a go/no-go decision on broader rollout. The pilot covers one or two workflows, not the entire HR function. The output is a working system, a measured baseline, and a clear picture of what scaling across departments would look like. The architecture is designed so that the next department, whether it is claims processing or customer service, plugs into the same stack without rebuilding from scratch.

    Scaling Across Departments After the Pilot

    The pilot is not the end of the engagement. It is the first step in scaling AI across departments. The architecture established in the pilot, the model-agnostic layer, the human-approval workflow, the pgvector embeddings search, and the measurement framework, is reusable. When the firm decides to extend the assistant to claims processing or customer service, the team reuses the same integration patterns and the same compliance controls. The marginal cost and time for each new use case is lower than the initial pilot because the foundational work is already done. The firm also gets a managed operation model: the team monitors the assistant, handles model updates, and maintains the integration with the HR system and documentation platform. This is not a one-off project; it is a managed service that scales with the firm’s needs. The 3-month pilot gives the firm a quantified business case, a working system, and a clear path to scaling without new hires.

  • Automating Lead Qualification and Reporting for German Healthcare Companies

    The Problem: Manual Lead Qualification in German Healthcare

    You run a 51-200 person healthcare or medtech company in Germany. Your marketing and content team handles lead qualification manually, sifting through inbound inquiries to determine which leads are worth pursuing. This process is slow, error-prone, and scales poorly as your lead volume grows. You want to automate this workflow without hiring new staff, but you also need to comply with GDPR, especially when handling data that touches patient information or health records. The challenge is to build a system that extracts data from unstructured documents, qualifies leads using a conversational agent, and generates monthly reports, all within a three-month timeline. The solution must integrate with your existing tools, such as Notion or Confluence, and operate within your infrastructure to ensure data residency and compliance. This guide outlines the steps to achieve this using a dedicated AI team and a model-agnostic architecture.

    Prerequisites: What You Need Before Starting

    Before you begin, you need to have the following in place:

    • Access to your existing tools: API keys for your CRM, ERP, helpdesk, and Notion or Confluence instances. Ensure these APIs are enabled and that you have the necessary permissions to read and write data.
    • Documentation in a structured format: Your product documentation, pricing sheets, and qualification criteria should be stored in Notion or Confluence. The more structured and up-to-date this content is, the better the agent will perform.
    • A clear definition of lead qualification: Define what constitutes a qualified lead. Include criteria such as company size, industry, budget, and timeline. This will guide the agent’s classification logic.
    • GDPR compliance framework: Ensure you have a data protection officer (DPO) or legal counsel who can review the data processing activities. You need to define data retention policies and consent mechanisms for any personal data collected.
    • Infrastructure for open-weight models: If you plan to use open-weight models for regulated data, you need a server or cloud instance with sufficient GPU resources. This ensures that sensitive data does not leave your infrastructure.
    • A dedicated AI team: Engage a team with experience in AI automation, document extraction, and conversational agents. The team should be familiar with GDPR requirements and the specific needs of the healthcare industry.

    Step 1: Audit Your Current Lead Qualification Process

    The first step is to audit your current lead qualification process. Identify the workflows that are most time-consuming and error-prone. For example, if your team spends hours manually extracting data from PDFs and emails, this is a prime candidate for automation. The dedicated AI team will work with you to map out the current process, including the tools used, the data sources, and the decision points. This audit will help you define the scope of the pilot and establish a baseline for cycle time and error rate. Use a simple spreadsheet or a tool like Notion to document the current process. Include metrics such as the average time to qualify a lead, the error rate in data entry, and the number of leads processed per month. This baseline will be used to measure the impact of the automation.

    Step 2: Build the Document and Data Extraction Pipeline

    The second step is to build the document and data extraction pipeline. This pipeline will extract structured data from unstructured documents such as PDFs, emails, and CRM records. The team will use OCR and NLP models to identify key fields like company name, contact details, and intent signals. The extracted data will be stored in a database, such as PostgreSQL, with a pgvector extension for vector search. This allows the conversational agent to retrieve relevant context from your documentation. The pipeline will be configured to handle the specific document types and formats used in your organization. For example, if you receive many PDFs from healthcare providers, the pipeline will be tuned to extract data from these documents accurately. The team will test the pipeline with a sample set of documents to ensure accuracy and adjust the models as needed.

    Step 3: Develop the Conversational Agent for Lead Qualification

    The third step is to develop the conversational agent for lead qualification. The agent will interact with inbound leads, asking structured questions to determine fit, budget, and timeline. It will classify the lead into a priority tier and draft a personalized response based on the retrieved context from your Notion or Confluence documentation. The agent will use a retrieval-augmented generation (RAG) approach, querying the pgvector database to find relevant information. This ensures that the agent’s responses are grounded in your specific business context. The team will configure the agent to handle common questions and edge cases, such as leads asking about pricing or compliance. The agent will be tested with a set of sample conversations to ensure it handles these scenarios correctly. The team will also set up a human-in-the-loop mechanism, where a human reviewer approves any response that touches sensitive topics or high-value leads.

    Step 4: Automate Monthly Reporting with Extracted Data

    The fourth step is to automate the monthly reporting process. The system will extract data from your CRM, helpdesk, and marketing platforms. It will aggregate key metrics such as lead volume, conversion rates, and response times. The system will generate a draft report using the extracted data and your predefined templates in Notion or Confluence. A human reviewer will check the report for accuracy and add qualitative insights before it is finalized. This process reduces the time spent on manual data entry and formatting, allowing your team to focus on analysis and strategy. The report will be generated automatically on a scheduled basis, ensuring consistency and timeliness without additional headcount. The team will configure the reporting pipeline to pull data from the relevant sources and format it according to your templates. They will test the pipeline with a sample month of data to ensure the report is accurate and complete.

    Step 5: Ensure GDPR Compliance and Data Residency

    The fifth step is to ensure GDPR compliance throughout the system. All personal data will be processed within EU-based infrastructure, and data residency will be enforced by keeping regulated data on your own hardware using open-weight models. The system will log all data access and processing activities, providing an audit trail for compliance reviews. Data minimization will be applied by extracting only the necessary fields from documents, and data retention policies will be enforced automatically. The human-in-the-loop design will ensure that any data touching health records or sensitive personal information is reviewed by a human before further processing. The team will work with your DPO or legal counsel to review the data processing activities and ensure compliance with GDPR. They will document the data flow and the measures taken to protect personal data, creating a compliance report that can be used for audits.

  • 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.