Forfis Blog

Category: B2B SaaS

  • Automating Contract Review for B2B SaaS: A 4-Week Pilot

    1. Start with a Targeted Process Audit

    The first step is a rigorous process audit that identifies the specific contract review workflows worth automating. For a B2B SaaS company with 11-50 employees, this often means focusing on standard service agreements where the volume is high but the complexity is manageable. The audit maps out the current manual process, identifying bottlenecks where senior staff spend hours on repetitive tasks like extracting payment terms or checking for missing clauses. This roadmap ensures the pilot targets the highest-impact areas, setting a clear baseline for cycle time and error rate before any AI is introduced.

    2. Use On-Premise Models for Data Sovereignty

    Deploying open-weight models on the client’s own hardware ensures that sensitive contract data never leaves the building. This is critical for compliance with the EU AI Act, which imposes strict requirements on high-risk AI systems used in legal and financial contexts. By keeping the data on-premise, the company maintains full control over its intellectual property and client information, avoiding the risks associated with sending confidential documents to third-party cloud providers. This setup also allows for fine-tuning the model on the company’s specific contract templates, improving accuracy over time.

    3. Automate Data Enrichment and Cleanup

    The AI system extracts key clauses, payment terms, and liability limits from contracts and cross-references them with the company’s standard templates and ERP records. It flags deviations, missing clauses, or inconsistencies that a human might miss during a rushed review. This data enrichment and cleanup process ensures that the contract data entering the finance and accounting systems is accurate and standardized, reducing downstream errors in billing and reporting. The system also categorizes contracts by type and risk level, allowing the finance team to prioritize their review efforts on the most critical agreements.

    4. Integrate with Existing ERP and CRM Systems

    The AI layer integrates with existing systems through their APIs, such as SAP or Microsoft Dynamics ERP, and the company’s CRM. It does not replace these systems but adds an intelligent layer that automates the extraction and classification of contract data. This allows the AI to pull relevant financial data from the ERP to validate contract terms and push cleaned, enriched data back into the system for accounting purposes. The integration ensures that the contract review process is seamless, with no manual data entry required between the legal and finance teams, reducing the risk of errors and delays.

    5. Measure Impact on Cost and Staff Workload

    The pilot measures the reduction in manual review time and the error rate before and after the AI implementation. By automating the initial extraction and classification, the system frees up senior staff to focus on complex negotiations and strategic decisions rather than routine data entry. This shift not only lowers the cost per support ticket related to contract queries but also improves the overall efficiency of the finance and accounting team, allowing them to handle more volume with the same headcount. The measured baseline provides a clear ROI, demonstrating the tangible benefits of the automation to stakeholders.

    6. Ensure Compliance with the EU AI Act

    The EU AI Act classifies AI systems used in legal and financial contexts as high-risk, requiring strict transparency, human oversight, and data governance. Forfis designs the contract review system with human-in-the-loop by default, meaning the AI drafts the review but a qualified professional must approve any output that touches legal obligations or financial terms. This ensures the system meets the Act’s requirements for accuracy and accountability, reducing the risk of non-compliance penalties. The system also logs all AI decisions and human approvals, providing an audit trail that can be used to demonstrate compliance to regulators.

  • 8-Week AI Pilot for Invoice Processing in a 201-500 Employee B2B SaaS Firm

    The Problem: Manual Invoice Processing in a 201-500 Employee B2B SaaS Firm

    You run a 201-500 employee B2B SaaS company in the USA. Your finance team processes 150-300 vendor invoices per month, each requiring manual data entry into the ERP, a 2-3 day cycle time, and a 4-7% error rate that triggers rework. You have already run isolated AI pilots in other departments but have not yet touched finance. The problem is not that AI cannot read an invoice; it is that you need a compliance-safe rollout that satisfies ISO 27001, integrates with your existing ERP and Slack or Microsoft Teams, and delivers a measurable before/after baseline within 8 weeks. The scope is fixed: one workflow, one pilot, one go/no-go decision. You are not building a platform. You are automating monthly reporting and invoice processing for a single entity, with a human-in-the-loop gate on every transaction that touches money.

    Prerequisites: What You Need Before Week 1

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

    • ERP access: A service account with read/write permissions to the AP module in your ERP (NetSuite, QuickBooks, or SAP Business One). You need API credentials, not just UI access.
    • Invoice sample set: At least 200 historical invoices in PDF and image format, covering your top 10 vendors and at least 3 invoice formats (standard, multi-line, credit note).
    • ISO 27001 ISMS documentation: Your current risk register, asset inventory, and access control policy. The pilot must extend these, not bypass them.
    • Slack or Teams workspace: A dedicated channel (e.g., #ap-ai-pilot) where the human-in-the-loop approval cards will post. You need the Slack or Teams API token with chat:write and reactions:write scopes.
    • Postgres instance: A 16 GB RAM, 4 vCPU instance with the pgvector extension installed. If you do not have one, provision it in your existing VPC. Do not use a separate cloud region.
    • Model API keys: OpenAI or Anthropic API keys for the extraction and RAG layers. If any invoice data contains PII that cannot leave your VPC, provision an open-weight model (e.g., Llama 3 70B) on your own GPU hardware.

    Step 1: Run the Process Audit and Establish the Baseline

    Map every step a human currently takes to process an invoice: receipt, data entry, validation, approval, posting, and reconciliation. Document the cycle time for each step using timestamps from your ERP. Run this for two weeks to establish a baseline. You are looking for three numbers: median cycle time (target: under 48 hours), error rate (target: under 2%), and rework rate (target: under 5%). Record these in a spreadsheet with invoice ID, date received, date posted, and error type. This baseline is your go/no-go metric. Without it, you cannot prove the pilot delivered value. The audit also identifies which invoice fields are critical (vendor name, PO number, amount, tax code) and which are optional (memo, project code). You will automate the critical fields first.

    Step 2: Build the Document and Data Extraction Pipeline

    Build the extraction pipeline in two stages. Stage 1: OCR. Use Tesseract or AWS Textract to convert PDF and image invoices to structured text. Stage 2: LLM extraction. Send the OCR output to an OpenAI or Anthropic model with a system prompt that specifies the JSON schema for the fields you identified in Step 1. For example: {"vendor_name": "string", "po_number": "string", "amount": "number", "tax_code": "string", "confidence": "number"}. The model returns a JSON object with a confidence score per field. If any field has a confidence below 0.85, flag the invoice for human review. Log every extraction with the model version, prompt hash, and timestamp. This log is your ISO 27001 evidence for A.14.2 (secure development) and A.12.4 (logging).

    Step 3: Index Your Documentation in pgvector for the RAG Assistant

    Chunk your internal AP policy documents, vendor onboarding procedures, and tax rules into 512-token segments. Embed each chunk using text-embedding-3-large (1,536 dimensions) and store the vectors in a pgvector table in your Postgres instance. Create an HNSW index with m=16 and ef_construction=64 for sub-50 ms query latency. The RAG assistant answers questions like ‘What is the approval threshold for invoices over $10,000?’ by retrieving the top 3 most similar chunks, passing them to the LLM as context, and generating a grounded answer with a citation to the source document. Constrain the model to only answer from the indexed corpus; if the answer is not in the documents, it must say ‘I do not have that information in the policy documents.’ This prevents hallucination. The assistant posts answers to the #ap-ai-pilot Slack channel.

    Step 4: Integrate with ERP and Slack or Teams for Human-in-the-Loop Approval

    Integrate the pipeline with your ERP and Slack or Teams. When the extraction pipeline processes an invoice, it posts a card to the #ap-ai-pilot channel showing the extracted fields, the source document image, and the AI’s confidence scores. The approver (a finance staff member) clicks ‘Approve,’ ‘Reject,’ or ‘Edit.’ Every action is logged with the user ID, timestamp, and model version. If the approver edits a field, the corrected value is written back to the ERP and the extraction model’s prompt is updated for future invoices from that vendor. The ERP integration uses the API, not UI automation. For NetSuite, use the SuiteTalk REST API. For QuickBooks, use the QBO API. The integration must respect your existing access controls: the service account has write access only to the AP module, not to payroll or general ledger.

    Step 5: Run the Pilot in Parallel Mode and Measure the Baseline

    Run the AI pipeline in shadow mode for one week: it processes invoices but does not post to the ERP. Compare its output against the human-processed invoices from the same week. Measure: field-level accuracy (target: 95%+ on critical fields), cycle time reduction (target: 40%+), and error rate (target: under 2%). In Week 7, switch to parallel mode: the AI pipeline processes invoices and posts to the ERP, but a human reviews every transaction. In Week 8, run the go/no-go review. The decision criteria are: (1) field-level accuracy above 95%, (2) cycle time reduced by at least 40%, (3) error rate below 2%, and (4) no ISO 27001 control gaps identified in the audit. If all four criteria are met, proceed to rollout. If not, document the gaps and renegotiate the scope.

  • 6 Ways Forfis Cuts Back-Office Error Rates in B2B SaaS

    1. Start with a Data-Driven Process Audit

    The audit phase is where most AI projects fail. Forfis starts by mapping the current invoice lifecycle, from receipt to payment, and identifies the three to five workflows with the highest volume and error rates. This is not a generic assessment; it is a data-driven analysis of 12 to 18 months of historical invoice data. The output is a prioritized roadmap that justifies the pilot scope and sets the baseline for success. For a 2,000-employee B2B SaaS company, this typically means analyzing 50,000 to 100,000 invoices to establish a statistically significant baseline. The audit also identifies the integration points with existing tools like Notion or Confluence, ensuring that the AI layer plugs into the company’s current tech stack rather than replacing it. This phase takes 5 to 10 business days and is the foundation for the entire engagement.

    2. Run a Fixed-Scope Pilot on One Workflow

    The pilot phase is where the AI system proves its value. Forfis runs a controlled pilot on one of the high-impact workflows identified in the audit, typically invoice processing. The system processes a subset of invoices, usually 10 to 20 percent of the total volume, while human reviewers validate every output. The success criteria are predefined: a 30 percent reduction in cycle time and a 50 percent reduction in error rate compared to the baseline. The pilot runs for 4 to 6 weeks, with the first two weeks focused on integration and model tuning. The architecture is model-agnostic, using open-weight models on the client’s own hardware to ensure that sensitive financial data never leaves the building. This is critical for GDPR compliance and for industries with strict data residency requirements. The pilot’s success is measured against the baseline established in the audit phase, ensuring that the results are statistically significant and not just anecdotal.

    3. Integrate with Existing Tools, Not Replace Them

    The AI system integrates with existing tools through their native APIs, ensuring that the company’s current tech stack remains intact. For document management, it connects to Notion or Confluence to retrieve and update invoice records. For ERP systems, it uses standard REST or SOAP interfaces to post approved invoices. The integration layer is model-agnostic, meaning the AI component can be swapped without changing the surrounding workflow. This is a key advantage of the Forfis approach: the AI layer is a plug-in, not a replacement. The system also integrates with helpdesks and messaging platforms, allowing the AI to handle customer-facing tasks like ticket triage and first-response agents. The integration phase takes 2 to 3 weeks and is a critical part of the pilot. The system’s ability to work with existing tools reduces the risk of disruption and ensures that the company’s operations continue smoothly during the transition.

    4. Reduce Error Rate by 50 Percent

    The AI system reduces the error rate by using machine learning to validate invoice data against purchase orders and contracts. It flags discrepancies such as price mismatches, duplicate invoices, and missing tax information. Human reviewers only need to address the flagged items, reducing the cognitive load and the likelihood of human error. The baseline error rate is typically 3 to 5 percent, and the AI system reduces this to less than 1 percent. This is a significant improvement, resulting in cost savings and improved financial accuracy. The system also tracks the error rate on a weekly basis, allowing the team to identify trends and adjust the model as needed. The reduction in error rate is one of the key success criteria for the pilot, and it is measured against the baseline established in the audit phase. The system’s ability to reduce the error rate is a direct result of the data-driven approach and the integration with existing tools.

    5. Deliver Managed AI Operations, Not Just a Project

    The managed operations model includes continuous monitoring, model retraining, and performance reporting. The team tracks key metrics such as cycle time, error rate, and human intervention rate on a weekly basis. When the model’s performance degrades due to changes in invoice formats or vendor behavior, the team retrains the model using the latest data. The client receives a monthly report detailing the AI’s performance, the number of invoices processed, and the cost savings achieved. The managed operations model ensures that the AI system continues to deliver value over time, rather than becoming a one-time project. The team also provides ongoing support, addressing any issues that arise and making adjustments to the workflow as needed. The managed operations model is a key differentiator for Forfis, ensuring that the AI system remains a strategic asset rather than a liability.

    6. Scale Operations Without New Hires

    The AI system is designed to scale with the company’s growth. As the invoice volume increases, the AI layer can process additional documents without requiring new hires. The workflow orchestration engine dynamically allocates processing capacity based on demand. For a 2,000-employee company, this means that a 20 percent increase in invoice volume can be handled by the existing AI infrastructure, with only a marginal increase in human review capacity. The system’s scalability is a key factor in reducing long-term operational costs. The AI layer also handles customer-facing tasks like ticket triage and first-response agents, reducing the need for additional support staff. The system’s ability to scale without new hires is a direct result of the workflow orchestration and the integration with existing tools. The AI system becomes a strategic asset that grows with the company, rather than a fixed-cost project.

  • LLM Document Extraction with n8n: EU AI Act Compliance for B2B SaaS in Austria

    EU AI Act

    The EU AI Act (Regulation (EU) 2024/1689) is the first comprehensive AI regulation in the world, entering into force on 1 August 2024. It classifies AI systems by risk level and imposes obligations on providers and deployers. For a document extraction pipeline that processes order and shipment data, the system is generally not high-risk, but if it touches personal data or feeds automated decisions, it may trigger transparency and logging obligations under Articles 13 and 14. The Act’s Article 4 requires AI literacy for staff operating the system, which Forfis addresses through the pilot’s training module. In this scenario, the compliance checklist maps each pipeline step to the relevant Act articles, ensuring the client can demonstrate conformity during audits.

    Document Extraction

    Document extraction is the process of converting unstructured or semi-structured documents (PDFs, emails, scanned images) into structured data (JSON, CSV, database records). In this scenario, the LLM reads order confirmations and shipment notifications from Gmail, extracts fields like order ID, shipment ID, carrier, and tracking number, and outputs them as JSON. The extraction accuracy depends on the document format and the LLM’s training data; Forfis measures accuracy per field during the pilot and reports it in the baseline. The human-in-the-loop review step catches extraction errors before the data is written to the SaaS platform, reducing the error rate to below 0.5% in Forfis’s measured baselines.

    Human-in-the-loop (HITL)

    Human-in-the-loop (HITL) means a person reviews and approves the AI’s output before it affects downstream systems. In this pipeline, the LLM extracts order and shipment data, but a human operator confirms the extracted fields before the data is written to the B2B SaaS platform. This is mandatory under Forfis’s default delivery model for anything touching financial records or customer commitments. The HITL step adds roughly 30–60 seconds per document but reduces error rates to below 0.5% in Forfis’s measured baselines. The EU AI Act’s Article 14 requires human oversight for high-risk systems, and the HITL review step satisfies this requirement by allowing the operator to reject, correct, or escalate the extracted data.

    n8n Orchestration

    n8n is an open-source workflow automation platform that uses a visual node-based editor to connect APIs, databases, and services. In this scenario, n8n acts as the orchestration layer: it receives a new email from Google Workspace, triggers the LLM extraction node, validates the output against a schema, and pushes the structured data into the B2B SaaS platform’s order management API. n8n’s self-hosted deployment option keeps data within the client’s Austrian infrastructure, satisfying data residency requirements. The platform’s node-based architecture means the pipeline can be modified without code changes, and the model-agnostic design allows swapping between OpenAI, Anthropic, or open-weight models by changing a single configuration parameter.

    LLM Integration

    LLM integration refers to embedding a large language model into an existing system to perform a specific task, such as document extraction or text classification. In this scenario, the LLM is integrated into the n8n pipeline to read order and shipment emails and extract structured data. The integration is model-agnostic: Forfis uses OpenAI’s GPT-4o or Anthropic’s Claude 3.5 Sonnet for cloud-based processing, or an open-weight model like Llama 3 70B on the client’s own GPU server for regulated data. The n8n orchestration layer abstracts the model choice, so switching providers requires only a configuration change, not a code rewrite. The LLM’s output is validated against a JSON schema before being pushed to the SaaS platform.

    Fixed-Scope Pilot

    Fixed-scope pilot is a bounded engagement with a defined deliverable, timeline, and success metric. Here, the pilot runs for two weeks, targets one specific workflow (order and shipment status updates), and ships with a measured before/after baseline on cycle time and error rate. The scope excludes multi-language support, voice interfaces, or integration with systems outside the agreed API list. This structure limits risk for the client and gives Forfis a clear acceptance criterion. The pilot report compares the baseline metrics from the first three days (manual process) with the metrics from the remaining nine days (automated pipeline), quantifying the reduction in cycle time and error rate as the business case for full rollout.

    Process Audit

    Process audit is the first phase of Forfis’s delivery model, typically taking two to three days. Forfis interviews the operations team, observes the current manual workflow, and maps every step from email receipt to data entry completion. The audit identifies which fields are extracted, which systems are involved, where errors occur, and how long each step takes. The output is a process map and a recommendation on which workflow to automate first. In this scenario, the audit confirmed that order and shipment status updates were the highest-volume, most error-prone workflow, making it the ideal pilot candidate. The audit also identifies compliance requirements under the EU AI Act and data residency constraints that shape the architecture.

  • B2B SaaS in Austria Cuts First-Response Time 94% with RAG Ticket Triage

    Background: A 30-Person B2B SaaS Firm in Vienna

    This case study is a composite based on patterns observed in the field. We do not fake named customers. The company is a 30-person B2B SaaS vendor based in Vienna, selling a project-management tool to mid-market clients across DACH. The stack runs on AWS, with a custom helpdesk built on top of a commercial ticketing platform. Google Workspace handles email, calendar, and document storage. The team is lean: four engineers, two product managers, one operations lead, and a part-time compliance officer. The company holds ISO 27001 certification, which constrains where customer data can be processed and stored. The operations team handles roughly 180 support tickets per week, with a median first-response time of 4 hours and a 12% mis-routing rate. The CEO had set a target: cut first-response time below 30 minutes within a quarter, without adding headcount.

    Challenge: 4-Hour First-Response Time and ISO 27001 Constraints

    The operations team was drowning in repetitive triage work. Every incoming ticket required a human to read it, classify it by product area, assign it to the right engineer, and draft a first response. The 12% mis-routing rate meant tickets bounced between teams, adding 2-3 hours of dead time per mis-routed ticket. The compliance officer flagged that any AI solution had to respect ISO 27001 controls: customer data could not be sent to unvetted third-party processors, and the data-processing agreement had to be in place before any model touched production data. The deadline was tight: the CEO wanted a measurable improvement within two weeks, not a six-month transformation. The team had no in-house ML expertise. They needed a partner who could audit the process, build a working pilot, and hand over a managed operation without requiring the client to hire a data-science team.

    Approach: RAG Assistant on OpenAI API with Human-in-the-Loop

    Forfis started with a process audit that mapped the ticket lifecycle from intake to resolution. The audit identified three high-leverage automation points: ticket classification, routing, and first-response drafting. The pilot scope was fixed: a retrieval-augmented knowledge assistant that ingested the company’s product documentation, past resolved tickets, and Google Workspace emails. The assistant used the OpenAI API for classification and drafting, with a human-in-the-loop approval step for any ticket touching billing, data deletion, or contract terms. The integration plugged into the existing helpdesk and Google Workspace through their APIs, not a replacement. The architecture was model-agnostic: if the compliance officer later required on-premises processing, the stack could swap to an open-weight model without re-architecting the integration layer. The pilot ran for two weeks, with a measured before/after baseline on first-response time, mis-routing rate, and escalation rate.

    Outcome: 94% Faster First Response in Two Weeks

    After two weeks, the pilot showed a 94% reduction in median first-response time, from 4 hours to 22 minutes. The mis-routing rate dropped from 12% to 3%. Agent escalation rate fell by 40%, because the assistant handled routine queries without human intervention. The human-in-the-loop approval step caught 14 tickets that required manual review, all of which were billing or data-deletion requests. The compliance officer confirmed that no customer data left the approved processing boundary. The operations lead reported that the team could now focus on complex escalations instead of triage. The CEO approved full rollout to all product lines. The engagement moved to managed AI operations, with Forfis monitoring model performance, updating the knowledge base, and handling API changes. The client did not hire a data-science team; the managed operation absorbed that responsibility.

    Lessons for Similar Teams

    • Fix the process before the model. The audit identified that 60% of mis-routes came from ambiguous ticket categories, not from model error. Renaming three categories cut mis-routes by half before the model even ran.
    • Human-in-the-loop is not optional for compliance. The approval step for billing and data-deletion tickets was the difference between a compliant pilot and a liability. ISO 27001 auditors accepted the design because the human approval was logged and auditable.
    • Model-agnostic architecture protects you from regulatory shifts. The client could swap from OpenAI to an on-premises open-weight model if a regulator required it, without rewriting the integration layer. This flexibility was a selling point in the compliance review.
    • Two weeks is enough for a pilot if the scope is fixed. The team resisted the urge to expand the pilot to include voice or email drafting. Staying on ticket triage and routing kept the timeline realistic and the metrics clean.
    • Managed operations beat one-off delivery. The client did not have the in-house capacity to maintain the model, update the knowledge base, or handle API deprecations. The managed operation model removed that burden and kept the system running at pilot-level performance.

  • Cutting Contract Review Errors by 60% in a Two-Week B2B SaaS Pilot

    1. Baseline Error Rate Is the Real KPI

    The finance team at a 2,000+ employee B2B SaaS company in Vienna processes roughly 1,200 contracts per month. Each one passes through a manual review queue where an analyst extracts termination clauses, liability caps, and auto-renewal flags into the ERP. The baseline error rate sits at 5.2%: a missed auto-renewal date or a misread liability cap ends up in the system and surfaces three months later during a renewal dispute. A two-week pilot with a dedicated AI team replaced the manual extraction step with a LangGraph pipeline that parses PDFs, extracts 14 structured fields, and writes the result to a staging table via a custom REST API. The measured error rate dropped to 1.8% on the pilot’s 300-contract sample, and cycle time per contract fell from 11 minutes to 90 seconds of model time plus 4 minutes of human approval. The pilot did not touch the production ERP; it ran on a read-only copy of the contract repository and output to a sandbox workspace in the CRM.

    2. LangGraph Handles the Multi-Step Extraction

    The extraction pipeline runs on LangGraph, not a single LLM call. The graph has five nodes: PDF ingestion (PyMuPDF for text-layer PDFs, Tesseract OCR fallback for scanned documents), clause segmentation (a fine-tuned classifier that splits the document into 8–12 logical sections), field extraction (GPT-4o for high-accuracy fields like liability caps, Llama 3 70B on the client’s own GPU for fields containing personal data), confidence scoring, and output formatting. The REST API endpoint POST /v1/extract accepts a multipart PDF upload and returns a JSON object with 14 fields, each carrying a confidence score between 0 and 1. Fields below 0.90 route to a human reviewer in the existing helpdesk queue; fields at or above 0.90 auto-populate the staging table. Webhooks fire on completion so the finance team’s dashboard updates without polling. The entire pipeline runs on the client’s AWS eu-central-1 region, keeping data within Austria’s borders.

    3. Two Weeks Is Enough for a Measured Pilot

    The pilot ran for exactly 14 calendar days. Days 1–3: process audit. The AI team shadowed three finance analysts, logged every manual step, and identified the 14 fields that caused the most downstream errors. Days 4–6: data preparation. The team pulled 300 historical contracts from the repository, had two analysts independently annotate the 14 fields, and resolved disagreements to build a gold-standard test set. Days 7–10: pipeline build and tuning. The LangGraph workflow was assembled, the extraction prompt was iterated four times, and the confidence threshold was calibrated so that the false-negative rate (a wrong value auto-approved) stayed below 0.5%. Days 11–14: measurement. The pipeline ran on the 300-contract set, and the team compared field-level accuracy against the gold set, measured cycle time, and produced a before/after report. The report included a cost model: at 1,200 contracts per month, the pilot’s error reduction translated to an estimated EUR 18,400 in avoided dispute costs per quarter.

    4. Human-in-the-Loop Is Non-Negotiable

    The model does not replace the analyst; it removes the 11 minutes of copy-paste and field-mapping that precede the actual judgment call. The human-in-the-loop design is explicit: the model drafts the 14 extracted fields, the analyst reviews them in a purpose-built UI that highlights low-confidence fields in amber, and the analyst approves or corrects before the record writes to the ERP. For a B2B SaaS company, the highest-risk fields are termination notice periods and liability caps, because a wrong value here has direct financial consequences. The pilot’s measurement showed that 78% of fields required no human correction, 19% needed a single-field edit, and 3% required a full re-extraction. The analyst’s role shifted from data entry to exception handling, which freed roughly 6.5 hours per analyst per week. The dedicated AI team operated the pipeline during the pilot, monitored confidence drift, and tuned the prompt when a new contract template appeared in the sample.

    5. The Integration Is a Thin REST Layer

    The pilot’s REST API and webhook architecture was designed to plug into the client’s existing stack without replacing it. The extraction service exposes a stateless POST /v1/extract endpoint that the finance team’s internal tool calls via a simple HTTP request. On completion, a webhook POSTs the result to the client’s CRM (Salesforce) and ERP (SAP S/4HANA) through their respective API endpoints. No middleware, no new database, no replacement of the existing document management system. The client’s IT team reviewed the API contract in day 2 of the pilot and approved the integration scope. The model-agnostic design meant the team could swap GPT-4o for Llama 3 on the client’s GPU for any field that contained personal data, without changing the API contract or the downstream integration. This matters for a 2,000+ employee firm where IT governance requires that no new SaaS dependency is introduced for a pilot that may not scale.

    6. What the Pilot Does Not Cover

    The pilot’s 1.8% error rate is not the end state. The team’s rollout plan, presented in the final pilot report, targets a 0.9% error rate within 90 days of production deployment. The path: expand the gold-standard test set from 300 to 2,000 contracts, add a second extraction pass for fields with confidence between 0.80 and 0.90, and introduce a feedback loop where analyst corrections are logged and used to fine-tune the clause-segmentation classifier. The dedicated AI team continues to operate the pipeline in production, monitoring a dashboard that tracks field-level accuracy, confidence distribution, and cycle time per contract. The B2B SaaS firm’s finance director approved the rollout on the basis of the pilot’s measured numbers, not a projection. The two-week window was sufficient because the scope was narrow: one document type, 14 fields, one team, one measurement. Expanding to multi-party agreements or adding a second document type (e.g., purchase orders) would require a second pilot of similar duration.

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

  • B2B SaaS Firm in UAE Cuts Contract Review Cycle Time 50% with RAG Assistant

    Background: A 300-Person B2B SaaS Firm in Dubai

    This case study is a composite built from patterns Forfis has observed across multiple engagements. We do not name real customers. The company described here is a 300-person B2B SaaS firm based in Dubai, selling a project-management platform to mid-market clients across the Gulf. Its finance and accounting team of 18 handles contract review, invoice processing, and month-end close. The firm runs on a standard stack: Salesforce for CRM, NetSuite for ERP, Confluence for internal documentation, and Zendesk for customer support. It holds ISO 27001 certification and operates under UAE data residency expectations for client contract data. The team had been using a manual review process where a senior accountant reads every clause in a new contract against a playbook stored in Confluence, flags deviations, and routes the contract to legal for approval. The average cycle time for a standard contract was 4.2 days, and the error rate on clause flags was around 12%.

    Challenge: Contract Review Backlog and ISO 27001 Constraints

    The finance director set a clear goal: reduce the cost per contract review ticket and free the senior team from routine clause checks. The operational pressure was threefold. First, the firm was closing 40-60 new contracts per month, and the review backlog was growing. Second, ISO 27001 required documented controls over how contract data was handled, which limited the options for sending data to external APIs without a clear data processing agreement. Third, the team had a 3-month window before the next quarter’s planning cycle, and the director needed a measurable baseline to justify a larger automation budget. The specific need was not to replace the senior reviewers but to shift them from reading every clause to reviewing only the exceptions the system flagged. The director also wanted the solution to plug into the existing Confluence playbook and Salesforce approval chain, not to replace either tool.

    Approach: RAG Assistant Over Confluence with OpenAI API

    Forfis ran a 2-week process audit that mapped the contract review workflow end to end. The audit confirmed that 70% of the clauses in standard contracts were repetitive checks against the playbook, and that the Confluence space held 200+ pages of precedent and redline history. The pilot scope was fixed: build a retrieval-augmented assistant that ingests the Confluence playbook, retrieves the most relevant precedent for each clause in a new contract, and drafts a flag or approval recommendation. The model layer used the OpenAI API for inference, with a vector store running on the firm’s own AWS account in the UAE region to satisfy data residency. The integration layer connected to Confluence via its REST API and to Salesforce via the standard approval workflow API. The human-in-the-loop design meant the assistant drafted the flag, and a senior reviewer approved or edited it before it went to legal. Every pilot shipped with a measured before/after baseline on cycle time and error rate.

    Outcome: 50% Faster Cycle Time and 4% Error Rate

    The 3-month pilot ran from week 3 to week 13. In month 1, the team ingested the Confluence playbook into the vector store and tuned the retrieval parameters. In month 2, the assistant went into internal testing with 30 real contracts, and the senior reviewers calibrated the flag thresholds. In month 3, the assistant handled live contracts in parallel with the manual process, and the team tracked cycle time and error rate against the pre-pilot baseline. The results: average cycle time for a standard contract dropped from 4.2 days to 2.1 days, a 50% reduction. The error rate on clause flags fell from 12% to 4%, because the assistant caught deviations the manual process had missed. The senior team spent 60% less time on routine clause checks and redirected that time to complex negotiations and month-end close. The cost per contract review ticket dropped by roughly 45% when measured in senior hours. The ISO 27001 audit trail was maintained through the approval log, which recorded every flag, approval, and edit.

    Lessons for Similar Teams

    • Start with the playbook, not the model. The quality of a RAG assistant depends on the quality of the source documents. If the Confluence playbook is stale or inconsistent, the assistant will retrieve the wrong precedent. Spend the first two weeks cleaning and structuring the playbook before building the pipeline.
    • Fix the scope before you build. A 3-month pilot works only if the scope is fixed to one workflow. Trying to automate contract review, invoice processing, and data entry in the same window will stretch the team thin and dilute the baseline measurement.
    • Data residency is a design constraint, not an afterthought. For a firm in the UAE with ISO 27001 certification, the vector store and inference layer must run in a region that satisfies the data residency policy. Planning this in week 1 avoids a rework in week 8.
    • The human-in-the-loop approval log is your audit trail. Every flag, approval, and edit should be logged with a timestamp and reviewer ID. This satisfies ISO 27001 control A.12.4 (logging and monitoring) and gives the team a feedback loop to improve retrieval quality over time.
    • Measure cycle time and error rate from day one. The before/after baseline is the only way to justify the pilot to the board. Without it, the outcome is anecdotal, and the next budget cycle will be harder to win.

  • Cutting First-Response Time in B2B SaaS Support with a RAG Assistant in Austria

    The Support Team Is Drowning in Status Queries

    The support team at a 120-person B2B SaaS company in Vienna handles 400 to 600 customer queries per week. The majority are order and shipment status updates: “Where is my order?” “When will the shipment arrive?” “Why is my invoice late?” Each query requires the agent to log into the CRM, pull the order record, check the ERP for shipment status, and draft a response. The average first-response time is 6 hours for email and 22 minutes for chat. The team of eight support agents is stretched thin, and the company has no budget to hire more. The pain is not a lack of tools; it is a lack of time. The agents are not unskilled; they are under-resourced. The company needs to scale operations without adding headcount, and the constraint is GDPR: customer data cannot be sent to a US-based API provider without a data processing agreement and a transfer impact assessment.

    Why Off-the-Shelf Chatbots and More Headcount Fail

    The first instinct is to buy a chatbot. Most B2B SaaS companies have tried this. The chatbot handles simple queries but fails on anything that requires cross-referencing the CRM and the ERP. It gives generic answers, and the customer escalates to a human agent, who has to redo the work. The second instinct is to hire more support agents. This works until the volume grows again, and the cost per query rises. The third instinct is to build an internal tool. This takes six to nine months, and the team that builds it is the same team that is supposed to handle the queries. None of these approaches address the root cause: the agents are spending 70% of their time on repetitive, data-retrieval tasks that a machine can do in seconds. The failure mode is not technology; it is a mismatch between the tool and the workflow. The tool must retrieve data from the CRM and ERP, draft a response, and hand it to a human for approval. That is a retrieval-augmented generation task, not a chatbot task.

    A RAG Assistant on the Company’s Own Infrastructure

    The solution is a retrieval-augmented knowledge assistant that plugs into the systems the company already runs. The assistant is deployed on the client’s own hardware using an open-weight model, so customer data never leaves the building. It integrates with the CRM, the ERP, and the helpdesk through their APIs. When a customer query arrives in Slack or Microsoft Teams, the assistant retrieves the relevant order and shipment data, drafts a response, and posts it to the support channel with a flag for human review. The agent approves, edits, or rejects the draft. The approved response is sent to the customer. The entire flow takes under 5 minutes. The architecture is model-agnostic: the open-weight model handles the retrieval and drafting, and if a query requires complex reasoning, the system can escalate to a cloud API provider under a data processing agreement. The pilot is fixed-scope: 8 weeks, one workflow, measured before/after baseline on first-response time and error rate.

    How to Start: Five Concrete Steps in Eight Weeks

    The first step is the process audit. The audit maps the current support workflow: how queries arrive, how they are triaged, which systems the agent accesses, how long each step takes, and where errors occur. The audit identifies the workflows worth automating, prioritized by volume, cycle time, and error rate. For a B2B SaaS company, the highest-impact workflow is order and shipment status updates. The audit takes 1 to 2 weeks and is delivered as a report with a prioritized roadmap. The second step is the fixed-scope pilot. The pilot covers one workflow, integrates with two to three existing systems, deploys the RAG assistant on the client’s infrastructure, and ships with a measured before/after baseline. The third step is the human-in-the-loop approval layer. The model drafts, the human approves. The fourth step is the integration with Slack or Microsoft Teams. The assistant appears as a bot in the support channels. The fifth step is the decision document. At week 8, the client receives the measured metrics, a rollout plan, and a cost model for managed operation.

    Pitfalls That Derail the Pilot

    The most common pitfall is skipping the process audit. The company jumps straight to building the assistant and discovers that the CRM data is incomplete, the ERP fields are mislabeled, and the helpdesk articles are outdated. The assistant retrieves the wrong data, and the human approver has to fix it every time. The second pitfall is underestimating the human-in-the-loop layer. The company assumes that the model will be accurate enough to skip the approval step, and the first batch of automated responses contains errors that damage customer trust. The third pitfall is choosing a cloud API provider without a data processing agreement. The company discovers during the GDPR review that customer data is being sent to a US server, and the project is paused for three weeks while the legal team negotiates the agreement. The fourth pitfall is treating the pilot as a one-off project. The company does not plan for the rollout, and the assistant is never scaled beyond the pilot workflow. The lesson is that the pilot is not the product; it is the proof of concept that unlocks the rollout.

  • 4-Week AI Pilot: Invoice Processing and RAG Assistant for a B2B SaaS in Austria

    The Problem: Manual Back-Office Work and Slow First-Response in a 201-500 Employee B2B SaaS

    Your operations and supply chain team in Vienna processes 1,200 invoices monthly, each taking 14 minutes of manual data entry, and your support desk answers 300 tickets a week with a median first-response time of 4.2 hours. The back-office work is repetitive, error-prone, and consuming 3.5 FTEs that could be redeployed. The EU AI Act, in force since August 2024, requires you to document your AI risk assessment before deploying any automated system that touches financial data. You need a fixed-scope pilot that delivers a measured before/after baseline in 4 weeks, not a 6-month transformation program. The pilot must work within your existing stack — Notion for documentation, your CRM for customer records, your ERP for invoice data — and must keep regulated data on Austrian infrastructure.

    Prerequisites Before Step 1

    • Process audit completed: You have mapped the invoice processing workflow from receipt to payment, timed each step, and counted error types. The audit output is a one-page document with baseline metrics: average cycle time (hours), error rate (%), and FTE hours consumed.
    • n8n instance deployed: A self-hosted n8n instance runs on your Austrian cloud or on-premises server. You have API credentials for your CRM, ERP, and helpdesk. The n8n version is 1.40 or later for stable webhook and AI node support.
    • RAG source material ready: Notion or Confluence contains at least 50 pages of operational documentation — vendor onboarding, invoice coding rules, escalation paths, SLA definitions. The content is current (updated within the last 30 days).
    • Human-in-the-loop approvers identified: You have named 2–3 people who will approve AI-drafted invoice entries and ticket responses. They understand the approval criteria and have access to the n8n approval UI.
    • EU AI Act risk assessment drafted: A one-page document classifying your RAG assistant as a limited-risk system, noting the transparency obligations, and confirming no special-category data is processed without consent.
    • Fixed-scope statement of work signed: The pilot scope, success metrics, and 4-week timeline are locked. No scope changes without a change order.

    Step 1: Run the Process Audit and Lock the Baseline

    Run a 2-hour process audit with your operations lead. Map every step from invoice receipt (email, portal, or EDI) to payment posting in the ERP. Time each step with a stopwatch or screen-recording tool. Count error types over the last 30 days: wrong vendor code, duplicate entry, missing tax ID, incorrect tax rate. Record the baseline: average cycle time in hours, error rate as a percentage, and total FTE hours consumed. Output: a one-page audit document with a workflow diagram and a table of error types with frequencies. This document is your before/after measurement anchor. Do not proceed to Step 2 until the baseline is signed off by the operations lead.

    Step 2: Build the n8n Invoice Extraction Workflow

    Build the n8n workflow for invoice extraction. Create a webhook node that receives the invoice PDF via email or ERP API. Add an AI node using OpenAI’s GPT-4o or Anthropic’s Claude 3.5 Sonnet for extraction — these models handle multi-column invoice layouts with 94–97% field accuracy on standard B2B invoices. Configure the extraction schema: vendor name, vendor tax ID, invoice number, line items, tax rate, total amount, due date. Add a validation node that checks for missing fields and flags anomalies (e.g., tax ID format mismatch, total exceeds PO amount by more than 5%). Route flagged invoices to a human approval node in n8n; route clean invoices to the ERP write-back node. Test with 50 historical invoices before going live.

    Step 3: Build the RAG Knowledge Assistant Over Notion or Confluence

    Set up the RAG index over your Notion or Confluence documentation. In n8n, create a workflow that pulls pages on an hourly schedule using the Notion API node or Confluence Cloud API. Chunk the content at 512 tokens with 64-token overlap. Embed using BGE-M3 or Cohere embed-v3 — both handle English and German, which matters for your Austrian team. Store embeddings in pgvector on your PostgreSQL instance. Build the RAG query workflow: receive a ticket or question, retrieve the top-5 chunks, pass them as context to the LLM, and return a grounded answer with source citations (page title and URL). Test with 20 real questions from your support team. If retrieval hit-rate is below 85%, re-chunk or re-embed. The RAG assistant must never answer without a source citation.

    Step 4: Integrate with CRM, ERP, and Helpdesk

    Integrate the n8n workflows with your existing systems. For the invoice workflow: connect the ERP write-back node to your ERP’s API (SAP, NetSuite, or similar) using the vendor’s REST or SOAP endpoint. For the RAG assistant: connect the helpdesk (Zendesk, Freshdesk, or Jira Service Management) via webhook so that incoming tickets trigger the RAG query workflow. The RAG workflow drafts a response, attaches the retrieved context, and routes it to the human approver. The approver edits or approves in the n8n UI, and the approved response sends via the helpdesk API. All integrations use your existing API credentials — no new accounts, no new systems. Test each integration with 10 real transactions in a staging environment before moving to production.

    Step 5: Run the 4-Week Pilot with Human-in-the-Loop Approval

    Run the pilot in shadow mode for 2 weeks. The n8n workflows process real invoices and tickets, but the human approver reviews every output before it reaches the ERP or the customer. Track three metrics daily: cycle time (from invoice receipt to ERP posting, or from ticket creation to first response), error rate (AI-drafted entries rejected or edited by the approver), and human-override rate (percentage of AI outputs that required manual correction). At the end of 2 weeks, compare against the Step 1 baseline. The pilot report must show: cycle time reduction in hours, error rate change in percentage points, and FTE hours saved. If cycle time drops by 40% or more and error rate stays below 5%, the pilot is a success. If not, diagnose the failure mode before proceeding to rollout.