Forfis Blog

Tag: Replace Manual Data Entry

  • AI Contract Review Rollout for US Fintechs: A 12-Point ISO 27001 Checklist

    12-Point Checklist for a Compliance-Safe AI Contract Review Rollout

    1. Verify the scope of the contract review workflow.
      Define the specific contract types, clause categories, and approval thresholds for the pilot.

    2. Document the baseline cycle time and error rate.
      Sample 50-100 historical contracts to measure manual review time and error frequency.

    3. Map the data flow from source to destination.
      Identify where contracts originate, how they are stored, and where reviewed data is sent.

    4. Select the open-weight model for on-premise deployment.
      Choose Llama 3 or Mistral based on contract complexity and hardware constraints.

    5. Configure the model serving infrastructure.
      Deploy vLLM or TGI on the client’s GPU cluster to ensure data never leaves the building.

    6. Integrate the AI system with Confluence or Notion.
      Use APIs to pull contract templates, store drafts, and log approval decisions.

    7. Define the human-in-the-loop approval workflow.
      Specify which clauses require human review and how approvers are notified.

    8. Implement data enrichment and cleanup rules.
      Configure extraction, classification, and deduplication logic for contract fields.

    9. Set up access controls and audit trails.
      Map each AI component to ISO 27001 controls, including A.8.2.2 and A.12.4.1.

    10. Test the end-to-end workflow with sample contracts.
      Run 10-20 test contracts through the full pipeline to validate accuracy and latency.

    11. Train the legal and compliance team on the new workflow.
      Provide documentation and a 2-hour training session on using the AI-assisted review tool.

    12. Schedule the post-implementation metrics review.
      Plan a 2-week check-in to compare cycle time and error rate against the baseline.

    Maintaining the Checklist Over Time

    The checklist above is a living document. After the pilot concludes, review which items were completed, which were skipped, and why. Update the checklist to reflect lessons learned, such as new clause types or changed approval thresholds. Assign a single owner for the checklist, typically the project lead, and review it quarterly to ensure it remains aligned with the company’s compliance requirements and operational changes. This maintenance process ensures that the checklist continues to serve as a reliable guide for future AI rollouts.

    Timeline and Scope Considerations

    The 4-week timeline is aggressive but achievable for a single, well-scoped pilot. Weeks 1-2 focus on the process audit, data mapping, and environment setup. Weeks 3-4 cover model fine-tuning, integration with Confluence or Notion, and the human-in-the-loop approval workflow. This timeline assumes the client has already identified the specific contract types and has access to historical data for baseline measurement. If the scope expands or the data is not ready, the timeline will slip, so it is critical to lock the scope during the audit phase.

  • 14-Day AI Pilot Checklist for Fintech Order and Shipment Status Updates

    1. Map the current order and shipment workflow

    Before any model touches a document, the team maps the current workflow end to end. For a 201-500 person fintech firm handling order and shipment status updates, this means identifying every touchpoint where a human reads a PDF, CSV, or email attachment, extracts an order ID or tracking number, and types it into the CRM or ERP. The audit also captures the customer-facing side: how many order status queries arrive per day, what channels they come through (email, chat, phone), and what the current first-response time is. The output is a one-page process map with cycle time and error rate baselines. This map becomes the acceptance criteria for the pilot. Without it, the 14-day window has no measurable target.

    2. Build the document extraction pipeline

    The extraction pipeline ingests documents from Google Drive and Gmail. For a fintech operations team, the typical inputs are order confirmations, shipment manifests, and carrier tracking updates. The pipeline uses OCR or structured parsing to pull out order IDs, tracking numbers, and status codes, then applies a validation rule set to flag anomalies. The Anthropic Claude API handles the classification step: it reads the extracted text and assigns a status category (e.g., “shipped,” “in transit,” “delivered”). The rule set is deterministic; the model only classifies. This keeps the extraction layer auditable and the error rate measurable.

    3. Configure the customer-facing assistant

    The assistant layer uses the Anthropic Claude API to generate natural-language responses to customer queries about order and shipment status. It pulls data from the CRM or ERP via API, formats the response, and sends it through the existing helpdesk or email channel. The system is configured to handle 24/7 queries, but it does not process payments, issue refunds, or modify contract terms. Any query that touches money or a contract routes to a human agent. The assistant is a lookup and response tool, not a transaction processor. This boundary is hard-coded into the prompt and the escalation logic.

    4. Wire the integration to Google Workspace and the CRM

    The assistant and extraction pipeline write to and read from the existing CRM, ERP, and helpdesk through their native APIs. No new infrastructure is required. For a fintech firm using Google Workspace, the integration points are Gmail (for inbound queries and document attachments), Google Drive (for document storage), and the CRM or ERP API (for order and shipment data). The dedicated AI team handles all wiring: OAuth tokens, API rate limits, and error handling. The system plugs into what the firm already runs. It does not replace the CRM, ERP, or helpdesk. It adds an AI layer on top.

    5. Run parallel tests against live data

    Days 9-11 of the pilot run the system in parallel with the existing manual process. The team feeds live order and shipment documents through the extraction pipeline and compares the output against the human-entered data. The assistant handles live customer queries and the team measures first-response time and accuracy. The human-in-the-loop approver reviews every output that touches money, health data, or a contract. The goal is not to prove the system works in a vacuum. The goal is to measure the delta: cycle time reduction, error rate change, and first-response improvement against the baseline captured in step 1.

    6. Validate, fix edge cases, and hand over the runbook

    Days 12-14 are for fixing edge cases, tuning the classification rules, and writing the operating runbook. The runbook documents: how to monitor the extraction pipeline, how to escalate assistant queries to a human, how to update the validation rule set, and how to measure the before/after metrics. The dedicated AI team hands over the runbook and the measured baseline. The pilot is a one-time deliverable. The runbook is what keeps the system running after the team leaves. Without it, the 14-day investment decays within a month.

  • AI Workflow Automation for German Logistics: 3-Month GDPR-Compliant Pilot

    The Bottleneck: Manual Data Entry in Logistics Compliance

    A 51-200 employee logistics firm in Germany faces a specific bottleneck: legal and compliance teams spend 12-18 hours per week manually extracting data from shipping documents, carrier contracts, and regulatory filings. This manual work creates two problems. First, error rates of 5-10% in data entry lead to billing disputes and compliance violations. Second, document turnaround times of 48-72 hours delay contract approvals and shipment releases. The firm has identified this workflow as high-value for automation but has not yet scaled AI beyond isolated pilots. The goal is to replace manual data entry with an AI layer that extracts, enriches, and cleans data, while providing legal teams with a semantic search tool over internal documentation. The engagement is a 3-month integration sprint with a fixed scope: one workflow, measured baselines, and human-in-the-loop approval for anything touching contracts or personal data.

    Integration Sprint: Custom REST APIs and Webhooks

    The architecture is deliberately model-agnostic and integrates with existing systems via custom REST APIs and webhooks. For document extraction, the system uses OpenAI or Anthropic APIs where quality matters, and open-weight models on the client’s own hardware where GDPR data residency requirements apply. The AI layer connects to the firm’s ERP, CRM, and document management system through their native APIs, not by replacing them. Webhooks ensure the system reacts to new documents within seconds, not hours. The data flow is: document receipt via webhook, LLM extraction and classification, human approval for contract or personal data, and write-back to the ERP via REST API. This keeps the integration reversible and limits the blast radius of any model error. The system is designed for a 51-200 employee firm, so the API surface is minimal: three endpoints for document ingestion, approval, and data write-back.

    pgvector Embeddings Search for Internal Knowledge

    The internal knowledge search assistant uses pgvector, a PostgreSQL extension that stores vector embeddings of internal documents. Legal and compliance teams query it in natural language and get relevant passages with citations. For example, a query like “What are the liability limits for cross-border shipments under the CMR Convention?” returns the exact clause from the carrier contract, not just a keyword match. The indexing process chunks documents into 512-token passages, embeds them using a multilingual model, and stores the vectors in pgvector. Search latency is under 18 ms for a corpus of 5,000 documents. This reduces the time legal teams spend searching for clauses from 45 minutes to 4 minutes per query. The assistant is read-only and does not modify documents, which simplifies GDPR compliance since no personal data is processed during search.

    Data Enrichment and Cleanup: Replacing Manual Entry

    Data enrichment and cleanup are the core automation tasks. Enrichment adds missing fields to existing records: GPS coordinates to warehouse addresses, carrier codes to shipment records, and regulatory classifications to product descriptions. Cleanup corrects errors and standardizes formats: normalizing inconsistent carrier names, fixing date formats, and resolving duplicate records. The LLM drafts the enrichment and cleanup, a human approves it, and the system writes the data to the ERP via API. For a logistics firm, this reduces error rates from 5-10% to under 1% and cuts processing time by 70-80%. The human-in-the-loop approval is mandatory for anything touching money, health data, or contracts, which aligns with GDPR Article 5 data minimization and purpose limitation requirements. The system logs every approval decision for audit purposes.

    GDPR Compliance for AI Document Processing

    GDPR compliance is the primary regulatory constraint for a German logistics firm. Article 5 requires data minimization and purpose limitation, so the AI must not process personal data without a legal basis. If the system handles personal data in shipping documents, the firm must document the legal basis, implement access controls, and ensure the model provider is a data processor under a DPA. For regulated data that cannot leave the building, open-weight models on client hardware satisfy this requirement. The system implements role-based access control, encryption at rest and in transit, and audit logging. Every model inference is logged with the input, output, and approval decision. This creates a complete audit trail for GDPR Article 30 records of processing activities. The firm’s DPO reviews the system before rollout and signs off on the data processing agreement.

    3-Month Timeline: From Pilot to Measured Baseline

    The 3-month timeline is realistic for a single workflow pilot with measured baselines. Week 1-2: process audit and baseline capture. The team documents the current manual process, measures cycle time and error rate, and identifies the specific documents and data fields to automate. Week 3-8: build and test the AI layer with human-in-the-loop approval. The system is deployed in a staging environment, tested against historical documents, and tuned for accuracy. Week 9-12: rollout, error-rate tracking, and before/after comparison. The system goes live, and the team tracks cycle time, error rate, and user adoption. The baseline is measured before the pilot and compared after rollout. For a 51-200 employee firm, this timeline assumes the client’s APIs are documented and accessible, and that the legal team is available for approval during business hours. The fixed scope prevents scope creep and ensures the pilot delivers measurable results.

  • UK Fintech AI Lead-Qualification Checklist: 15 Steps for a 3-Month Pilot

    1. Audit the Current Lead-Qualification Workflow

    Start by mapping the current lead-qualification workflow end-to-end. Identify every touchpoint where a human manually enters data, classifies intent, or drafts a response. Document the average cycle time from ‘lead submitted’ to ‘qualified’ and the error rate on misclassified leads. This baseline is the anchor for the pilot’s before/after report. Without it, you cannot prove the AI agent delivers measurable value. The audit also flags which workflows are worth automating and which are too complex for a 3-month pilot. For a 201-500 person fintech, this typically means focusing on one high-volume, low-complexity workflow, such as inbound lead triage from a marketing form.

    2. Define the Pilot Scope and Success Metrics

    Define the exact scope of the pilot before writing a single line of code. The pilot should cover one workflow, one integration, and one success metric. For lead qualification, this means the agent handles inbound leads from a specific channel, integrates with one CRM, and measures cycle time reduction. Avoid scope creep by documenting what is out of scope, such as multi-channel routing or contract drafting. The fixed scope keeps the 3-month timeline realistic and ensures the pilot report is actionable. For a fintech team, this also means defining the human-in-the-loop approval step: the agent drafts, a rep approves, and the system logs the approval with a timestamp and user ID.

    3. Map ISO 27001 Controls to the AI Layer

    Map every data flow that touches the AI agent against ISO 27001 Annex A controls. Identify where PII enters the system, how it is stored, and when it is deleted. For a fintech agent, this means ensuring transaction data and customer identifiers are not logged in model weights or sent to unapproved endpoints. Document the access controls: who can view agent logs, who can approve responses, and how incidents are escalated. The audit trail must show that every interaction is logged, every approval is timestamped, and every data deletion is recorded. This documentation is what your ISO 27001 assessor will review, so it must be complete and current before the pilot goes live.

    4. Configure the Anthropic Claude API and Integration Layer

    Configure the Anthropic Claude API endpoint with the appropriate model and temperature settings for lead qualification. For a fintech agent, use a model that handles nuanced intent classification and drafts professional first-response emails. Set the temperature low, around 0.2 to 0.3, to reduce hallucination risk. Implement rate limiting and error handling so the agent degrades gracefully if the API is down. The integration layer should plug into your existing CRM and helpdesk through their APIs, not replace them. This means the agent reads lead data from the CRM, writes qualified leads back, and logs every interaction in the helpdesk. The model-agnostic design means you can swap to an open-weight model on your own hardware if regulated data cannot leave the building.

    5. Integrate with Notion or Confluence for Knowledge Grounding

    Connect the agent to your Notion or Confluence workspace through their APIs so it can pull documentation, product specs, and compliance policies. This grounds the agent’s responses in your current content, not generic AI output. For a marketing and content team, this means the agent can reference the latest product page, pricing sheet, or compliance FAQ when drafting a first-response email. When marketing updates a page in Notion, the agent’s knowledge base updates automatically without manual retraining. This reduces the risk of the agent providing outdated information, which is a critical concern in fintech where compliance and accuracy are non-negotiable. The integration should be tested with a sample of 50 real leads before the pilot goes live.

    6. Build the Conversational Agent with Human-in-the-Loop Approval

    Build the conversational agent with a clear human-in-the-loop approval step. The agent drafts the response and classifies the lead, but a human must approve anything that touches money, health data, or a contract. In a fintech lead-qualification context, this means the agent can tag a lead as ‘high-intent’ and draft a follow-up email, but a sales rep must click ‘send’ before it goes out. The approval step is logged with a timestamp and user ID for audit purposes. The agent should also flag leads that require human review, such as those with compliance questions or high transaction volumes. This ensures the AI layer accelerates the workflow without bypassing the controls your ISO 27001 certification requires.

    7. Run the Pilot and Measure Before/After Baselines

    Run the pilot for 4 to 6 weeks with a small group of sales reps. Track cycle time, error rate, and rep satisfaction daily. Compare the pilot results against the baseline captured in the process audit. If the agent reduces cycle time by 40% and error rate by 25%, the business case for rollout is quantified. Document any edge cases where the agent misclassified a lead or drafted an inappropriate response. These edge cases inform the prompt tuning and approval rules for the rollout phase. The pilot report should include a recommendation on whether to proceed to rollout, what changes are needed, and what the managed operations plan looks like. For a 201-500 person fintech, this report is the decision point for scaling the AI layer across the sales and marketing teams.

  • Retrieval-Augmented Candidate Screening: A 4-Week Pilot for Austrian Healthcare

    1. Replace Manual Data Entry First

    Most companies that automate candidate screening start by replacing the manual data entry step. Recruiters spend 2-3 hours per week copying data from resumes into their ATS. A retrieval-augmented assistant built on pgvector can extract structured fields (name, experience, certifications) and classify candidates against your job description in under 18 seconds per application. The human-in-the-loop design means a recruiter approves or rejects each classification before it touches the hiring pipeline. This single process automation reduces cycle time by 40-60% and eliminates transcription errors, giving you a measurable baseline before you consider expanding to other workflows.

    2. Build EU AI Act Compliance Into the Pilot

    The EU AI Act, which entered into force in August 2024, classifies AI systems that make decisions affecting individuals as high-risk. Candidate screening tools that process personal data and influence hiring decisions fall squarely into this category. Article 10 requires data governance, Article 13 mandates transparency, and Article 14 demands human oversight. Forfis builds these controls into the pilot from day one: every classification is logged, every decision is auditable, and no candidate is screened out without human review. This is not a compliance checkbox added at the end; it is the architecture of the system.

    3. Use pgvector for Grounded Answers

    pgvector is a PostgreSQL extension that stores vector embeddings and performs similarity search. For a 501-2000 employee company, this means you can run your RAG pipeline on the same database as your transactional data, avoiding the cost and complexity of a dedicated vector database. The assistant embeds your job descriptions, screening criteria, and past hiring decisions into pgvector. When a new application arrives, the system retrieves the most relevant chunks and feeds them to an LLM, which generates a classification grounded in your data. This reduces hallucinations and keeps answers current as your criteria change.

    4. Integrate With Your Existing ATS via REST APIs

    The assistant connects to your ATS, HRIS, or recruitment platform via their REST APIs. Webhooks trigger the screening workflow when a new application arrives. The system extracts structured data from resumes, classifies candidates, and writes results back to your existing system. No replacement of your current tools is required. The architecture is deliberately model-agnostic: OpenAI or Anthropic APIs where quality matters, open-weight models on your own hardware where regulated data cannot leave the building. This means you can switch models without rebuilding the pipeline, and you can keep candidate data within your infrastructure if required.

    5. Ship a Measurable Result in 4 Weeks

    A 4-week timeline is realistic for a single-process pilot. Week 1: process audit and baseline measurement. Week 2: build the RAG pipeline and API integration. Week 3: test with real data and tune the model. Week 4: measure results, document findings, and hand over. This assumes your APIs are accessible and your data is in a usable format. The pilot ships with a report showing whether the automation meets the agreed thresholds on cycle time and error rate before you commit to rollout. This fixed-scope approach protects you from scope creep and ensures you have a measurable result before expanding to other workflows.

    6. Keep Humans in the Loop for High-Risk Decisions

    The assistant drafts a shortlist of candidates based on your job description and screening criteria. A recruiter reviews each draft, approves or rejects the classification, and the system logs the decision. This human-in-the-loop design ensures no candidate is screened out without human review, satisfying EU AI Act requirements for high-risk AI systems. The model classifies, the person decides. This is not a limitation; it is the correct architecture for a regulated environment. Every pilot ships with a measured before/after baseline on cycle time and error rate, so you know exactly what the automation achieved and where human judgment still adds value.

  • Voice Agent and Knowledge Search for a 20-Person B2B SaaS Team in Germany

    1. Start with a measured baseline, not a model demo

    The first thing Forfis does in a process audit is measure the baseline. For a 20-person B2B SaaS company in Germany, that means shadowing the support team for two weeks and logging every inbound ticket, its category, the time to first response, and the number of manual data-entry steps before a human agent touches it. The audit also maps which workflows touch regulated data. If the company handles customer health records or payment information, the data residency requirement is documented before any model is selected. This step takes three weeks and produces a ranked list of workflows by volume and error rate. The voice agent for inbound support and the internal knowledge search over Google Workspace documents typically top that list for a B2B SaaS team of this size, because both workflows are high-volume, repetitive, and currently handled entirely by hand.

    2. Scope the pilot to one workflow, not a platform

    The fixed-scope pilot runs for four to six weeks on a single workflow. For the voice agent, the scope is defined as: answer inbound support calls in English, classify the ticket type, draft a first response, and route it to the correct queue in the existing helpdesk. The human-in-the-loop layer is active from day one. Any response that touches a contract, a payment, or a health record requires explicit human approval before it is sent. The pilot ships with a before/after comparison on cycle time and error rate. In a typical engagement, the voice agent reduces average handle time by 40 to 60 percent and cuts the first-response error rate by a measurable margin. The cost per support ticket drops because the agent handles the first 60 to 70 percent of inbound calls without a human agent picking up the phone. The pilot is not a proof of concept; it is a production system with a measured baseline.

    3. Run the knowledge search on open-weight models, on-premise

    The internal knowledge search is a retrieval-augmented assistant built over the company’s own documentation, CRM records, and Google Workspace content. The agent indexes Gmail threads, Google Docs, shared drives, and the CRM’s ticket history. When a support agent or an internal user asks a question, the system retrieves the relevant passages and grounds the answer in that content rather than in the model’s training data. This is where the open-weight model on the client’s own hardware becomes the default choice. German data protection rules and ISO 27001 information security controls require that regulated data does not leave the building. The model runs on the client’s hardware, the API keys are managed locally, and the audit log records every query and every retrieved passage. The integration sprint includes a security review of the data flow, so the compliance posture is documented before the system goes live.

    4. Plug into the helpdesk and Google Workspace, not around them

    The voice agent connects to the existing helpdesk through its API. Tickets created by the agent appear in the same queue the human agents already use, with the same priority and SLA fields. Google Workspace integration means the agent can pull context from Gmail threads and shared documents to ground its responses. The agent does not replace the helpdesk; it plugs into it. The same applies to the ERP and the CRM. The integration sprint is built around the APIs the company already uses, not around a new middleware layer. For a 20-person team, this matters because there is no dedicated IT department to maintain a separate AI platform. The agent is a component of the existing stack, not a new stack. The managed operation phase includes monitoring the API connections, updating the retrieval index when new documents are added to Google Workspace, and adjusting the classification thresholds based on the error rate data from the pilot.

    5. Ship the pilot in three months, not six

    The three-month timeline breaks down as follows. Weeks one through three: process audit, baseline measurement, model selection, and security review. Weeks four through nine: fixed-scope pilot on the voice agent, with the human-in-the-loop layer active and the before/after metrics tracked daily. Weeks ten through twelve: rollout to the internal knowledge search, integration with Google Workspace and the CRM, and the start of managed operation. The managed operation phase includes a 30-day post-rollout measurement window where the same cycle time and error rate metrics are tracked. The deliverable at the end of month three is not a report; it is a running system with a measured baseline, a documented security posture, and a clear path to expand to additional workflows. The integration sprint model means the scope is fixed at the start, so the timeline is not subject to scope creep. If the company wants to add invoice processing or document extraction, that is a second sprint, not a change order on the first.

    6. The synthesis: one sprint, two systems, one measured baseline

    The voice agent and the internal knowledge search are not separate projects; they share the same retrieval layer and the same human-in-the-loop approval mechanism. The voice agent uses the knowledge search to ground its responses in the company’s own documentation. The knowledge search uses the voice agent’s classification data to improve its retrieval ranking over time. For a 20-person B2B SaaS team, this means one integration sprint delivers two working systems instead of two separate projects. The cost per support ticket drops because the agent handles the first response. The internal data entry that used to take a human agent ten to fifteen minutes per ticket is now handled by the retrieval layer in under two seconds. The ISO 27001 compliance posture is documented in the security review, and the open-weight model on the client’s hardware ensures that regulated data stays in the building. The result is a system that runs on the existing stack, measures its own performance, and hands off to a human whenever the output touches money, health data, or a contract.

  • AI Contract Review for UAE Logistics: Cutting Cost per Ticket

    The Cost of Manual Data Entry in Logistics

    A 15-person logistics firm in the UAE faces a common problem: manual data entry and contract review consume a disproportionate amount of support agent time. Each shipment dispute or carrier contract requires an agent to extract details from PDFs, verify terms, and input data into the ERP. This process is slow, error-prone, and expensive. The cost per support ticket is high because agents spend 40-60% of their time on manual data entry rather than resolving complex issues. The goal is to reduce this cost by automating the initial extraction and classification, allowing agents to focus on high-value decisions. This is where AI-native operations come in: using AI to handle the repetitive, low-value tasks and freeing up human capacity for complex problem-solving. The approach is not to replace the entire workflow but to augment it with AI where it adds the most value.

    Process Audit: Identifying the Right Workflows

    The first step is a process audit that maps out the current workflow and identifies the highest-impact use cases. For a logistics firm, this typically means contract review and shipment dispute handling. The audit involves shadowing agents, reviewing sample documents, and measuring the current cycle time and error rate. This baseline is critical because it provides a measurable target for the pilot. The audit also identifies which data fields are most critical and which systems need to be integrated. For example, the AI might need to pull shipment details from the TMS, verify terms against the carrier contract, and send the results to the ERP. This audit takes 2-3 weeks and is the foundation for the entire integration sprint. Without a clear baseline, it is impossible to measure the ROI of the AI deployment.

    Pilot: Contract Review with Anthropic Claude API

    The pilot focuses on a single workflow: contract review. The AI uses Anthropic Claude API to extract key fields from carrier contracts, such as SLA terms, penalty clauses, and liability limits. The model is fine-tuned on a sample of historical contracts to improve accuracy. The output is a structured JSON object that the ERP can consume directly. The human-in-the-loop model ensures that any contract with high-risk terms is flagged for human review. The pilot runs for 6-8 weeks and is measured against the baseline from the process audit. The key metrics are cycle time (time to review a contract) and error rate (percentage of contracts with incorrect field extraction). The goal is to reduce cycle time by 50% and error rate by 30%. The pilot is a fixed-scope engagement, meaning the team delivers a specific, measurable outcome within a set timeframe.

    Model-Agnostic Architecture and Integration

    The architecture is deliberately model-agnostic, allowing the firm to use different AI models for different tasks. For contract review, Anthropic Claude API is used because it provides high-quality extraction and classification. For processing regulated data that cannot leave the building, an open-weight model is deployed on the firm’s own hardware. This flexibility ensures that the firm can optimize for both quality and compliance. The AI system integrates with existing systems through custom REST APIs and webhooks. This means the AI can pull data from the TMS, verify terms against the carrier contract, and send the results to the ERP without requiring the firm to replace its existing infrastructure. The integration approach ensures that the AI works with the firm’s current tools rather than replacing them, reducing the risk and cost of deployment.

    Rollout and Managed Operation

    After the pilot, the firm rolls out the AI system to additional workflows, such as shipment dispute handling and predictive scoring for delivery delays. The predictive scoring model uses historical data to assign a probability to future events, such as the likelihood of a shipment missing its delivery window. This allows the firm to proactively address potential issues before they become support tickets. The managed operation phase involves monitoring the AI system, fine-tuning the models, and ensuring that the human-in-the-loop model is working effectively. The firm measures the cost per support ticket and the error rate on a monthly basis to ensure that the AI system is delivering the expected ROI. The 6-month timeline includes the process audit, the pilot, the rollout, and the managed operation phase. This approach ensures that the AI system is not just a one-time deployment but a continuous improvement process.

  • How a 2,400-Person US Insurer Cut Contract Review Time 40 Percent in 8 Weeks

    Background: A 2,400-Person US P&C Insurer

    This case study is a composite drawn from patterns Forfis has observed across multiple insurance engagements in Tier-1 US markets. No named customer appears. The details below reflect a realistic engagement profile: a mid-to-large insurer, a specific compliance pressure, and a fixed-scope pilot that moved from audit to measured rollout in eight weeks.

    The company in question is a property and casualty insurer with roughly 2,400 employees, headquartered in a Tier-1 US metro. It operates a hybrid stack: a legacy policy management system for underwriting, Notion for internal knowledge management, and Confluence for compliance documentation. The legal and compliance team of 38 analysts handles contract review for vendor agreements, reinsurance treaties, and policyholder addenda. The team’s primary pain is not legal judgment but data entry: extracting clause-level details from PDFs, populating tracking spreadsheets, and flagging deviations from standard terms. Each contract consumes 4 to 6 hours of analyst time before it reaches a senior reviewer.

    Challenge: 5.2 Hours per Contract and a 90-Day Audit Clock

    The trigger was a regulatory audit cycle. The company’s compliance officer needed to demonstrate, within a 90-day window, that contract review processes met internal risk thresholds and that no policyholder data was handled outside approved systems. The existing process relied on manual PDF reading, spreadsheet tracking, and email chains. Error rates on clause extraction sat at roughly 12 percent, and cycle time averaged 5.2 hours per contract. Headcount was frozen, so the team could not absorb the volume increase from a new reinsurance program launching in Q3.

    The specific need was not to replace legal judgment but to eliminate the data-entry layer: the repetitive extraction, classification, and flagging that consumed 70 percent of analyst time. The compliance team needed a system that could read a contract, score each clause against the company’s standard terms, and surface only the deviations that required human review. Everything had to stay inside the company’s data perimeter to satisfy GDPR Article 4 definitions of personal data and the company’s internal data residency policy.

    Approach: n8n Orchestration with a Human Approval Gate

    Forfis ran a two-week process audit across the compliance team’s workflow. The audit identified three automatable stages: clause extraction from PDFs, risk scoring against a predefined rubric, and structured output into Notion and Confluence. The team chose contract review as the pilot scope because it had the highest volume and the clearest before/after metrics.

    The architecture used n8n as the orchestration layer. A new document upload triggered an n8n workflow that called an LLM API for clause extraction, applied a predictive scoring model to flag deviations, and wrote the structured result to a Notion database. A summary posted to the relevant Confluence page. The model was model-agnostic: the pilot used an API-based LLM for quality, with a documented path to migrate to an open-weight model on the client’s own hardware if data residency requirements tightened. A dedicated AI team of four Forfis engineers and one product designer worked alongside two compliance analysts assigned by the client. Every output that touched policyholder data or contract terms required a human approval gate before it moved to the next stage.

    Outcome: 40 Percent Faster, 67 Percent Fewer Extraction Errors

    The pilot ran for six weeks after the two-week audit, for a total of eight weeks from kickoff to measured rollout. Baseline metrics were captured in weeks one and two: 5.2 hours average cycle time per contract, 12 percent clause-extraction error rate, and 38 analyst-hours per week spent on manual data entry.

    After the n8n workflow went live in parallel with the manual process, the team measured the following over four weeks:

    • Cycle time dropped to approximately 3.1 hours per contract, a 40 percent reduction.
    • Clause-extraction error rate fell to roughly 4 percent, a 67 percent relative improvement.
    • Analyst time on data entry dropped from 38 hours per week to about 14 hours per week.
    • The compliance team redirected the freed capacity to the 15 percent of contracts that required deep legal review, which had previously been buried under routine processing.

    The system did not replace the policy management system. It fed structured data back through the same APIs the team already used, and every flagged contract still required a named human reviewer before signature. The audit deliverable was a documented before/after report with timestamps, error logs, and reviewer sign-offs.

    Lessons for Similar Teams

    Five lessons from this engagement apply to any insurance or compliance team considering AI-assisted contract review:

    • Start with the data-entry layer, not the judgment layer. The highest ROI in legal and compliance automation is eliminating repetitive extraction and classification, not replacing legal reasoning. Scope the pilot to the 70 percent of work that is mechanical.
    • Measure the baseline before you build. Two weeks of manual tracking before the pilot gives you a defensible before/after number. Without it, the outcome is anecdote, not evidence.
    • The approval gate is not a bottleneck; it is the product. In regulated environments, the human-in-the-loop step is what makes the system auditable. Design the reviewer interface in Notion or Confluence so the approval action is a single click, not a form fill.
    • Model-agnostic architecture protects you from lock-in. If your data residency requirements change, you should be able to swap the LLM without rewriting the workflow. n8n’s abstraction layer makes this a configuration change, not a rebuild.
    • Eight weeks is realistic if data access is clear. The timeline holds when API access to the policy management system and read access to Notion and Confluence are available in week one. Delays almost always come from access approvals, not from the build.

  • UK E-commerce Firm Cuts Invoice Cycle Time 61% with a 4-Week Claude API Sprint

    Background: A UK E-commerce Retailer at 1,200 Headcount

    This case study is a composite drawn from patterns observed across multiple UK e-commerce engagements. No named customer is represented; details are generalized to protect confidentiality while preserving operational realism.

    The client is a mid-market e-commerce retailer operating across the UK and Ireland, with approximately 1,200 employees and annual revenue in the GBP 80-120 million range. The finance and accounting team consists of 14 people, of whom 6 are dedicated to accounts payable. The company holds ISO 27001 certification, a requirement driven by its B2B wholesale division and its payment processor’s vendor security questionnaire. The existing stack includes NetSuite ERP, a document management system (DMS) for incoming supplier invoices, and a custom internal approval workflow built on a low-code platform. Invoices arrive via email, EDI, and a supplier portal, creating three separate ingestion paths that all funnel into manual data entry before posting to NetSuite.

    Challenge: 4.2% Error Rate and an ISO 27001 Surveillance Audit

    The finance director flagged a specific pain: 6 of 14 AP staff spent an estimated 35-40 hours per week on manual invoice data entry, cross-referencing supplier codes, and chasing missing PO numbers. The error rate on manual entry was measured at 4.2% over a 90-day sample of 1,800 invoices, with the most common errors being incorrect tax codes and mismatched supplier references. Each error triggered a correction cycle averaging 3.5 days, delaying supplier payments and occasionally triggering late-payment penalties under supplier contracts.

    The operational pressure was twofold. First, the company was preparing for a Series C fundraising round in Q3, and the CFO wanted to demonstrate operational efficiency gains to investors. Second, the ISO 27001 surveillance audit was scheduled for the following quarter, and the auditors had noted the manual process as a control weakness in the previous year’s report. The finance team needed a solution that reduced manual effort without introducing a new compliance risk. The constraint was clear: no invoice data could leave the company’s controlled environment without a documented risk assessment, and any third-party API usage had to be covered by a data processing agreement.

    Approach: A 4-Week Integration Sprint on Anthropic Claude

    Forfis scoped a 4-week integration sprint focused on a single process: supplier invoice ingestion and data extraction. The process audit in week one mapped all three ingestion paths (email, EDI, supplier portal) and identified that 78% of invoices arrived as PDFs with a consistent layout from the top 20 suppliers. The pilot scope was deliberately narrow: automate extraction for those 20 suppliers, route the remaining 22% to manual entry, and integrate the extracted data into NetSuite via its REST API.

    The technical stack used the Anthropic Claude API for document understanding and field extraction. The integration layer was a custom Python service deployed on the client’s existing AWS account, receiving webhooks from the DMS when a new invoice was uploaded. The service called the Claude API with a structured prompt that specified the expected output schema (supplier name, invoice number, line items, tax code, total amount, due date). The response was validated against a JSON schema, and any field with a confidence score below 0.92 was flagged for human review. Approved records were pushed to NetSuite via its REST API, with a webhook confirmation written back to the DMS.

    The human-in-the-loop layer was built into the client’s existing low-code approval platform. Reviewers received a Slack notification with a link to a review screen showing the extracted fields, the original PDF, and a one-click approve/reject button. Every action was logged with a timestamp, user ID, and the model’s raw output, creating an audit trail that mapped directly to ISO 27001 Annex A.12 and A.14 controls.

    Outcome: 61% Cycle-Time Reduction and 0.8% Error Rate

    The pilot ran for 6 weeks post-launch, covering approximately 2,400 invoices from the 20 in-scope suppliers. The measured results, compared against the 90-day baseline:

    • Cycle time (from invoice receipt to NetSuite posting) dropped from an average of 4.1 days to 1.6 days, a 61% reduction.
    • Error rate on extracted fields fell from 4.2% to 0.8%, with the remaining errors concentrated in tax code classification for cross-border invoices.
    • Manual data entry hours for the 6 AP staff decreased by an estimated 28 hours per week, freeing capacity for supplier reconciliation and month-end close tasks.
    • Late-payment penalties dropped to zero during the pilot period, compared to an average of GBP 1,200 per month in the prior quarter.

    The human-in-the-loop approval queue averaged 12-15 items per day, with a median review time of 45 seconds per invoice. The finance team reported that the approval step felt like a quality check rather than a data-entry task, which improved adoption. The ISO 27001 surveillance audit, conducted 8 weeks after launch, noted the new process as a control improvement, with no findings related to the automation layer. The client’s CTO confirmed that the integration code, API keys, and infrastructure were fully owned by the client, with no vendor lock-in beyond the Anthropic API subscription.

    Lessons for Similar Teams

    • Scope discipline is the single biggest predictor of sprint success. The pilot succeeded because the team resisted the urge to include the 22% of non-standard invoices in week one. Expanding scope to all suppliers would have pushed the timeline to 8-10 weeks and diluted the baseline measurement. Start with the 70-80% of documents that share a common format, prove the pipeline, then expand.

    • Baseline measurement must happen before the build, not after. The 4.2% error rate and 4.1-day cycle time were measured over 90 days before any code was written. Without that baseline, the outcome metrics would have been anecdotal. Allocate at least one week to process mapping and data collection before the integration sprint begins.

    • Human-in-the-loop design determines adoption, not accuracy. A 95% accurate model is useless if the approval queue is buried in a separate system. The approval step had to live where the reviewers already worked (Slack, in this case) and required no more than one click to approve. The 45-second median review time was a design outcome, not an accident.

    • Compliance documentation is part of the deliverable, not an afterthought. The ISO 27001 risk assessment, data processing agreement with Anthropic, and audit trail specification were drafted during week one, not retrofitted in week four. For regulated clients, compliance artifacts should be treated as first-class deliverables with their own acceptance criteria.

    • Model-agnostic architecture protects the client’s future. The integration layer was built to swap the LLM provider without changing the ingestion, validation, or ERP posting logic. If the client later moves to an open-weight model on-premises for data residency reasons, the change is a configuration update, not a rebuild.

  • Swiss E-Commerce Team Cuts Invoice Cycle Time 47% with a Claude Extraction Pilot

    Background: A Swiss E-Commerce Operations Team at the Pilot Stage

    This case study is a composite drawn from patterns Forfis has observed across multiple engagements. We do not name real clients. The company described here is a plausible representative of a profile we have worked with repeatedly: a mid-sized Swiss e-commerce and retail operations firm, roughly 120 employees, running a mixed stack of SAP Business One for ERP, Microsoft Teams for internal communication, and a legacy document management system for incoming supplier invoices. The team was in the “running isolated pilots” stage of AI maturity: they had experimented with a generic OCR tool on a small sample of invoices, seen promising results, but had no structured process to move from experiment to production. The finance and operations leads wanted a repeatable path, not another one-off test.

    Challenge: 1,800 Invoices a Month, No Headroom, and a Compliance Clock

    The operations team processed roughly 1,800 supplier invoices per month across 14 business days. Each invoice required a clerk to open the PDF, transcribe vendor name, line items, tax codes, and payment terms into SAP Business One, then flag discrepancies for review. The average cycle time from receipt to ERP entry was 3.2 days, with a field-level error rate of 11% on a 200-invoice sample. Two pressures made the status quo untenable: first, the EU AI Act’s transparency and human-oversight obligations (Articles 13 and 14) meant that any automated system handling financial data needed a documented approval workflow, and the team had no such process in place. Second, the operations lead was managing a 20% volume increase tied to a new retail distribution agreement that closed in six weeks. Hiring two additional clerks would have cost roughly CHF 14,000 per month in fully loaded salary, and the onboarding cycle for a new finance clerk in the Swiss market was 4 to 6 weeks.

    Approach: A Two-Week Pilot on One Workflow, Built on Claude and Teams

    Forfis scoped a two-week, fixed-scope pilot on a single workflow: supplier invoice extraction and ERP entry. The architecture used the Anthropic Claude API for extraction, chosen for its 200K-token context window, which handled multi-page invoices and attached purchase orders in a single inference call without chunking. The model output was constrained to a JSON schema matching SAP Business One’s field structure. The integration path was deliberately thin: incoming invoices arrived via email to a monitored mailbox, a lightweight ingestion service pulled the PDFs, the Claude API extracted and classified the fields, and the result was pushed to SAP via its REST API. Approval requests and status updates routed through Microsoft Teams, where the finance team reviewed extractions above a CHF 5,000 threshold. The human-in-the-loop rule was explicit: any invoice touching a payment, a contract clause, or a tax code required a named approver’s sign-off before the ERP write. The pilot team included one Forfis engineer, one product designer, and the client’s operations lead, working as a dedicated AI team embedded in the client’s daily standup.

    Outcome: 47% Faster Cycle Time, 5.8% Error Rate, Zero Re-Keys

    The pilot ran for 10 business days on a live subset of 320 invoices. The measured results, compared against the pre-pilot baseline: cycle time from receipt to ERP entry dropped from 3.2 days to 1.7 days, a 47% reduction. The field-level error rate fell from 11% to 5.8% on the same 200-invoice verification sample. The finance team approved 94% of extractions without correction; the remaining 6% were flagged by the model’s own confidence score and routed to a human reviewer before ERP entry. No invoice required a full re-key. The operations lead reported that the two clerks who had been doing manual entry were redeployed to handle the 20% volume increase from the new distribution agreement without additional hiring. The pilot’s measured baseline and post-pilot metrics were delivered as a one-page report, which the client used in a board presentation to justify a rollout to the remaining 12 invoice workflows. The EU AI Act compliance documentation, including the human-oversight log and transparency disclosures, was included as an appendix.

    Lessons for Teams Running Isolated Pilots

    • Scope the pilot to one workflow, not one document type. The client initially wanted to pilot invoices, credit notes, and purchase orders simultaneously. Forfis pushed back: a single workflow with a full integration chain (ingestion, extraction, approval, ERP write-back, Teams notification) produces operationally meaningful metrics. A multi-document pilot with a partial integration chain produces vanity numbers. The client agreed, and the focused scope is why the two-week timeline held.
    • The baseline is a contractual deliverable, not an afterthought. Without the pre-automation measurement of cycle time and error rate, the team cannot quantify the improvement or justify the rollout. Forfis builds the baseline measurement into the first week of the pilot, even if it means the automation work starts on day four instead of day one.
    • Human-in-the-loop thresholds should be configurable, not hardcoded. The CHF 5,000 approval threshold was a starting point. During the pilot, the team observed that the model’s confidence score was a better predictor of error than the invoice amount. The threshold was adjusted to a hybrid rule: amount above CHF 5,000 OR confidence below 0.92 triggers human review. This reduced unnecessary approvals by 18% without increasing the error rate.
    • Integration through existing APIs keeps the operational surface small. The client did not want a new front-end. The approval workflow lived in Microsoft Teams, the ERP write went through SAP’s REST API, and the ingestion service was a 200-line Python script. The total new infrastructure was one container and one API key. This kept the post-pilot operational overhead low and made the managed-operation retainer straightforward.
    • EU AI Act compliance is a design constraint, not a documentation afterthought. The human-oversight log, the transparency disclosure to affected parties, and the model-output audit trail were built into the workflow from day one. Retrofitting compliance documentation after the pilot is live is more expensive and less defensible than building it in.