Forfis Blog

Tag: UK

  • AI-Native Contract Review vs Manual Legal Workflows: A UK Fintech Comparison

    What Is Being Compared

    The comparison centers on two operational models for contract review in a 51-200 person UK fintech: manual legal review (current state) and AI-native operations (target state). Manual review relies on senior lawyers reading each clause, flagging risks, and drafting redlines. AI-native operations uses a pgvector embeddings search pipeline to retrieve similar clauses, apply predictive scoring to risk assessment, and generate first-draft responses. The AI layer integrates with existing Confluence or Notion documentation, the CRM, and the helpdesk via APIs, without replacing any tool. Both models must satisfy PCI DSS requirements for payment contracts and free senior staff from routine work within a 6-month timeline.

    Criteria for Judgment

    We judge both models against eight criteria: cycle time (hours from receipt to approval), error rate (missed risk clauses per 100 contracts), cost per contract (fully loaded), vendor lock-in (ability to switch models or tools), compliance (PCI DSS, UK GDPR), scalability (contracts/hour without adding headcount), audit trail (traceability of decisions), and staff utilization (senior hours on high-value work). Each criterion carries a quantitative target: cycle time under 4 hours for standard agreements, error rate below 2%, cost under £150 per contract, no single-vendor dependency, full PCI DSS Requirement 3.5.1 compliance, 50+ contracts/hour, immutable decision logs, and 60%+ of senior time on negotiation and strategy.

    Comparison Table

    Criterion Manual Legal Review AI-Native Operations
    Cycle time 3-5 days (18-30 hours) Under 4 hours for standard agreements
    Error rate 5-8% missed risk clauses Below 2% with human-in-the-loop approval
    Cost per contract £400-600 (senior lawyer time) Under £150 (API + infrastructure)
    Vendor lock-in None (human-dependent) Model-agnostic: OpenAI/Anthropic APIs + open-weight on client hardware
    Compliance Manual PCI DSS checks, error-prone Automated PCI DSS Requirement 3.5.1 validation, immutable audit trail
    Scalability 5-10 contracts/hour per lawyer 50+ contracts/hour without added headcount
    Audit trail Email threads, version control Immutable decision logs with clause-level traceability
    Staff utilization 70% on routine review 60%+ on negotiation, strategy, regulatory interpretation

    When Manual Review Wins

    Manual review wins when contracts are highly novel, involve unprecedented regulatory interpretations, or require nuanced negotiation strategy. A 51-200 person fintech handling bespoke payment product agreements or cross-border regulatory filings benefits from senior lawyers’ judgment on ambiguous clauses. AI-native operations wins for high-volume, template-based contracts: standard merchant agreements, data processing addenda, and service level agreements. The predictive scoring model trains on the firm’s own reviewed contracts in Confluence or Notion, using pgvector embeddings to retrieve similar clauses and assign risk probabilities. For a UK fintech processing 200+ contracts/month, the AI layer handles 80% of routine review, freeing senior staff for the 20% requiring human judgment.

    When AI-Native Operations Wins

    AI-native operations wins when the firm has 50+ contract types, 30+ hours/week of routine review, and existing documentation in Confluence or Notion. The integration sprint delivers a working pipeline in 4-6 weeks: document ingestion, pgvector embeddings search, predictive scoring, and human-in-the-loop approval gates. Round-the-clock customer response is enabled by the AI layer handling first-response triage, while humans approve final decisions. The model-agnostic architecture uses OpenAI or Anthropic APIs for high-quality clause analysis and open-weight models on client hardware for regulated data that cannot leave the building. For a 51-200 person UK fintech, the 6-month timeline includes a 2-week audit, 4-week pilot on one contract type, and 4 months of phased rollout, with PCI DSS validation and staff training built into the schedule.

    Recommendation

    For a 51-200 person UK fintech in the payments sector, AI-native operations is the recommended model. The firm’s contract volume, existing Confluence or Notion documentation, and PCI DSS compliance requirements align with the AI layer’s strengths. The integration sprint delivers a working pipeline in 4-6 weeks, with human-in-the-loop approval ensuring compliance throughout. The 6-month timeline includes buffer for PCI DSS validation and staff training, ensuring the AI layer operates within the firm’s existing compliance framework. Senior staff are freed from routine work, focusing on negotiation strategy and regulatory interpretation. The model-agnostic architecture avoids vendor lock-in, using OpenAI or Anthropic APIs where quality matters and open-weight models on client hardware where regulated data cannot leave the building.

  • AI Lead Qualification Pilot for UK Professional Services Firms

    The Problem: Manual Lead Qualification in Professional Services

    Professional services firms in the UK with 201-500 employees often struggle with lead qualification. The process is manual, time-consuming, and error-prone. Sales teams spend hours reviewing inbound leads, checking their fit, and updating CRM records. This manual work is not only costly but also introduces errors, such as misclassifying a lead or missing key details. The result is a lower conversion rate and a higher cost per support ticket. The problem is not a lack of leads, but a lack of efficient processes to handle them. This deep dive explores how a conversational agent, built on the OpenAI API and integrated with Notion, can automate this process. The goal is to reduce the error rate in the back office and lower the cost per support ticket, all within a 2-week fixed-scope pilot.

    Mechanism: How the Conversational Agent Works

    The system consists of three main components: the conversational agent, the knowledge base, and the integration layer. The agent is built using the OpenAI API, specifically the GPT-4o-mini model, which offers a balance of cost and performance. The agent is designed to handle multi-turn conversations, asking qualifying questions and providing relevant information. The knowledge base is stored in Notion, which is integrated via the Notion API. The agent uses Retrieval-Augmented Generation (RAG) to pull relevant snippets from Notion to answer questions. The integration layer connects the agent to the company’s existing systems, such as the CRM and email. The architecture is model-agnostic, allowing for future migration to other models if needed. The system is designed to be human-in-the-loop, with a person approving any action that touches money or contracts.

    Trade-offs: Cost, Quality, and Human Oversight

    The primary trade-off is between cost and quality. Using GPT-4o-mini reduces the cost per ticket, but it may not handle complex, multi-turn conversations as well as GPT-4o. The architect must decide which model to use based on the complexity of the lead qualification process. Another trade-off is between automation and human oversight. A fully automated system is faster and cheaper, but it introduces the risk of errors. A human-in-the-loop system is slower and more expensive, but it reduces the risk of errors. The architect must find the right balance between these two. The integration with Notion also introduces a trade-off: it provides a rich knowledge base, but it requires ongoing maintenance to keep the content up-to-date. The architect must decide how much effort to invest in maintaining the knowledge base.

    Recommendation: A 2-Week Fixed-Scope Pilot

    For a 201-500 employee professional services firm in the UK, the recommendation is to start with a 2-week fixed-scope pilot. The pilot should focus on one specific workflow, such as lead qualification for a particular service line. The agent should be built using the OpenAI API and integrated with Notion. The pilot should measure the baseline metrics, such as cycle time, error rate, and cost per ticket. After the 2-week period, the results should be compared against the baseline. If the pilot shows a reduction in error rate and cost per ticket, the firm should consider a full rollout. The rollout should include a more comprehensive integration with the CRM and other systems. The firm should also consider using a human-in-the-loop design to reduce the risk of errors. The pilot should be designed to be scalable, so that it can be expanded to other workflows in the future.

  • Candidate Screening AI for UK Logistics: n8n Pilot vs. Full Rollout

    What Is Being Compared

    The two options under comparison are commercial API-based AI assistants (OpenAI GPT-4o or Anthropic Claude 3.5 Sonnet, called via REST) and open-weight models on client hardware (Llama 3 70B or Mistral 8x22B, served via vLLM or Ollama). Both sit behind the same n8n orchestration layer, the same Notion or Confluence knowledge base, and the same human-in-the-loop approval gate. The difference is where inference runs and what data leaves the building. For a 51-200 person logistics firm in the UK running candidate screening as a fixed-scope pilot, this choice determines GDPR posture, cost structure, and latency budget. The pilot scope is one hiring team, 30 to 80 candidates per month, with a measured before/after baseline on screening cycle time and mis-screening error rate.

    Criteria

    Five criteria drive the decision for this scenario:

    • GDPR data residency: whether candidate PII can leave the UK/EEA boundary, and what Article 28 processor agreements are required.
    • Latency per screening cycle: the model must return a scored draft in under 90 seconds so the recruiter can act within the same working day.
    • Cost at pilot volume: 30 to 80 candidates per month, each generating roughly 2,000 to 4,000 tokens of input and 500 to 800 tokens of output.
    • Scoring accuracy on structured rubrics: the model must apply a weighted criteria matrix from Notion consistently, not just summarise.
    • Integration surface: the n8n workflow must call the model via a stable HTTP endpoint, regardless of which backend is active.
    • Vendor lock-in: switching from one model to another should be a configuration change, not a code rewrite.
    • Compliance audit trail: every model output must be logged with a timestamp, model version, and the recruiter’s approval or override.

    Comparison Table

    Criterion Commercial API (GPT-4o / Claude 3.5) Open-Weight on Client Hardware (Llama 3 70B)
    GDPR data residency PII transits to US or EU region; requires Article 28 DPA and SCCs PII stays on client hardware in UK; no cross-border transfer
    Latency per screening cycle 8 to 15 seconds for a 3,000-token input 12 to 25 seconds on a single A100; 6 to 10 seconds on 2x A100
    Cost at pilot volume (50 candidates/month) EUR 15 to 40 in API fees EUR 1,200/month GPU rental or EUR 8,000 one-off for a used A100
    Scoring accuracy on weighted rubrics 92 to 96 percent agreement with human rubric in Forfis pilot data 85 to 90 percent agreement; weaker on multi-criteria weighting
    Integration via n8n HTTP POST to OpenAI or Anthropic endpoint; stable SDK HTTP POST to vLLM or Ollama endpoint; same request shape
    Vendor lock-in Tied to OpenAI or Anthropic pricing and model deprecation schedule Model weights are downloadable; no per-token fee; no vendor deprecation risk
    Audit trail API logs available; model version pinned in request header Full inference logs on client hardware; model version is the checkpoint hash

    Scenario-by-Scenario Verdict

    When the commercial API wins: if the candidate data is non-sensitive (public CVs, no health data, no financial history) and the firm wants the highest scoring accuracy with zero infrastructure management, GPT-4o or Claude 3.5 Sonnet is the faster path. The 8 to 15 second latency fits comfortably inside the 90-second screening budget. At 50 candidates per month, the API cost is under EUR 40, which is negligible against the pilot budget. The n8n workflow calls the API, writes the draft to the ATS, and notifies the recruiter. The model-agnostic adapter means that if the firm later switches to an on-prem model, the n8n workflow changes only the endpoint URL.

    When the open-weight model wins: if the logistics firm handles candidate data that includes health declarations, right-to-work documents, or salary history, and the DPO has ruled that PII cannot leave the UK, Llama 3 70B on a single A100 is the only compliant path. The 12 to 25 second latency is still inside the 90-second budget. The EUR 1,200 monthly GPU cost is higher than the API fee, but it eliminates the cross-border transfer risk entirely and the per-token fee does not scale with volume. For a firm that will scale to 500 candidates per month in the rollout phase, the on-prem model becomes cheaper above roughly 50,000 tokens per day.

    Recommendation

    For a 51-200 person UK logistics firm running a fixed-scope candidate screening pilot with a 6-month timeline, the recommendation is open-weight Llama 3 70B on client hardware, orchestrated by n8n, with the scoring rubric in Notion. The reasoning is specific: the firm is in logistics, where candidate data routinely includes right-to-work documents and sometimes health declarations for warehouse roles; the DPO will flag any cross-border PII transfer; and the pilot volume of 30 to 80 candidates per month makes the EUR 1,200 monthly GPU cost a manageable line item. The n8n workflow triggers on a new ATS record, fetches the CV and the Notion rubric, calls the vLLM endpoint, writes the scored draft back to the ATS, and pings the recruiter. The human-in-the-loop gate means no candidate advances without a recruiter’s explicit approval. The before/after baseline, measured in weeks 1 and 12, should show a 40 to 60 percent reduction in screening cycle time and a 25 to 40 percent reduction in mis-screening error rate. The model-agnostic adapter ensures that if the firm later adds a commercial API for a non-sensitive sub-task, the n8n workflow changes only the routing rule, not the code.

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

    1. Audit the Current Lead-Qualification Workflow

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

    2. Define the Pilot Scope and Success Metrics

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

    3. Map ISO 27001 Controls to the AI Layer

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

    4. Configure the Anthropic Claude API and Integration Layer

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

    5. Integrate with Notion or Confluence for Knowledge Grounding

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

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

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

    7. Run the Pilot and Measure Before/After Baselines

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

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

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

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

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

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

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

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

    Approach: A 4-Week Integration Sprint on Anthropic Claude

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

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

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

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

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

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

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

    Lessons for Similar Teams

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

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

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

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

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

  • Deploying a RAG Assistant for Lead Qualification in a UK Healthcare Company

    The Problem: Manual Lead Qualification and Document Turnaround in a Regulated Environment

    You run a 2,000+ employee healthcare and medtech company in the UK. Your sales team spends 12-15 hours per week manually qualifying inbound leads, extracting data from PDFs and spreadsheets, and updating CRM records. Monthly reporting takes 3-5 days of back-office work. You need faster document turnaround and automated monthly reporting, but you cannot send patient-identifiable data to third-party APIs without explicit consent. You must comply with UK GDPR and the Data Protection Act 2018. This guide walks you through a 3-month integration sprint to deploy a retrieval-augmented knowledge assistant that grounds answers in your own CRM and document corpus, using OpenAI API where quality matters, with human-in-the-loop review for anything touching health data or contracts.

    Prerequisites: What You Need Before Step 1

    • CRM access: API credentials for Salesforce or HubSpot, with read/write permissions for the relevant objects (Leads, Contacts, Opportunities, Cases).
    • Document corpus: A structured repository of your internal documents, product specs, and compliance policies, stored in a format the RAG pipeline can ingest (PDF, DOCX, HTML).
    • Data mapping: A documented schema of your CRM fields, including which fields contain personal data, health data, or financial figures.
    • GDPR compliance: A signed DPA with your AI vendor, a data processing impact assessment, and a lawful basis under GDPR Article 6 for processing personal data.
    • Baseline metrics: Measured cycle time and error rate for your current lead qualification and document turnaround workflows, captured over a 2-week period.
    • Human-in-the-loop workflow: A defined approval process for anything touching money, health data, or contracts, with named reviewers and SLAs.

    Step 1: Map Data Sources and Compliance Boundaries

    1. Map your data sources and compliance boundaries. Identify which CRM fields and document types contain personal data, health data, or financial figures. Tag each field with its GDPR lawful basis and purpose limitation. This mapping determines which data can be sent to OpenAI API and which must stay on-premise. Use a spreadsheet with columns for field name, data type, GDPR category, and permitted processing locations.

    2. Build the vector store and ingestion pipeline. Ingest your document corpus into a vector database (e.g., Pinecone, Weaviate, or pgvector). Chunk documents at 512 tokens with 50-token overlap. Embed using OpenAI’s text-embedding-3-small model. Store metadata (document ID, section, last updated date) alongside each vector. Test retrieval precision: for 50 sample questions, measure the percentage of retrieved passages that are relevant. Target 80% or higher.

    Step 2: Integrate with Salesforce or HubSpot CRM

    1. Integrate with your CRM via API. Connect the RAG assistant to Salesforce or HubSpot using their REST APIs. For Salesforce, use the /services/data/v58.0/sobjects/Lead endpoint to read and write lead records. For HubSpot, use the /crm/v3/objects/contacts endpoint. Implement OAuth 2.0 authentication with refresh tokens. Test bidirectional data flow: the assistant reads inbound leads, scores them, and writes the score and tags back to the CRM. Log all API calls for audit purposes under GDPR Article 30.

    Step 3: Configure the RAG Pipeline with OpenAI API

    1. Configure the RAG pipeline with OpenAI API. Use OpenAI’s gpt-4o model for generation and text-embedding-3-small for embeddings. Set the temperature to 0.2 for deterministic answers. Implement a retrieval step that fetches the top 5 most relevant passages from the vector store. Feed these passages to the model with a system prompt that instructs it to answer only from the provided context and cite sources. Log all prompts and responses for audit purposes. Store logs in an encrypted database with access controls.

    Step 4: Implement Human-in-the-Loop Review

    1. Implement human-in-the-loop review. Define the approval workflow: the assistant drafts or classifies, but a person approves anything that touches money, health data, or contracts. For lead qualification, the assistant scores and tags leads, but a sales rep confirms the final disposition. For document extraction, the AI populates CRM fields, but a human reviews and approves before the record is saved. Build a review dashboard with a queue of pending approvals, each showing the AI’s draft, the source passages, and an approve/reject button. Track approval time and rejection rate.

    Step 5: Run User Acceptance Testing and Measure the Baseline

    1. Run user acceptance testing and measure the baseline. Conduct UAT with 5-10 sales reps over 2 weeks. Measure cycle time and error rate for lead qualification and document turnaround. Compare against your pre-pilot baseline. Target a 60-80% reduction in manual data entry and a 50-70% reduction in lead response time. If retrieval precision is below 80%, clean your data and re-run UAT. If error rate is above 5%, adjust the system prompt or retrieval parameters. Document all findings in a UAT report.

  • Fixed-Scope Pilot vs. In-House Build: Lead Qualification for a UK Fintech

    What Is Being Compared

    The two options are distinct in scope and risk profile. Option A is a fixed-scope pilot delivered by an external product studio: a 6-8 week engagement on one workflow—lead qualification—using the Anthropic Claude API as the model layer, integrated via custom REST API and webhooks into the existing CRM. The studio handles technical planning, product design, and full-cycle development. The pilot ships with a measured before/after baseline on cycle time and error rate. Option B is a fully in-house build: the company’s own engineering team designs, develops, and operates the agent, using the same model API or an open-weight model on internal hardware. The in-house team owns the architecture, the integration, and the ongoing operation. Both options target the same use case—lead qualification for a 201-500 employee fintech in the UK—but they differ in who bears the delivery risk, how fast the first working system ships, and what the company must maintain after the pilot.

    Criteria for the Comparison

    The comparison is judged against seven criteria that matter to a fintech scaling operations without new hires:

    • Time to first working system — how many weeks from kickoff to a live agent handling real leads.
    • Total cost of ownership over 6 months — including model API costs, integration work, and ongoing operation.
    • PCI DSS scope impact — whether the agent’s data boundary touches cardholder data and what that means for compliance.
    • Error rate reduction — the measured delta in misclassified leads between the manual baseline and the agent.
    • Cycle time reduction — the measured delta in time from lead creation to qualified status.
    • Vendor lock-in — how easily the company can switch model providers or take the system in-house after the pilot.
    • Operational burden — who monitors, tunes, and maintains the agent after the pilot ends.

    Comparison Table

    Criterion Option A: Fixed-Scope Pilot (External Studio) Option B: In-House Build
    Time to first working system 6-8 weeks from kickoff; studio has delivery templates and prior fintech experience 12-16 weeks minimum; team must design architecture, build integration, and tune the model from scratch
    Total cost over 6 months Fixed pilot fee (typically £25,000-£40,000) plus Anthropic API usage (approx. £1,500-£3,000/month at 500-1,000 leads/month); no new hires 2-3 FTEs at £60,000-£80,000/year each plus API costs; total £150,000-£250,000 over 6 months including salaries
    PCI DSS scope impact Studio designs data boundary to exclude cardholder data; client retains compliance ownership Same design principle, but in-house team must validate the boundary against PCI DSS 4.0 requirements; no external review
    Error rate reduction Measured in pilot; studio ships with baseline and delta report; typical delta: 30-50% reduction in misclassification Measured after build; no external baseline; team must design the measurement framework themselves
    Cycle time reduction Measured in pilot; typical delta: 40-60% reduction in time-to-qualified Measured after build; no external baseline; team must design the measurement framework themselves
    Vendor lock-in Low: model-agnostic architecture; client can switch to OpenAI or an open-weight model post-pilot Low: in-house team controls the stack; no external dependency
    Operational burden Studio provides handover documentation and a 30-day post-pilot support window; client takes over operation In-house team owns all operation, monitoring, and tuning from day one

    Scenario-by-Scenario Verdict

    When Option A wins: The company has no dedicated AI engineering team and needs a working lead qualification agent within 6-8 weeks to hit a quarterly sales target. The fixed-scope pilot removes delivery risk: the studio has delivered similar systems for fintech and payments clients in Tier-1 markets, and the pilot’s measured baseline gives the sales team a concrete number to report to leadership. The 6-month timeline is tight for an in-house build, and the pilot’s fixed fee is a smaller commitment than hiring 2-3 engineers. For a 201-500 employee company where every new hire is a significant cost, the pilot’s cost profile is easier to justify.

    When Option B wins: The company already has a strong engineering team with experience in API integrations and LLM applications, and the lead qualification workflow is one of several AI initiatives the team is building. The in-house build gives the team full control over the architecture, which matters if the company plans to extend the agent to other workflows (invoice processing, document extraction) over the next 12-18 months. The in-house team can also choose to run an open-weight model on internal hardware if the data residency requirements tighten, without renegotiating a vendor contract.

    Recommendation

    For a 201-500 employee UK fintech with a 6-month timeline and no dedicated AI engineering team, Option A—the fixed-scope pilot on the Anthropic Claude API—is the better fit. The pilot’s 6-8 week delivery window fits the 6-month timeline with room for a rollout phase after the pilot. The fixed fee is a smaller financial commitment than hiring 2-3 engineers, and the studio’s prior experience with fintech and payments clients in Tier-1 markets reduces the risk of a failed pilot. The measured baseline on cycle time and error rate gives the sales team a concrete business case for scaling. The model-agnostic architecture means the company is not locked into Anthropic; if the data residency requirements change, the team can switch to an open-weight model on internal hardware without rebuilding the integration. The in-house build is the right choice only if the company already has the engineering capacity and the lead qualification agent is part of a broader AI roadmap that justifies the longer build time and higher cost.

  • UK E-Commerce Retailer Cuts Monthly Reporting from 14 Days to 36 Hours

    Background: A 1,200-Person UK E-Commerce Retailer

    This case study is a composite drawn from patterns Forfis has observed across multiple e-commerce and retail engagements in the UK. No named customer appears. The company described here is a mid-market online retailer with roughly 1,200 employees, operating across three fulfilment centres in the Midlands and the North of England. It sells through its own website and two major marketplaces, processes around 40,000 supplier invoices per month, and runs a monthly operations report that feeds into board-level KPIs. The existing stack includes a mid-tier ERP, a legacy document management system, and Microsoft Teams as the primary internal communication channel. The finance and operations teams are separate, and the monthly report is a hand-built spreadsheet assembled from exports in three different formats.

    The Challenge: 14 Days of Manual Reporting

    The monthly operations report took the finance team 14 working days to assemble. The process started with exporting supplier invoices from the document management system, manually keying line items into a spreadsheet, reconciling them against the ERP purchase orders, and then formatting the output for the board pack. Two analysts spent roughly 60 hours per cycle on this task, and the error rate on manual data entry sat around 4 to 6 percent, meaning roughly 1,600 to 2,400 line items per month required correction before the report could be signed off. The operations team, meanwhile, had no real-time visibility into supplier performance because the data was locked in the spreadsheet until the report was published. The pressure was not regulatory; it was operational. The CFO had flagged the reporting lag in a board review, and the head of operations wanted supplier scorecards available within 48 hours of month-end close, not 14 days later.

    Approach: Audit, Pilot, and n8n Orchestration

    Forfis began with a two-week AI automation audit. The audit mapped the invoice-to-reporting flow end to end, identified 11 distinct manual touchpoints, and scored each on volume, error rate, and cycle time. The top candidate was the invoice extraction and reconciliation step, which accounted for 70 percent of the analyst hours. The pilot scope was fixed at eight weeks: build a document and data extraction pipeline that ingests supplier invoices from the document management system, extracts line items, PO references, and tax codes, and pushes structured data into the ERP via its REST API. On top of that, a retrieval-augmented knowledge assistant was built over the company’s operations documentation, historical reports, and CRM records, accessible through Microsoft Teams. The orchestration layer was n8n, self-hosted on the client’s own infrastructure, so no data transited a third-party SaaS boundary. The model layer used OpenAI’s API for extraction quality and an open-weight model for the RAG assistant, running on the client’s GPU server, because the operations documentation contained supplier contract terms that procurement wanted to keep on-premises.

    Outcome: 36 Hours, Not 14 Days

    The pilot shipped in seven and a half weeks, one day ahead of the eight-week deadline. The extraction pipeline processed 40,000 invoices per month with a field-level accuracy of 96.2 percent on the test set, up from the 94 to 96 percent baseline of manual entry. The monthly report cycle dropped from 14 working days to 36 hours: the pipeline ran overnight, the RAG assistant generated a draft narrative summary by 09:00 the next morning, and a finance analyst reviewed and approved the output by 12:00. The error rate on the final report fell to under 1 percent. The operations team gained access to supplier scorecards within 48 hours of month-end close, a 12-day improvement. The two analysts who previously spent 60 hours per cycle on this task were redeployed to supplier negotiation support. The n8n workflow was handed over with documentation, and the client’s own operations team could adjust routing rules without a developer. The RAG assistant was scoped to the indexed corpus only; it did not have internet access, and access was controlled at the Teams channel level.

    Lessons for Similar Teams

    • Fix the pilot scope before writing code. The eight-week timeline held because the audit deliverable defined exactly which invoices, which fields, and which ERP endpoints were in scope. Any new request during the pilot was treated as a change order with its own timeline, not a silent addition. Teams that skip this step routinely blow past their deadline by two to three weeks.
    • Self-host the orchestration layer when procurement asks where data lives. n8n on the client’s own infrastructure answered that question in one sentence. A managed SaaS orchestrator would have required a data processing agreement and a security review that added three to four weeks to the timeline.
    • Partition the RAG index by department. The operations assistant could not query finance data, and vice versa. This was enforced at the vector store level, not just at the Teams channel level. Without partitioning, a user in logistics could have pulled supplier contract terms from the finance index.
    • Log every human approval with a timestamp and user ID. Even though no regulation mandated it, the audit trail became the first thing the CFO asked for in the post-pilot review. The log showed exactly who approved the report, when, and what the model had drafted before approval.
    • Model-agnostic from day one. The client swapped the RAG model from OpenAI to the open-weight model in week three when procurement raised a data-residency concern. The n8n workflow did not change; only the model endpoint did. That swap cost two hours of configuration, not a re-architecture.

  • UK E-commerce Voice Agent for Ticket Triage: 3-Month GDPR-Compliant Pilot

    Process Audit and Baseline Measurement

    A 500-person e-commerce company in the UK handles 12,000 support tickets monthly, with 40% involving order status checks or returns. The support team spends 6 hours per day on manual data entry and routing, with an average cycle time of 4.2 hours from ticket creation to first response. The goal is to reduce manual back-office work by 30% and cut cycle time to under 2 hours, while maintaining GDPR compliance and supporting English plus two additional languages. The engagement starts with a two-week process audit that analyzes call recordings, ticket logs, and CRM data to identify the top five query types and the current error rate. The audit produces a baseline document with cycle time, error rate, and customer satisfaction scores for each query type, which becomes the success criteria for the pilot. The team selects one product category and one language for the isolated pilot, ensuring the scope is fixed and measurable. The pilot runs for four weeks, with a human-in-the-loop approval for any action that touches money or account changes. The architecture uses the Anthropic Claude API for response generation, with a custom REST API and webhooks connecting the voice agent to the existing CRM and helpdesk. No data is stored in the AI layer; all records remain in the client’s systems. The pilot ships with a measured before/after baseline, and the team reviews the results in a structured debrief before deciding on rollout.

    Voice Agent Architecture and Model Selection

    The voice agent uses a three-stage pipeline: speech-to-text, language model inference, and text-to-speech. The speech-to-text engine captures the caller’s voice and converts it to text with a 92% accuracy rate in English. The Anthropic Claude API generates the response using a prompt template that includes the caller’s intent, order details, and the company’s returns policy. The prompt is tuned for each language, with a glossary of product terms and a confidence threshold that routes low-confidence calls to human agents. The text-to-speech engine converts the response to natural-sounding audio with a 180 ms latency, which is within the acceptable range for conversational AI. The system supports English, German, and French, with a fallback to English if the confidence score drops below 85%. The voice agent does not make decisions with legal or similar significant effects; it provides information and captures data, with a human agent handling any action that touches money or account changes. The architecture is model-agnostic, so the team can switch to an open-weight model on client hardware if the data sensitivity requires it. The integration layer uses custom REST APIs and webhooks to connect the voice agent to the CRM and helpdesk, with no vendor lock-in on the AI model or integration layer.

    Integration Sprint and API Design

    The integration sprint delivers a working voice agent connected to the client’s CRM and helpdesk via REST APIs and webhooks. The deliverable includes the model configuration, prompt templates, API endpoints, and a runbook for the support team. The client retains full ownership of the code and configuration, with no vendor lock-in on the AI model or integration layer. The integration layer is designed to be modular, so the team can add new languages or product categories without re-architecting the system. The API endpoints are documented with OpenAPI 3.0, and the webhooks are signed with HMAC-SHA256 to ensure data integrity. The system logs all interactions with a timestamp, caller ID, and intent classification, which the support team can query via the CRM’s reporting dashboard. The runbook includes troubleshooting steps for common issues, such as high latency or low confidence scores, and a contact list for the integration team. The client’s IT team is trained on the system during the final week of the sprint, with a handover document that covers the architecture, configuration, and maintenance procedures. The integration sprint is fixed-scope, with a defined deliverable and a 48-hour rollback window if the pilot fails to meet the success criteria.

    Isolated Pilot and Rollback Strategy

    The pilot runs in isolation on a single product category and one language, with a measured baseline of cycle time and error rate before go-live. The system does not touch production data or affect other support channels. If the pilot fails to meet the predefined success criteria, the team rolls back to the manual process within 48 hours, with no data loss or system disruption. The success criteria include a 30% reduction in manual data entry, a cycle time under 2 hours, and an error rate below 5%. The team reviews the results in a structured debrief, with a focus on the error types and the customer satisfaction scores. The debrief produces a report that includes the before/after metrics, the error analysis, and a recommendation for rollout. The rollout plan includes a phased approach, with the voice agent expanding to additional languages and product lines over the next eight weeks. The team monitors the error rate and customer satisfaction scores during the rollout, with a 24-hour review window where a support lead audits a sample of AI-handled calls for accuracy. The rollout is considered successful if the error rate remains below 5% and the customer satisfaction score does not drop by more than 2 points.

    GDPR Compliance and Data Handling

    The system complies with GDPR Article 5 (data minimization) and Article 22 (automated decision-making). Voice recordings and transcripts are encrypted in transit and at rest, with a lawful basis for processing. The data is stored in the client’s CRM and helpdesk, not in the AI layer, which reduces the data footprint and simplifies the compliance review. The team documents the logic of the AI system in a Data Protection Impact Assessment, which is required if the system makes decisions with legal or similar significant effects. The voice agent does not make such decisions; it provides information and captures data, with a human agent handling any action that touches money or account changes. The system offers a human review option for any caller who requests it, and the team maintains a log of all human reviews. The data retention policy is aligned with the client’s existing GDPR compliance program, with a maximum retention period of 12 months for voice recordings and 24 months for transcripts. The team conducts a quarterly review of the data processing activities, with a focus on the error rate and the customer satisfaction scores. The compliance review is documented in a report that is shared with the client’s data protection officer.

    Risk Mitigation and Error Handling

    The main risk is the voice agent providing incorrect information about order status or returns policy. Mitigation includes a human-in-the-loop approval for any action that touches money or account changes, a confidence threshold that routes low-confidence calls to humans, and a 24-hour review window where a support lead audits a sample of AI-handled calls for accuracy. The team monitors the error rate and the customer satisfaction scores during the pilot and rollout, with a focus on the error types and the root causes. The error analysis is documented in a report that is shared with the support team, with a focus on the corrective actions and the preventive measures. The team conducts a monthly review of the system’s performance, with a focus on the cycle time, the error rate, and the customer satisfaction scores. The review produces a report that includes the metrics, the error analysis, and a recommendation for improvement. The team maintains a knowledge base of common issues and their solutions, which is updated monthly based on the error analysis. The knowledge base is used to train the support team and to improve the prompt templates for the voice agent.

  • How a 15-Person UK Medtech Firm Cut Back-Office Errors 40% in Two Weeks

    1. The pilot scope is one workflow, not a platform

    A 15-person medtech company in Manchester was losing 11 hours per week to manual invoice data entry and document extraction. The finance lead typed supplier invoices into the ERP, cross-checked line items against purchase orders, and flagged discrepancies in a shared spreadsheet. Error rate: 6.2% on a sample of 200 invoices. Cycle time: 4.3 hours per batch.

    The fix was not a new hire. It was a fixed-scope pilot with a two-week deadline: automate the extraction and validation step for one supplier, integrate it into the existing ERP via API, and measure the before/after delta. The pilot used the Anthropic Claude API for document parsing because the invoice formats were inconsistent and required nuanced field mapping. A human approved every extracted record before it hit the ERP. The result: error rate dropped to 1.8%, cycle time fell to 1.1 hours per batch, and the finance lead spent the freed time on supplier negotiations instead of data entry.

    2. The integration lives in Slack, not a new dashboard

    The pilot ran inside the team’s existing Slack workspace. A bot posted extracted invoice fields into a dedicated channel, tagged the finance lead for approval, and logged the decision. No new UI, no new login, no training session. The integration used the Slack API and the ERP’s REST endpoint — both already in production.

    This matters because a 15-person team does not have the bandwidth to adopt a new tool. The workflow orchestration layer sat between the Claude API and the ERP: it handled retries, format validation, and the approval gate. When the finance lead approved a record in Slack, the orchestration layer pushed it to the ERP. When they rejected it, the bot asked for the correction and re-processed. Every interaction was logged for the GDPR audit trail. The team never left Slack. The AI never replaced the ERP. It filled the gap between the two.

    3. GDPR compliance is a design constraint, not an afterthought

    The pilot processed supplier invoices, which contain no patient data. But the company’s broader documentation — SOPs, regulatory checklists, clinical trial protocols — does. The architecture was designed from day one to be model-agnostic: the orchestration layer could route a request to the Anthropic Claude API for general document work, or to an open-weight model running on the company’s own server for anything touching special-category data under GDPR Article 9.

    The DPIA was completed before the pilot started. It documented: what data the AI processes, where it is stored, who can access it, and how a human can override any automated decision. The Data Processing Agreement with Anthropic was signed. The open-weight model (a 7B-parameter Llama variant) ran on a single GPU workstation in the office. No patient data left the building. The pilot’s scope was narrow enough that the compliance overhead was a one-day task, not a multi-week project.

    4. The baseline is measured, not assumed

    The pilot’s success metric was not “the AI works.” It was: error rate drops from 6.2% to under 3%, and cycle time drops from 4.3 hours to under 2 hours per batch. The baseline was measured in week one, before any automation was live. The team processed 50 invoices manually and logged every error and every minute. In week two, the AI processed the same 50 invoices, and the finance lead approved or corrected each one. The delta was the deliverable.

    This is what separates a pilot from a demo. A demo shows the AI extracting fields from a sample PDF. A pilot measures whether the extraction is accurate enough to trust in production, and whether the human approval step is fast enough to be worth the overhead. The 4.3-hour to 1.1-hour drop was not theoretical. It was logged in the ERP’s audit trail, timestamped, and attributable to the automation.

    5. The rollout is a sequence of fixed-scope engagements

    The pilot’s scope was one supplier, one document type, one integration point. The rollout plan was explicit: week three adds the second supplier, week four adds the third, week five adds the document extraction for purchase orders. Each expansion was a separate fixed-scope engagement with its own baseline and success metric.

    This is how a 15-person company scales operations without new hires. The finance lead’s role did not change — she still approved every record. But the time she spent typing dropped from 4.3 hours to 1.1 hours per batch. The freed capacity went to supplier management, which had been neglected for two years. The company did not hire a data entry clerk. It did not buy a new ERP. It added an AI layer to the workflow it already ran, measured the delta, and expanded only when the numbers justified it.

    6. The knowledge search is a byproduct, not the goal

    The pilot’s real value was not the 40% error reduction. It was the internal knowledge search capability that emerged from the same architecture. The orchestration layer that routed invoice data to the ERP was repurposed to route queries to the company’s document store. A support agent in Slack could now ask, “What is the recall procedure for device X?” and get a cited answer from the SOP, with the relevant section highlighted. The agent still reviewed the answer before sending it to a customer. The AI did not replace the agent. It cut the search time from 12 minutes to 90 seconds.

    The synthesis: a 15-person UK medtech company did not need a new hire, a new ERP, or a new helpdesk. It needed a two-week fixed-scope pilot that measured a real delta, ran inside the tools the team already used, and kept a human in the loop for every high-stakes action. The AI was a layer, not a replacement. The compliance was a constraint, not a blocker. The rollout was a sequence, not a big bang. That is the pattern that works when the team is small, the data is regulated, and the timeline is two weeks.