Forfis Blog

Tag: UK

  • AI Invoice Processing for UK Professional Services: A 3-Month LangGraph Roadmap

    The Back-Office Bottleneck in UK Professional Services

    A 51-200 person professional services firm in the UK processes 800-1,500 invoices monthly. Each invoice requires manual data entry into the ERP, cross-referencing against purchase orders, and validation against vendor terms stored in Confluence or Notion. The baseline cycle time is 12-18 minutes per invoice, with a 3-5% error rate that triggers rework and payment delays. The operations team spends 40-60 hours weekly on this task, and the cost of errors (late payment penalties, vendor disputes) compounds over time.

    The problem is not a lack of tools. The firm already has an ERP, a helpdesk, and a knowledge base. The gap is in the workflow: data moves between systems through human hands, and each handoff introduces latency and error. AI workflow automation addresses this by replacing the manual extraction and validation steps with a model that reads the invoice, extracts fields, scores confidence, and routes exceptions to a human approver. The architecture plugs into existing systems via APIs rather than replacing them, preserving the firm’s current operational stack while automating the repetitive back-office work.

    LangGraph Stateful Workflow for Invoice Processing

    The system operates as a stateful graph defined in LangGraph. Each node represents a step: document ingestion, field extraction, validation, predictive scoring, and routing. The state object carries the invoice metadata, extracted fields, confidence scores, and approval status through the graph.

    [Ingest] → [Extract] → [Validate] → [Score] → [Route]
   ↑           ↑           ↑           ↑           ↓
   └───────────┴───────────┴───────────┴─────[Human Approve]

    The extraction node uses a vision-language model (GPT-4o or Claude 3.5 Sonnet) to parse the invoice PDF and output structured JSON. The validation node checks fields against the vendor master in the ERP and terms in Confluence/Notion via their APIs. The scoring node applies a predictive model that estimates the probability of payment delay or dispute based on historical data. If the confidence score falls below a threshold (typically 0.85), the graph routes to a human approval node where a person reviews the invoice and approves or rejects it. The approval action updates the state and triggers the next node, which posts the invoice to the ERP.

    The RAG layer indexes Confluence and Notion documents using semantic chunking (512-1024 tokens, 10-15% overlap) and stores embeddings in a vector store. At query time, the system retrieves relevant chunks on vendor terms, payment policies, and historical exceptions, augmenting the prompt to improve extraction accuracy.

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

    The architect faces three key trade-offs. First, model choice: cloud APIs (OpenAI, Anthropic) offer higher quality but require data to leave the building, which conflicts with GDPR Article 22 if the data includes personal information. Open-weight models (Llama 3 70B, Mistral 7B) deployed on-premises via vLLM or TGI keep data local but require GPU infrastructure and yield slightly lower extraction accuracy. Forfis resolves this with a hybrid routing: invoices containing personal data go to the on-premises model; generic vendor data uses the cloud API.

    Second, human-in-the-loop granularity: a fully automated pipeline is faster but riskier. A fully manual approval is safe but defeats the purpose of automation. The compromise is confidence-based routing: only invoices below the threshold require human review. The threshold is tuned during the pilot to balance cycle time and error rate. A threshold of 0.85 typically routes 15-25% of invoices to humans, reducing manual work by 75-85% while keeping the error rate below 1%.

    Third, integration depth: shallow integration (API calls to ERP and helpdesk) is faster to deploy but misses opportunities for end-to-end automation. Deep integration (webhooks, event-driven updates) is more complex but enables real-time status tracking and audit trails. For a 3-month timeline, shallow integration is the pragmatic choice; deep integration can be added in a subsequent phase.

    3-Month Roadmap: Audit, Pilot, and Managed Operation

    For a 51-200 person UK professional services firm, the 3-month timeline breaks down as follows. Weeks 1-4: process audit and baseline measurement. The team maps the current invoice workflow, identifies the highest-volume and highest-error workflows, and measures cycle time and error rate. This baseline is critical for the before/after comparison that justifies the investment. Weeks 5-8: fixed-scope pilot on one workflow. The LangGraph workflow is deployed in a staging environment, and the team runs it on a sample of 100-200 invoices. The human-in-the-loop approval is tested, and the confidence threshold is tuned. Weeks 9-12: rollout and handover. The workflow is deployed to production, the dedicated AI team takes over managed operation, and the firm’s operations team is trained on the exception-handling dashboard.

    The dedicated AI team monitors key metrics: cycle time per invoice, error rate, human intervention rate, and model confidence distribution. If the error rate exceeds the baseline threshold, the team investigates whether the issue is in the extraction model, the validation rules, or the data quality. They also manage the RAG pipeline, re-indexing Confluence/Notion documents when content changes and monitoring retrieval accuracy. The service level agreement specifies 4-hour response times for production outages and weekly dashboards with monthly business reviews.

  • Cutting First-Response Time in UK Professional Services with On-Premise AI

    The Back-Office Bottleneck in Professional Services

    The problem is not a lack of effort. It is a structural mismatch between the volume of unstructured documents your team handles and the number of people you can hire. In a 51-200 person professional services firm, HR and recruiting teams spend 30-40% of their week on manual document processing: parsing CVs, extracting data from onboarding forms, and answering the same internal policy questions over and over. The result is a first-response time of 4-6 hours for internal queries, a 12-18 day cycle for onboarding, and a 15-20% error rate on data entry. You are not underperforming. You are under-resourced in a way that hiring cannot fix without destroying your margin.

    Why Off-the-Shelf RPA and SaaS Tools Fall Short

    Most firms try to solve this with more headcount or generic RPA tools. Both fail. Hiring adds cost and does not scale with demand. RPA tools like UiPath or Automation Anywhere work well for structured, rule-based tasks, but they break down on unstructured documents like CVs, contracts, and policy manuals. They require brittle rules that need constant maintenance. The other common approach is to buy a SaaS document processing tool. These work, but they send your data to a third-party cloud, which is a non-starter for professional services firms handling client data. You need a solution that stays on your infrastructure and handles the messiness of real-world documents.

    A Model-Agnostic Approach That Stays On-Premise

    The better path is a model-agnostic AI layer that plugs into your existing systems. For a firm with no AI in production yet, the starting point is a process audit that identifies the workflows worth automating. The audit measures the baseline: cycle time, error rate, and volume. Then a fixed-scope pilot builds an extraction pipeline for one workflow, using open-weight models like Llama 3 or Mistral deployed on your own hardware. This ensures no data leaves your building. The AI layer integrates with Slack or Microsoft Teams, so your team gets answers and processed documents where they already work. The pilot ships with a before/after report, so you know exactly what you gained.

    How to Start: The 8-Week Pilot Path

    Start with the process audit. Identify the three to five workflows where manual work is most painful. Measure the baseline: how long does each task take, and what is the error rate? Next, define the scope of the pilot: which workflow, which document types, which integration point. Lock the scope. Then build the extraction pipeline and knowledge search index. Integrate with Slack or Microsoft Teams. Test with your team. Refine. Report. The 8-week timeline is tight, but it is enough to prove value and give you the data to decide whether to scale. The key is to start with the highest-volume, lowest-risk workflow, not the most complex one.

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

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

  • n8n AI Ticket Triage for a UK Insurer: A 3-Month ISO 27001-Compliant Pilot

    The Problem: Manual Triage in a 200-Person UK Insurer

    You run a 200-person UK insurer. Your operations team handles 4,000 to 6,000 support tickets per month across claims, policyholder queries, and vendor communications. Each ticket is manually triaged by a first-line agent who reads the subject line, skims the body, and assigns it to a queue. The average handling time is 11 to 14 minutes per ticket, and misrouting rates sit at 8 to 12 percent, meaning nearly one in ten tickets lands in the wrong queue and gets re-routed, adding 3 to 5 minutes of dead time. Your ISO 27001 certification requires that any new system touching customer data passes a documented risk assessment under clause 8.2, and your board has set a 3-month deadline to show measurable cost reduction per ticket. The problem is not that you lack an AI tool; it is that you have no structured path from a single isolated pilot to a managed, auditable production system that fits inside your existing helpdesk, CRM, and ERP stack without replacing them.

    Prerequisites Before You Touch n8n

    Before you write a single n8n node, confirm these conditions are met:

    • Helpdesk API access: Your helpdesk (Zendesk, Freshdesk, Jira Service Management, or equivalent) exposes a REST API with webhook support for new-ticket and ticket-update events. You need at least read and update permissions on ticket objects.
    • ISO 27001 risk assessment initiated: Your information security officer has opened a risk register entry for the AI triage layer. You must document the data flows, the model provider’s DPA, and the access control model before the pilot goes live.
    • Baseline metrics captured: For the 4 weeks before the pilot, log the average cycle time (ticket creation to first human action), misrouting rate, and cost per resolved ticket for at least one ticket category. This is your before/after baseline.
    • n8n instance provisioned: A self-hosted n8n instance on your own infrastructure (not n8n Cloud) to satisfy data residency requirements. The instance must be behind your existing authentication and logging infrastructure.
    • Model API keys scoped: API keys for OpenAI or Anthropic (or an open-weight model endpoint) restricted to the specific endpoints and token limits the pilot requires. Keys must be stored in your secrets manager, not in n8n environment variables visible to all team members.
    • Stakeholder sign-off: The operations director, the CISO, and the head of customer service have agreed on the pilot scope: one ticket category, one routing destination, 6 to 8 weeks, no scope expansion.

    Step 1: Audit the Triage Process and Capture Baseline Metrics

    Run a 2-week process audit on the single ticket category you will automate. Export 200 to 300 historical tickets from your helpdesk for the target category. Tag each ticket with: original queue assignment, final queue assignment (after any re-routing), handling time, and whether it was escalated. Calculate the misrouting rate and average cycle time. This gives you the baseline numbers you will compare against after the pilot. Document the triage decision rules your agents currently use: which keywords trigger which queue, which customer segments get priority, and what happens when a ticket is ambiguous. These rules become the prompt structure for the LLM classification node. Without this audit, you are automating a process you do not fully understand, and the pilot will produce data you cannot interpret.

    Step 2: Provision n8n on Your Own Infrastructure

    Provision a self-hosted n8n instance on a VM or container within your existing network boundary. Use the n8n Docker image (n8nio/n8n:latest) with the following configuration: set N8N_ENCRYPTION_KEY from your secrets manager, enable N8N_DIAGNOSTICS_ENABLED=false to prevent telemetry, and configure the webhook listener to accept events only from your helpdesk’s IP range. Create a dedicated n8n user account with read-only access to the workflow for auditors and full access for the two engineers who will build the pilot. Version-control the workflow JSON in your Git repository under a pilot/ directory. This step takes 2 to 3 days including security review by your CISO’s team.

    Step 3: Build the Triage Workflow in n8n

    Build the n8n workflow with the following node sequence: (1) a Webhook node that receives the ticket.created event from your helpdesk; (2) an HTTP Request node that calls the LLM API (OpenAI gpt-4o or Anthropic claude-sonnet-4-20250514) with a structured prompt containing the ticket subject, body, customer segment, and the triage decision rules from Step 1; (3) a Code node that parses the JSON response and extracts the predicted queue, confidence score, and escalation risk; (4) an IF node that checks whether the confidence score is above 0.80; (5) an HTTP Request node that calls the helpdesk API to reassign the ticket to the predicted queue; (6) a Webhook node that logs the full request/response pair to your SIEM. If the confidence score is below 0.80, the workflow routes the ticket to a human review queue instead of auto-routing. This is your human-in-the-loop gate.

    Step 4: Configure the LLM Prompt and Predictive Scoring

    The LLM prompt must be deterministic and auditable. Structure it as follows: a system message defining the role (“You are a ticket triage classifier for a UK insurer”), the triage rules as a numbered list, the output format as strict JSON with fields predicted_queue, confidence (float 0 to 1), escalation_risk (float 0 to 1), and reasoning (one sentence). Include 3 to 5 few-shot examples from your historical data. Set the temperature to 0.1 to minimize variance. Log every prompt and response to your SIEM with a correlation ID matching the ticket ID. This logging is not optional under ISO 27001 clause 8.15 (logging and monitoring); your CISO will require it for the risk assessment. The prompt file should live in your Git repository, versioned, so that any change to the classification logic is traceable.

    Step 5: Run the 6-to-8-Week Pilot in Parallel Mode

    Run the pilot for 6 to 8 weeks on the single ticket category. During this period, the n8n workflow runs in parallel with the existing manual triage: the AI classifies and scores every ticket, but a human agent still makes the final routing decision. Compare the AI’s predicted queue against the human’s actual assignment. Track three metrics weekly: (1) agreement rate (percentage of tickets where AI and human agree on queue), (2) cycle time (ticket creation to first human action, measured in minutes), and (3) misrouting rate (tickets that required re-routing after initial assignment). At week 4, review the data with the operations director. If the agreement rate is above 85% and cycle time has dropped by at least 20%, you have a defensible case to switch from parallel mode to auto-routing mode for high-confidence tickets (score above 0.85). If the agreement rate is below 75%, do not proceed; go back to Step 1 and refine the triage rules.

  • Cutting First-Response Time by 55%: AI Ticket Triage for a 30-Person UK Insurer

    The Problem: 18-Minute First Responses and a 30-Person Team

    A 30-person UK insurer handling 200 support tickets a day faces a familiar problem: first-response time sits at 18 minutes on average, and the cost per ticket is climbing as agent turnover rises. The tickets are not complex — most are policy status checks, document requests, or routine claim updates — but they consume the same agent time as a disputed claim. The insurer has already automated one process: invoice processing. The next target is the support queue, where the volume is highest and the margin for error is lowest.

    The constraint is not technical. The insurer runs a standard helpdesk, a CRM, and a Confluence workspace with 400 pages of policy documentation. The constraint is compliance: UK GDPR, specifically Article 22, requires that no decision with legal or similarly significant effect be made solely by automated processing. A ticket that triggers a claim denial, a premium adjustment, or a policy cancellation cannot be resolved by an AI without human review. The architecture must reflect that boundary from day one.

    The engagement is scoped as a 3-month integration sprint: a two-week process audit, a six-week pilot on ticket triage and routing, and a four-week rollout with measured before/after baselines. The AI layer sits on top of the existing helpdesk and CRM, not in place of them. It reads tickets, classifies them, retrieves context from Confluence, drafts a response, and routes the ticket to the right queue. A human approves anything that touches money, health data, or a contract. The model is Anthropic Claude, called via API, because the insurer’s data can leave the building under a standard data processing agreement, and the quality of the drafting and classification is the priority.

    How the Pipeline Works: From Webhook to Human Review

    The pipeline has five stages, each mapped to a specific API call or internal function:

    1. Ingestion. The helpdesk webhook fires on every new ticket. The payload includes the ticket ID, subject, body, policy number, and customer ID. The system parses this and normalizes the fields.

    2. Classification. The ticket body and subject are sent to the Anthropic Claude API with a system prompt that defines the taxonomy: claim, policy change, document request, billing, other. The model returns a JSON object with the category, a confidence score, and a suggested urgency level. The taxonomy is fixed; the model does not invent categories.

    3. Retrieval. The policy number and issue type are used to query the Confluence workspace via its REST API. The relevant pages are pulled, chunked, and embedded. A vector search returns the top three passages. This step runs in under 400 ms.

    4. Drafting. The ticket body, the classification, and the retrieved passages are sent to Claude with a second prompt that instructs it to draft a first response in the insurer’s tone. The draft includes a reference to the specific policy clause or FAQ article that supports the answer.

    5. Routing and Review. The ticket is routed to the correct queue based on the classification. If the category is claim, billing, or policy change, the ticket is flagged for human review. The human sees the AI’s draft, the classification, the retrieved context, and a one-click approve/edit/reject interface. The audit log records the ticket ID, the model version, the prompt hash, the human’s action, and the timestamp.

    The whole pipeline, from webhook to human review screen, takes under 3 seconds. The human review step adds 2-5 minutes for routine tickets and 10-15 minutes for flagged ones.

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

    Three architectural choices drive the cost and compliance profile of this system.

    Model choice. Anthropic Claude is used for the classification and drafting steps because the quality of the natural-language output matters. The insurer’s data is not regulated to the point where it cannot leave the building under a standard DPA. If the data had been health records or financial data subject to FCA rules, the architecture would have shifted to an open-weight model on the insurer’s own hardware, which would have added 4-6 weeks to the timeline for GPU provisioning and model fine-tuning.

    Human-in-the-loop boundary. The AI drafts and classifies; a human approves anything that touches money, health data, or a contract. This is not a soft guideline. The system is built so that the approve button is the only path to sending a response for flagged tickets. The audit log is immutable and exportable for ICO inspection. This design satisfies GDPR Article 22 and gives the insurer a defensible position if a customer challenges a decision.

    Integration depth. The AI plugs into the existing helpdesk, CRM, and Confluence via their APIs. It does not replace any of them. The insurer keeps its current tooling, its current data model, and its current access controls. The AI is a layer, not a platform. This keeps the integration sprint to 3 months instead of the 9-12 months a full platform replacement would require. The trade-off is that the AI is limited by the quality of the data in the existing systems. If the Confluence documentation is stale or inconsistent, the retrieval step degrades, and the drafting step produces lower-quality responses.

    Recommendation: What to Do in the First 30 Days After the Pilot

    The pilot measured three metrics over two weeks before and two weeks after the AI went live: first-response time, error rate, and cost per ticket. The baseline was 18 minutes for first-response time, a 7% misclassification rate, and a cost per ticket of £4.20. After the pilot, first-response time dropped to 8 minutes, the misclassification rate fell to 3%, and the cost per ticket dropped to £2.90. The 55% reduction in first-response time came from the AI handling the first 70% of tickets end-to-end, with the human only reviewing the draft. The 40% reduction in cost per ticket came from reduced agent time on routine tickets.

    The rollout plan is straightforward. The AI is enabled for all new tickets in the support queue. The human review step remains for flagged tickets. The audit log is reviewed weekly by the compliance team. The Confluence documentation is updated quarterly to keep the retrieval step accurate. The model is re-evaluated every six months against a test set of 500 historical tickets to catch drift.

    The key lesson is that the AI does not replace the agent. It changes the agent’s job from drafting every response to reviewing and approving AI-drafted responses. The agent’s skill set shifts from writing to judgment. The insurer should plan for retraining, not for headcount reduction. The 3-month sprint is a starting point, not a finish line. The next phase is to extend the same architecture to the claims queue, where the volume is lower but the complexity is higher, and the human-in-the-loop boundary is more critical.

  • 4-Week AI Automation Audit for a 2,000+ Employee UK Healthcare Firm

    1. The audit measures what you actually do, not what you think you do

    The audit starts by pulling 90 days of ticket, invoice, and contract logs from Google Workspace, the CRM, and the ERP. The team interviews the finance team, the clinical operations lead, and the IT security officer to map every data flow that touches the AI layer. Each workflow is scored on three axes: volume (how many instances per week), complexity (how many manual steps and exceptions), and sensitivity (does it touch patient data, money, or a contract?). The output is a ranked list of automation candidates with a measured baseline on cycle time and error rate for each. For a 2,000+ employee UK healthcare firm, the top three candidates are almost always invoice processing, contract review, and patient-facing query triage. The audit does not recommend a model or a vendor; it recommends a workflow and a success metric. That distinction matters because the model choice is a technical decision that can be made after the business case is approved.

    2. The pilot is one workflow, one team, one measurable outcome

    The pilot runs for 4-6 weeks on a single workflow, with a fixed scope defined in the audit. For a healthcare and finance firm, the most common pilot is a conversational agent that monitors a shared Google Workspace inbox, classifies incoming queries, retrieves relevant documentation from a pgvector store, and drafts a first response. The human-in-the-loop step is a simple approve/edit/reject action in the Gmail UI. The agent does not send anything to a patient or a supplier without a human clicking approve. The success criterion is a statistically significant reduction in median first-response time and a measurable drop in error rate, both measured against the baseline captured in the audit. For a 2,000+ employee firm, the pilot team is typically three to four people: one engineer, one product manager, one domain expert from the target department, and one security officer who signs off on the ISO 27001 control mapping. The pilot ships with a written report that includes the before/after metrics, the error log, and the list of edge cases the agent could not handle.

    3. The model-agnostic stack keeps regulated data on-premises

    The architecture routes queries to the appropriate model based on a sensitivity tag assigned during the audit. Patient-identifiable data, financial records, and contract terms are tagged as regulated and routed to open-weight models (Llama 3, Mistral) running on the client’s own GPU hardware. The pgvector store lives on the same on-prem PostgreSQL instance, so no data leaves the building. Non-regulated flows (internal process documentation, general FAQ) are routed to OpenAI or Anthropic APIs where quality and speed matter more than data residency. The routing logic is documented in the ISO 27001 Annex A.8.13 (threats) and A.8.15 (access control) sections. The model-agnostic design means the company can swap models as they improve without changing the RAG pipeline, the approval workflow, or the audit trail. The pgvector index is rebuilt when the document store changes, and the embedding model is versioned so that a model upgrade does not silently change the search results.

    4. ISO 27001 controls are built into the pilot, not bolted on

    ISO 27001 requires documented risk assessment, access control, and audit logging for all information assets. When the AI layer processes financial or patient-adjacent data, the model’s input/output logs become part of the information security scope. In practice, this means three things: (1) every classification or draft is logged with a timestamp, user ID, and confidence score; (2) access to the model API keys and the pgvector store follows the same least-privilege rules as any other system; (3) the data flow diagram in the ISO 27001 documentation explicitly includes the AI component. Forfis builds these controls into the pilot from day one rather than retrofitting them after the model is live. The security officer signs off on the control mapping before the pilot goes to production. The audit trail is exportable in a format the company’s ISO 27001 auditor can review, which saves weeks of back-and-forth during the annual certification audit.

    5. Scaling is a repeat of the audit-pilot-rollout cycle, not a bigger agent

    The audit produces a prioritised roadmap, but the pilot is deliberately narrow. Scaling across departments means repeating the audit-pilot-rollout cycle for each new workflow, not pointing the same agent at more data. Each new department’s pilot gets its own baseline measurement, its own human-in-the-loop approval rules, and its own ISO 27001 control mapping. For a 2,000+ employee firm, the realistic timeline is 8-12 weeks per additional department, with the first department’s rollout feeding lessons into the second. The architecture (pgvector, model-agnostic API layer, Google Workspace integration) stays the same; the prompts, approval thresholds, and data sources change per department. The key discipline is that no department skips the baseline measurement. The first department’s error log becomes the test suite for the second department’s pilot, which catches edge cases that the first team did not anticipate. This is how a 4-week audit becomes a 12-month programme without losing the measurement rigour that makes the business case defensible.

    6. The synthesis: measurement is the product

    The most common failure mode is skipping the baseline measurement. Teams deploy an agent, see it working, and assume it is faster and more accurate than the manual process, but they never measured the manual process’s cycle time and error rate before the agent went live. Without that baseline, the business case is anecdotal, and the ISO 27001 audit trail is incomplete. The second failure mode is treating the pilot as a demo: the agent works on the test data but fails on edge cases in production. The third is ignoring the human-in-the-loop approval step, which means the agent makes errors that a human would have caught. The fourth is choosing the model before the audit, which locks the architecture into a vendor and makes the ISO 27001 control mapping harder to document. Forfis builds the baseline measurement, the approval workflow, and the model-agnostic routing into the pilot specification from day one. The 4-week audit is not a cost centre; it is the measurement infrastructure that makes every subsequent rollout defensible to the board, the auditor, and the team that has to live with the agent in production.

  • UK Fintech AI Data Enrichment Pilot: 4-Week ISO 27001-Compliant Automation

    The Problem: Manual Data Entry in a Regulated Fintech

    A 51-200 person UK fintech running ISO 27001 faces a specific constraint: compliance data cannot leave the building, yet the team is drowning in manual data entry for client onboarding, transaction enrichment, and regulatory reporting. The process audit identifies one workflow—say, enriching client records from source documents into the CRM—where cycle time is 14 minutes per record and error rate sits at 3.2%. The fixed-scope pilot targets that single process, with a four-week timeline and a measured before/after baseline on both metrics.

    The architecture is deliberately model-agnostic. Open-weight models run on the client’s own hardware, satisfying ISO 27001 Annex A.13 and A.14 requirements without relying on third-party API providers. The AI layer drafts the enriched data, a human reviewer approves anything touching compliance records, and the final output is written back to the existing CRM via its API. No new software is installed; the integration plugs into the system the team already runs.

    The Four-Week Pilot: Audit, Build, Measure

    Week 1 covers the process audit and baseline measurement. The team documents the current workflow: where records originate, which fields are manually entered, where errors occur, and what the cycle time is per record. A sample of 50 records is processed manually to establish the baseline: 14 minutes average cycle time, 3.2% error rate.

    Weeks 2 and 3 cover model configuration and integration. The open-weight model is fine-tuned or prompted to extract and enrich the specific fields in the target workflow. The integration is built through the CRM’s API, so the enriched data lands in the same system the team already uses. Slack or Microsoft Teams is connected via its API, so the human reviewer receives AI-drafted enrichments in the channel they already use, approves or edits them, and the final record is written back.

    Week 4 covers human-in-the-loop testing and final metrics. The same 50-record sample is processed through the automated workflow. The before/after report documents cycle time, error rate, and the number of records requiring human intervention. The pilot ends with a documented deliverable, not an open-ended deployment.

    Compliance: ISO 27001 and On-Premise Models

    ISO 27001 requires documented risk assessment, access control, and audit trails for all systems handling sensitive data. An on-premise open-weight model satisfies the data residency and access control requirements because regulated data never leaves the client’s hardware. The human-in-the-loop approval step provides the audit trail that ISO 27001 Annex A.12.4 (logging and monitoring) expects for automated decisions affecting compliance records.

    The model-agnostic architecture means the company is not locked into a single vendor. If the open-weight model’s quality is insufficient for a specific task, the architecture can route that task to a hosted API where data can leave the building. For a UK fintech with ISO 27001 obligations, the on-premise option is the default for compliance-sensitive workflows, but the architecture allows flexibility where the risk profile permits.

    The integration with Slack or Microsoft Teams keeps the workflow within the team’s existing communication pattern. No new software is installed, no new training is required beyond the approval step, and the audit trail is logged in the same channel the team already uses.

    Scaling Without New Hires: The Operational Payoff

    The pilot replaces manual data entry by extracting, validating, and enriching records from source documents or systems. The AI layer drafts the enriched data, a human reviewer approves anything touching compliance or financial records, and the final output is written back to the existing CRM or ERP via its API. The before/after baseline measures cycle time and error rate on the same sample of records, so the improvement is quantified, not assumed.

    For a 51-200 person company, the goal is to scale operations without new hires. The AI handles the repetitive extraction and enrichment, freeing the team to focus on judgment calls and exceptions. The fixed-scope structure means the pilot ends with measured metrics, not an open-ended deployment. The company then decides whether to scale to additional workflows based on the documented before/after report.

    The internal knowledge search assistant is a natural extension of the same architecture. It uses retrieval-augmented generation over the company’s own documentation, CRM records, and compliance policies. The AI retrieves relevant passages and drafts a response, which a human reviewer can approve or edit before it is shared. This replaces the manual process of searching through PDFs, shared drives, and CRM notes to answer internal queries.

  • AI Process Audit vs. Support Ticket Cost Reduction: A UK E-commerce Comparison

    What is being compared

    The two options are distinct in scope and objective. AI process audit and roadmap is a diagnostic engagement that identifies which workflows in the company’s back office are worth automating, designs the architecture, and produces a fixed-scope pilot plan. It is a strategic investment that reduces error rates and establishes a baseline for future automation. Lower cost per support ticket is an operational goal that focuses on reducing the cost of handling customer support tickets, typically through AI triage and first-response agents. It is a tactical investment that reduces labor costs and improves response times. The two options are not mutually exclusive, but they serve different purposes and have different success metrics. The audit is about reducing error rates in the back office; the support ticket cost reduction is about reducing labor costs in customer support. The audit is a prerequisite for the support ticket cost reduction, because the audit identifies which workflows are worth automating and designs the architecture that will support them.

    Criteria for comparison

    The comparison is judged against eight criteria that matter to a 201-500 e-commerce company in the UK operating under PCI DSS. Error rate reduction is the primary metric for the audit; the goal is to reduce the error rate in invoice processing from a baseline of 3-5% to under 1%. Cost per support ticket is the primary metric for the support ticket option; the goal is to reduce the cost per ticket from £12 to £4. Compliance is a hard constraint; the system must comply with PCI DSS Requirement 3.4 and UK GDPR. Timeline is a practical constraint; the pilot must be delivered in 2 weeks. Integration is a technical constraint; the system must integrate with Google Workspace and the existing ERP. Vendor lock-in is a strategic concern; the architecture must be model-agnostic. Scalability is a long-term concern; the system must scale from one workflow to multiple workflows. Operational overhead is a practical concern; the system must be manageable by the existing operations team.

    Comparison table

    Criterion AI Process Audit and Roadmap Lower Cost per Support Ticket
    Error rate reduction 3-5% to under 1% in invoice processing No direct impact on back-office error rate
    Cost per support ticket No direct impact on support ticket cost £12 to £4 per ticket
    Compliance (PCI DSS) Designs data flow to mask PAN before model access Requires separate PCI DSS compliance for support data
    Timeline (2 weeks) Achievable for single workflow pilot Achievable for single workflow pilot
    Integration (Google Workspace) Integrates with Google Workspace for document access Integrates with helpdesk and CRM
    Vendor lock-in Model-agnostic architecture Model-agnostic architecture
    Scalability Scales from one workflow to multiple workflows Scales from one channel to multiple channels
    Operational overhead Requires human-in-the-loop approval for money-touching actions Requires human-in-the-loop approval for escalations

    Scenario-by-scenario verdict

    The audit wins when the company’s primary pain point is error rate in the back office. A 201-500 e-commerce company in the UK processing 500-2,000 invoices per month with a 3-5% error rate is losing £15,000-£50,000 per year in rework, disputes, and penalties. The audit identifies the specific workflows that are causing the errors, designs the architecture to reduce the error rate, and delivers a fixed-scope pilot that proves the value. The support ticket cost reduction wins when the company’s primary pain point is labor cost in customer support. A 201-500 e-commerce company handling 1,000-5,000 support tickets per month at £12 per ticket is spending £12,000-£60,000 per month on support labor. The support ticket option reduces the cost per ticket to £4, saving £8,000-£40,000 per month. The two options are complementary, but the audit is the prerequisite for the support ticket option, because the audit identifies which workflows are worth automating and designs the architecture that will support them.

    Recommendation

    The recommendation is to start with the AI process audit and roadmap. The audit is the prerequisite for the support ticket cost reduction, and it addresses the company’s primary pain point: error rate in the back office. The audit delivers a fixed-scope pilot on invoice processing in 2 weeks, with a measured before/after baseline on cycle time and error rate. If the pilot meets the success metric, the company proceeds to rollout and managed operation. The support ticket cost reduction is a natural next step, but it is not the priority. The audit is a strategic investment that reduces error rates, establishes a baseline, and designs the architecture for future automation. The support ticket cost reduction is a tactical investment that reduces labor costs, but it does not address the root cause of the company’s pain: error rate in the back office. The audit is the right first step for a 201-500 e-commerce company in the UK operating under PCI DSS.

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

    1. Map the current order and shipment workflow

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

    2. Build the document extraction pipeline

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

    3. Configure the customer-facing assistant

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

    4. Wire the integration to Google Workspace and the CRM

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

    5. Run parallel tests against live data

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

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

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