Forfis Blog

Author: Forfis

  • Automating Lead Qualification in a UK E-Commerce Firm: An 8-Week Pilot

    1. The agent drafts, a human approves

    The pilot replaces the 45-to-90-minute manual review cycle with an agent that drafts a qualification tag and a first-response email in under 15 seconds. A human approves the tag before it hits the CRM. For a 2,000+ employee UK e-commerce firm, this single change removes the most repetitive back-office task in the marketing funnel and frees the analyst to work on campaign strategy instead of form-filling. The OpenAI API (GPT-4o) handles the natural-language layer; the RAG layer pulls product specs and pricing from Notion so the agent never quotes a discontinued SKU.

    2. It plugs into the CRM, not around it

    The agent connects to the CRM through its REST API, pulling lead records and writing back qualification tags. It does not replace the CRM; it adds a layer on top. The RAG layer indexes Notion or Confluence pages weekly, so product descriptions, shipping policies, and objection-handling scripts stay current. For a firm running monthly reporting cycles, this means the agent’s knowledge base refreshes without a manual export-and-reload step. The integration adds roughly 2-3 days of engineering within the 8-week window and requires only read-only API tokens from the documentation platform.

    3. Eight weeks, one process, one channel

    The 8-week timeline is fixed: Weeks 1-2 are the process audit, mapping where manual back-office work concentrates in the lead-qualification flow. Weeks 3-4 cover API provisioning, RAG build, and prompt engineering. Weeks 5-6 are the pilot build, wiring the agent to the CRM and configuring the approval gate. Week 7 is a controlled run on a subset of real leads, measuring cycle time and error rate against the pre-pilot baseline. Week 8 is the readout and handover. The client’s IT team must provision API keys and CRM access within the first five business days; that is the single most common schedule risk.

    4. The baseline is measured, not estimated

    The pilot ships with a one-page report comparing pre- and post-pilot metrics. Cycle time drops from a median of 45-90 minutes per lead to 8-15 minutes for the agent-drafted portion. Error rate on qualification tags falls from 12-18% (manual, fatigued) to under 4% with the agent plus human approval. These numbers are not projections; they are measured during the Week 7 controlled run. The report also logs every escalation to a human, so the client can see exactly where the agent’s confidence dropped and adjust the RAG content or prompt accordingly before any rollout decision.

    5. The team is dedicated, not shared

    The dedicated AI team runs in two-week sprints with a demo at the end of each. The client assigns one point of contact, usually a marketing operations manager, who provides CRM access, Notion or Confluence tokens, and the existing lead-qualification SOP. The team does not touch the ERP, helpdesk, or any other system. The model-agnostic architecture means the OpenAI API is used for the conversational layer because quality matters for natural-language understanding, but the orchestration code is written so that a different model provider can be swapped in without rewriting the integration. This keeps the client from being locked into a single vendor’s pricing or rate-limit policy.

    6. What the pilot does not include

    The pilot is fixed-scope: one process, one channel, one CRM, one documentation source. Deliverables are the working agent, the RAG layer, the CRM integration, the approval flow, the baseline report, and a one-page operations runbook. Out of scope: multi-channel rollout, additional processes like monthly reporting or invoice processing, model fine-tuning, and any changes to existing systems. If the pilot meets the baseline targets, a second phase can extend the agent to phone or chat-widget channels or automate a second process, but that is a separate engagement with its own scope, timeline, and cost. The fixed-scope structure keeps the 8-week commitment honest and the client’s risk bounded.

  • 4-Week AI Voice Agent Pilot for Order Status in UAE Professional Services

    1. Start with a Process Audit, Not a Model

    Before writing a single line of code, Forfis runs a process audit across the firm’s back-office workflows. For a 201-500 person professional services company in the UAE, this means mapping every step in order intake, shipment tracking, and client communication. The audit measures baseline cycle time and error rate for each workflow — not estimates, but logged timestamps from the existing Zendesk or Intercom queue. The output is a prioritized roadmap: which workflows to automate first, which to defer, and what the success metrics will be. This step takes roughly five working days and costs a fixed fee. It prevents the most common failure mode in AI projects: building a solution for a workflow nobody actually uses.

    2. Scope the Pilot to One Workflow

    The pilot targets order and shipment status updates — the highest-volume, lowest-complexity workflow in most professional services firms. A voice agent, built on LangChain and LangGraph, answers inbound calls and chat messages with real-time status pulled from the firm’s ERP or logistics API. LangGraph handles the stateful logic: if the shipment is delayed, the agent escalates to a human; if it’s on time, it responds directly. The integration plugs into Zendesk or Intercom through their native APIs, so existing ticket queues and SLA reporting stay intact. The pilot runs for four weeks with a fixed scope: one workflow, one channel, one success metric. No scope creep, no open-ended discovery.

    3. Build the Compliance Boundary First

    The UAE’s Federal Decree-Law No. 45 of 2021 on personal data protection aligns closely with GDPR in its core obligations: lawful basis for processing, purpose limitation, and data subject rights. For a professional services firm handling client names, addresses, and contract references, the practical constraint is that data cannot leave the jurisdiction without explicit consent and a data processing agreement. Forfis addresses this two ways: where data can flow through cloud APIs, it uses OpenAI or Anthropic endpoints with contractual data-processing addenda; where it cannot, it deploys open-weight models on the client’s own hardware. The architecture is model-agnostic by design, so the compliance boundary determines the model, not the other way around.

    4. Keep a Human in the Loop by Default

    The voice agent drafts responses; a human approves anything that touches a contract, a refund, or a client’s legal standing. This is not a technical limitation — it is a deliberate design choice that satisfies GDPR Article 22 (right not to be subject to automated decision-making with legal effects) and the UAE’s equivalent provisions. In practice, the agent handles 70-80% of routine status queries autonomously. The remaining 20-30% — delayed shipments, disputed invoices, contract amendments — route to a human queue with full context attached. The firm’s existing support team in customer support reviews and approves these within the same Zendesk or Intercom interface they already use. No new tooling, no new training cycle.

    5. Measure Error Rate, Not Just Speed

    The pilot ships with a measured before/after baseline: cycle time per interaction, error rate on data entry, and cost per resolved ticket. For a firm processing 400-600 status inquiries per week, the typical result is a 35-50% reduction in average handling time and a measurable drop in transcription and data-entry errors. The four-week timeline is fixed: Week 1 is audit and baseline, Week 2 is integration build, Week 3 is model tuning and internal testing, Week 4 is soft launch with live traffic. If the pilot hits its success metric, the firm moves to rollout across additional workflows. If it does not, the fixed-scope structure means the firm has lost a bounded amount of time and money, not an open-ended engagement.

    6. Plan for Managed Operations from Day One

    A pilot that ends with a demo is a pilot that fails. Forfis delivers the system as a managed AI operations engagement: the firm gets a monthly performance report with cycle time, error rate, and cost per interaction; Forfis monitors prompt drift, manages API costs, and updates the system as business rules change. The voice agent’s response templates are versioned and auditable. Model selection is revisited quarterly — if a new open-weight model outperforms the current one on the firm’s specific task, the swap happens without re-architecting the integration. The firm’s IT team retains full visibility into the system through standard API logs and access controls. This is the difference between a one-time build-and-handover and a system that keeps performing as the firm’s volume and rules evolve.

  • Swiss Fintech Cuts First-Response Time to 11 Minutes with a 4-Week RAG Pilot

    The Problem: 4-Hour First-Response Times in a Swiss Fintech

    A 2,000+ employee fintech in Switzerland was running support on a legacy helpdesk with a 4-hour first-response SLA. The legal and compliance team flagged that every support interaction touching payment disputes or customer PII required manual review, creating a bottleneck that scaled linearly with ticket volume. The AI maturity stage was running isolated pilots: the team had tested a single chatbot on a sandbox channel but had not measured cycle time or error rate against a baseline. The goal was to cut first-response time to under 15 minutes for routine queries while keeping human approval on anything touching money, contracts, or regulated data. The constraint was strict: regulated data could not leave the building, and the system had to satisfy ISO 27001 audit requirements for access control and logging.

    Architecture: pgvector RAG with Model-Agnostic Inference

    The architecture used pgvector for embeddings search over the company’s policy documents, product manuals, and CRM records. When a ticket arrived, the system generated an embedding for the query, retrieved the top-5 most similar document chunks, and passed them to the model as context. The model was model-agnostic: OpenAI’s GPT-4o handled non-sensitive drafting tasks via API, while an open-weight Llama 3 70B model ran on the client’s own GPU hardware for anything involving customer PII or transaction data. The integration layer used custom REST APIs and webhooks to pull ticket data from the existing helpdesk, push drafted responses back, and trigger approval workflows. No existing system was replaced; the AI layer sat on top of the CRM, ERP, and helpdesk through their native APIs.

    The 4-Week Pilot: Scope, Baseline, and Approval Workflow

    The pilot ran for 4 weeks on a single support channel with a limited document set of 200 policy and product documents. Week 1 covered the process audit: mapping ticket categories, identifying the top 5 highest-volume workflows, and defining the approval rules. Weeks 2-3 handled integration and model tuning: wiring the REST API to the helpdesk, building the pgvector index, and calibrating the retrieval threshold. Week 4 measured the before/after baseline: cycle time, error rate, and escalation rate. The workflow orchestration layer ensured that any ticket flagged as high-risk (payment dispute, contract amendment, health data) routed to a human before any response was sent. Routine queries were auto-approved after the model’s confidence score exceeded 0.92.

    Results: 38% Error Reduction and 11-Minute First Response

    The pilot measured a 38% reduction in error rate on routine queries and a 72% drop in first-response time from 4.2 hours to 11 minutes. The cost per support ticket fell by 22% in the pilot channel, driven by fewer escalations and reduced manual drafting time. The legal and compliance team reviewed every model output during the pilot and flagged 3 cases where the RAG retrieval had pulled an outdated policy document; the fix was a versioning tag on the pgvector index so the model always retrieved the current document. The candidate screening use case, tested in parallel, reduced time-to-screen from 3 days to 6 hours, with a recruiter approving every shortlist decision. The pilot’s success criteria were met on all three metrics: cycle time, error rate, and compliance audit trail completeness.

    Rollout and Managed Operations: From Pilot to Production

    Post-pilot, the organization moved to managed AI operations: continuous monitoring of model performance, drift detection on the pgvector index, prompt and embedding updates, and SLA management. The vendor handled model versioning, retraining when accuracy dropped below the 0.92 threshold, and compliance reporting for ISO 27001 audits. The rollout expanded to three additional support channels over 8 weeks, with each channel running as an isolated pilot before scaling. The legal and compliance team reviewed each new use case’s data handling, model selection, and approval workflow before go-live. The managed operations contract included monthly accuracy reports, quarterly compliance reviews, and a 4-hour incident response SLA for model degradation or data breach events.

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

    The problem: manual ticket triage at 500 tickets per week

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

    Prerequisites: what you need before week 1

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

    Step 1: Run the process audit and lock the scope

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

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

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

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

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

    Step 4: Measure the pilot against the baseline

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

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

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

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

  • RAG-Powered Conversational Agent for Contract Review in a UK Fintech

    The Problem: Manual Back-Office Bottlenecks in a 100-Person Fintech

    A 100-person UK fintech processes 400+ contracts and 1,200 invoices monthly. Finance staff spend 12 hours compiling monthly reports and 6 hours reviewing contract clauses. The manual process introduces a 3% error rate in data entry and a 48-hour cycle time for contract queries. The goal is to reduce cycle time to under 4 hours and error rate to under 0.5% without replacing the existing ERP, CRM, or Slack workspace. The solution is a RAG-powered conversational agent that drafts responses, classifies documents, and automates data gathering, with human approval for any output touching financial figures or contractual obligations. The deployment fits an 8-week timeline, starting with a process audit and ending with managed operations.

    Mechanism: RAG Pipeline with pgvector and Conversational Agent

    The architecture uses a RAG pipeline with pgvector for embedding search. Contract PDFs are ingested, OCR-processed, and chunked into 512-token segments. Each chunk is embedded using text-embedding-3-small into a 1536-dimensional vector and stored in a Postgres 15 instance with the pgvector extension. The HNSW index is configured with m=16 and ef_construction=64 for sub-50 ms retrieval. The conversational agent runs on Slack via the Bot API, listening for mentions in a #contract-review channel. When triggered, it embeds the query, retrieves top-10 chunks, and passes them to GPT-4o for drafting. If the response references payment terms or liability caps, it flags the message for human review in a #approval channel. The model-agnostic layer allows switching to Llama 3 on client hardware for regulated data.

    Trade-offs: Model Choice, Human-in-the-Loop, and Timeline

    The architect chooses between OpenAI/Anthropic APIs and open-weight models based on data sensitivity. API models offer higher quality but require data to leave the building. Open-weight models like Llama 3 run on client GPU hardware, ensuring data residency but requiring 2x the engineering effort for fine-tuning and monitoring. The human-in-the-loop design adds a 15-minute approval delay for flagged responses but reduces the error rate from 3% to 0.4%. The 8-week timeline is tight; adding a second department mid-pilot extends it to 12 weeks. The managed operations model shifts the burden of model updates and index maintenance to Forfis, costing a fixed monthly fee but reducing the client’s engineering overhead by 60%.

    Recommendation: 8-Week Deployment Plan for UK Fintech

    Start with a process audit in Week 1-2 to measure baseline cycle time and error rate. Fix the pilot scope to one department (Finance) and one channel (Slack) in Week 3. Build the RAG pipeline and conversational agent in Week 4-5, using pgvector for embedding search and GPT-4o for drafting. Run the human-in-the-loop pilot in Week 6-7, measuring the delta in cycle time and error rate. Roll out to the full Finance team in Week 8 and hand over to managed operations. Avoid adding departments or channels mid-pilot. Ensure the ERP and CRM API documentation is complete before Week 3 to prevent custom connector delays. The managed operations SLA should include 99.5% uptime, 4-hour critical response, and monthly performance reports.

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

  • Fintech in the UAE: 8-Week Pilot to Automate Contract Review with On-Premise AI

    The 18-Minute Contract Review That Eats a Finance Team’s Week

    A 15-person fintech in the UAE processes 300 to 500 contracts per month. Each contract requires a finance analyst to open the document, locate the payment terms, extract the amounts, and enter them into SAP. The average cycle time is 18 minutes per contract, with a 7% error rate on data entry. The analyst spends 40% of their week on this task, which means they are not doing the reconciliation, forecasting, or vendor management that actually requires judgment. The pain is not that the work is hard; it is that it is repetitive, error-prone, and it consumes the time of the person who should be doing higher-value work. The metric that matters is not the cost of the analyst’s salary; it is the opportunity cost of the 40% of their week that is spent on data entry.

    Why Hiring More Analysts and Buying RPA Both Fail

    The first approach is to hire more analysts. This works until the volume grows, and then the problem scales with the headcount. The second approach is to use a commercial RPA tool to automate the data entry. RPA works for structured data in fixed formats, but contracts are semi-structured. The payment terms might be in a table, a paragraph, or a footnote. The RPA bot breaks when the format changes, and the maintenance cost of keeping the bot working across 500 different contract templates is higher than the cost of the analyst. The third approach is to use a commercial AI API to extract the data. This works, but the contract data leaves the building. For a fintech in the UAE, where the data includes payment terms, vendor names, and amounts, sending that data to a third-party API is a risk that the compliance team will flag. The problem is not that the technology is unavailable; it is that the available options do not fit the constraints of a small team with sensitive data and no dedicated compliance function.

    On-Premise RAG With a Human Approval Gate

    The approach that fits is a retrieval-augmented knowledge assistant built on open-weight models running on the company’s own hardware. The system ingests the contract, retrieves the relevant clauses, and extracts the payment terms, amounts, and dates. The output is a structured form that the finance analyst reviews and approves before it enters SAP. The model is model-agnostic: the pilot uses an open-weight model on-premise because the data cannot leave the building, but the architecture allows switching to a commercial API for workflows where the data is less sensitive. The integration is through the SAP API, not a replacement of SAP. The human-in-the-loop step is not a limitation; it is the design. The analyst sees the AI’s output, can edit it, and clicks approve. The system logs every approval and rejection, which creates an audit trail. The pilot is fixed-scope: one workflow, one integration, one measured baseline, 8 weeks.

    Eight Weeks From Audit to Measured Baseline

    Week 1: run the process audit. Map the contract review workflow step by step. Measure the current cycle time and error rate. Identify where the data enters and leaves the system. Check whether SAP has an API that can be used for integration. The output is a one-page recommendation with a projected ROI calculation. Week 2: select the model. For a fintech in the UAE where the data is sensitive, an open-weight model on the company’s own hardware is the right choice. The model should be capable of extracting structured data from semi-structured text. Week 3 to 4: build the RAG pipeline. Ingest the contract, retrieve the relevant clauses, extract the data, and populate the form. Week 5 to 6: build the approval interface. The analyst sees the AI’s output, can edit it, and clicks approve. The system logs every action. Week 7: integrate with SAP. The approved data enters the ERP through the API. Week 8: measure the baseline. Compare the cycle time and error rate against the pre-pilot numbers. The deliverable is a working system with documented metrics, not a proof of concept.

  • Managed Cloud vs. On-Premises AI Automation for Healthcare Invoice Processing

    Managed Cloud AI Services vs. On-Premises AI Deployments

    The two options under comparison are a managed cloud AI service and an on-premises or private-cloud AI deployment. The managed cloud service uses third-party APIs, such as OpenAI or Anthropic, to process documents and generate responses. Data is sent to the vendor’s servers, processed, and returned. The on-premises deployment runs open-weight models, such as Llama 3 or Mistral, on the client’s own hardware or a private cloud instance. Data never leaves the client’s infrastructure. Both options can handle document extraction, conversational agents, and retrieval-augmented assistants, but they differ in latency, cost, compliance posture, and operational burden. For a 51-200 employee company in healthcare and medtech, the choice hinges on whether the data being processed is subject to GDPR or HIPAA restrictions.

    Comparison Criteria

    The criteria for this comparison are: latency (time from document upload to processed output), cost (total cost of ownership over 6 months), vendor lock-in (ability to switch providers without rework), compliance (GDPR Article 32 security, HIPAA BAA requirements), integration complexity (effort to connect to existing ERP, CRM, and helpdesk systems), human-in-the-loop overhead (time spent reviewing AI output), scalability (ability to add workflows without re-architecting), and data residency (where data is stored and processed). These criteria are weighted differently depending on the company’s regulatory environment. For a healthcare and medtech company in the USA, compliance and data residency carry the highest weight. For a B2B SaaS company in fintech, latency and cost may dominate. The following table presents concrete values for each criterion.

    Comparison Table

    Criterion Managed Cloud AI Service On-Premises AI Deployment
    Latency 18-45 ms per document, depending on model size and network distance 8-25 ms per document, assuming local GPU inference
    Cost (6 months) $12,000-$28,000, based on API usage and volume $35,000-$80,000, including hardware, setup, and maintenance
    Vendor lock-in High; switching requires retraining prompts and re-integrating APIs Low; open-weight models can be swapped without re-architecting
    Compliance GDPR Article 44 requires SCCs or adequacy decision; HIPAA BAA required GDPR Article 32 satisfied by data staying in client infrastructure; HIPAA BAA not required
    Integration complexity Low; standard REST APIs, 2-4 weeks to integrate Medium; requires GPU provisioning, model serving, 4-8 weeks to integrate
    Human-in-the-loop overhead Low; high accuracy on standard documents, 5-10% review rate Medium; open-weight models may have 10-20% review rate on complex documents
    Scalability High; add workflows by increasing API usage Medium; add workflows by provisioning additional GPU capacity
    Data residency Data leaves client infrastructure, stored in vendor’s region Data stays in client’s infrastructure, region controlled by client

    When the Managed Cloud Service Wins

    The managed cloud service wins when the company processes non-sensitive data, such as internal process documentation or public-facing content. For a B2B SaaS company automating ticket triage or first-response agents, the cloud service’s 18-45 ms latency and $12,000-$28,000 six-month cost make it the pragmatic choice. The integration effort is low, and the human-in-the-loop overhead is minimal because the models are fine-tuned on large, diverse datasets. The on-premises deployment wins when the company handles PHI, GDPR-regulated personal data, or financial records that cannot leave the building. For a healthcare and medtech company in the USA, the on-premises option satisfies GDPR Article 32 and HIPAA requirements without relying on third-party BAAs. The trade-off is higher upfront cost and longer integration time, but the compliance posture is stronger.

    Recommendation for Healthcare and Medtech Companies

    For a 51-200 employee company in healthcare and medtech, the on-premises deployment is the recommended option if the company processes PHI or GDPR-regulated personal data. The fixed-scope pilot should focus on one workflow, such as invoice processing or monthly reporting, and include a measured before/after baseline on cycle time and error rate. The architecture should use pgvector for embeddings search over the company’s Notion or Confluence documentation, and a conversational agent for routine inquiries. Human-in-the-loop approval is mandatory for any output that touches money, health data, or contracts. The 6-month timeline is realistic: months 1-2 for process audit and pilot design, months 3-4 for pilot build and testing, month 5 for validation, and month 6 for rollout and handoff to managed operation. The total cost of ownership, including hardware, setup, and 6 months of managed operation, should be budgeted at $50,000-$100,000.

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

    What Is Being Compared

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

    Criteria for Judgment

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

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

    Side-by-Side Comparison

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

    Scenario-by-Scenario Verdict

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

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

    Recommendation

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

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