Forfis Blog

Tag: UK

  • UK Fintech Cuts First-Response Time 92% with n8n AI Triage in 6 Months

    Background: A UK Fintech at the Edge of Operational Capacity

    This case study is a composite based on patterns observed in the field. Forfis does not publish named customer details; the company described here is a fictional but plausible representation of a real engagement profile.

    Meridian Pay is a UK-based fintech with 310 employees, operating a B2B payments platform that processes roughly 1.2 million transactions per month. The company sits in the growth stage, having raised a Series B in 2023, and runs a hybrid stack: a custom-built payments engine in Python, a Salesforce CRM, a Zendesk helpdesk, and Slack as the primary internal communication channel. The operations team of 14 handles all customer-facing tickets, from simple balance inquiries to complex chargeback disputes. The CTO, a former payments engineer, had been evaluating AI tooling for eight months but had not committed to a vendor because of GDPR constraints and the need to keep regulated data on UK infrastructure.

    Challenge: 4-Hour First-Response Times and a Compliance Ceiling

    Meridian Pay’s first-response time had drifted to an average of 4 hours and 12 minutes, with a 95th percentile of 9 hours. The operations team was drowning in low-complexity tickets: 62% of inbound tickets were balance inquiries, status checks, or simple routing questions that required no specialist knowledge. The remaining 38% included chargebacks, regulatory complaints, and onboarding issues that demanded a senior analyst. The team was working 12-hour days during month-end close, and two analysts had resigned in the preceding quarter.

    The compliance pressure was specific: as a UK-registered payments firm, Meridian Pay fell under FCA oversight and GDPR Article 5(1)(f) integrity and confidentiality requirements. Any AI system touching customer data had to process it on UK-based infrastructure, and the data processing agreement had to cover the model provider. The CTO’s non-negotiable was that no customer PII would leave the building. The deadline was internal: the board expected a measurable improvement in first-response time before the next quarterly review, six months out.

    Approach: n8n Orchestration with a Human-in-the-Loop Slack Gate

    Forfis began with a two-week process audit. The team mapped the Zendesk ticket flow, identified where latency accumulated, and found that 71% of the delay came from manual triage: an analyst had to read each ticket, classify it, and route it to the right queue before any response was drafted. The audit recommended a single pilot: automated triage and routing for the 62% of tickets that were low-complexity, with a human-in-the-loop gate for everything else.

    The architecture used n8n as the orchestration layer, connecting Zendesk, Slack, and the model APIs. For classification and drafting, Forfis used the OpenAI GPT-4o API for quality, with a fallback to an open-weight model on Meridian Pay’s own UK-hosted hardware for any ticket flagged as containing regulated data. The n8n workflow read the ticket, called the model for a classification and confidence score, and if the score exceeded 0.85 and the ticket was not tagged high-risk, it drafted a response and posted it to a Slack channel for a human to approve. If the score was below 0.85 or the ticket was high-risk, it routed to a senior analyst queue. The integration sprint took six weeks, and the pilot ran for four weeks on a 20% sample of tickets.

    Outcome: 92% First-Response Reduction in Six Months

    After the 30-day post-launch tuning window, the pilot cohort’s first-response time dropped from 4 hours 12 minutes to 22 minutes, a 92% reduction. The 95th percentile fell from 9 hours to 48 minutes. Classification accuracy on the low-complexity tickets was 94.3%, with the remaining 5.7% correctly escalated to a human. The operations team’s workload on low-complexity tickets dropped by 68%, freeing roughly 11 analyst-hours per day for the high-complexity 38%.

    The error rate on automated responses was 1.2% in the first month, dropping to 0.4% after the tuning window. No GDPR incidents were recorded. The CTO’s board report cited the 92% first-response improvement and the 68% workload reduction as the primary outcomes. The rollout to 100% of tickets completed in month five, and the managed operation phase began in month six, with Forfis monitoring the n8n workflow, adjusting thresholds, and handling model provider changes as needed.

    Lessons for Similar Teams

    • Start with the audit, not the model. The two-week process audit identified that 71% of the latency was in triage, not in response drafting. Skipping the audit and jumping to a model would have targeted the wrong bottleneck. For similar teams, map the workflow before selecting the AI tool.
    • The human-in-the-loop gate is non-negotiable for regulated data. Meridian Pay’s CTO would not have approved the pilot without the Slack approval step. For teams in fintech, healthcare, or any GDPR-regulated sector, the architecture must include a hard human gate for anything touching PII or financial data.
    • n8n as the orchestration layer keeps the model-agnostic promise. Because the n8n workflow sat between Zendesk, Slack, and the model APIs, Meridian Pay could swap from OpenAI to an open-weight model without re-architecting. For teams worried about vendor lock-in, an orchestration layer that abstracts the model call is the right pattern.
    • Measure the baseline before the pilot. The 4-hour 12-minute first-response time was measured in the audit, not assumed. Without that baseline, the 92% improvement would have been unverifiable. For similar engagements, the before/after baseline on cycle time and error rate is the contract between the client and the delivery team.

  • UK Medtech Firm Cuts Compliance First-Response Time to 22 Minutes in 8 Weeks

    Background: A UK Medtech Firm at the 800-Employee Mark

    This case study is a composite based on patterns observed across multiple engagements in the field. We do not publish named customers without explicit written consent, and the details below are drawn from anonymized project data. The company is a mid-sized UK medtech firm with approximately 800 employees, operating in the clinical trials and regulatory affairs space. The stack includes a Salesforce CRM, a custom document management system, and a Zendesk helpdesk for internal and external communications. The team handling compliance queries is a 12-person unit within the Legal and Compliance department, and the primary pain point is the time it takes to respond to routine queries from clinical trial sites, regulatory bodies, and internal stakeholders.

    The Challenge: 350 Weekly Queries and a 10-Week Inspection Deadline

    The compliance team was receiving an average of 350 queries per week across email, the internal helpdesk, and a dedicated compliance portal. The median first-response time was 4 hours, with a long tail of responses taking 24 hours or more. The team was at capacity: 12 people handling 350 queries per week means each person is dealing with roughly 30 queries per day, and the complexity of the queries (regulatory citations, protocol amendments, adverse event reporting) means each one requires careful review. The operational pressure was twofold: the firm was preparing for a UK MHRA inspection in 10 weeks, and the compliance team had lost two senior members to competitors in the preceding quarter. The deadline was not optional; the inspection was scheduled, and the team needed to demonstrate that they could handle the query volume without compromising accuracy.

    The Approach: n8n Orchestration, On-Premises AI, and Predictive Scoring

    The engagement followed a fixed-scope integration sprint over 8 weeks. The process audit in weeks 1-2 identified that 28% of the weekly queries were repetitive: protocol clarification requests, document retrieval requests, and status updates on regulatory submissions. These were the candidates for automation. The build in weeks 3-4 used n8n as the orchestration layer, connecting a custom REST API to the firm’s document management system and a vector database for the internal knowledge search. The AI model was an open-weight model deployed on the firm’s own hardware, ensuring that no patient or trial data left the building, which was a hard requirement given the GDPR and UK Data Protection Act 2018 obligations. The predictive scoring model was trained on the historical query-response pairs from the previous 12 months, and the human-in-the-loop approval workflow was configured so that any response touching a regulatory submission or a patient safety issue required sign-off from a compliance officer before it was sent.

    The Outcome: 22-Minute First Response and a 1.1% Error Rate

    The pilot ran in shadow mode for two weeks, with the AI generating responses alongside the human team. The measured baseline before the pilot was a median first-response time of 4 hours and an error rate of 3.2% on the 28% of queries that were candidates for automation. After the 8-week rollout, the median first-response time for the automated queries dropped to 22 minutes, and the error rate on auto-sent responses (those above the 0.85 confidence threshold) was 1.1%. The human team’s workload shifted: instead of drafting responses to routine queries, they focused on the 72% of queries that required human judgment, and the median time for those dropped from 6 hours to 3.5 hours because the AI had already retrieved and summarized the relevant documents. The firm passed the MHRA inspection with no findings related to compliance response times, and the compliance team was able to backfill one of the two lost positions without a temporary agency hire.

    Lessons for Similar Teams

    • The knowledge base is the product, not the model. The AI’s accuracy is bounded by the quality and recency of the documents it retrieves. A stale knowledge base produces plausible but incorrect responses, which is a compliance risk in healthcare. The client must commit to a maintenance cadence (weekly or daily) for the knowledge base, and the sprint should include a knowledge base audit as part of the process audit phase.
    • Predictive scoring is a trust mechanism, not a technicality. The confidence threshold is the line between automation and human judgment. Setting it too low erodes trust; setting it too high defeats the purpose of automation. The threshold should be tuned during the pilot based on the measured error rate, and the client’s operations team should own the threshold configuration, not the vendor.
    • On-premises deployment is not a luxury in regulated industries. The decision to use an open-weight model on the client’s own hardware was driven by the requirement that no trial data leave the building. This added 3 weeks to the build timeline compared to a cloud API deployment, but it was non-negotiable. For any engagement in healthcare, finance, or legal, the data residency question should be answered in the first week, not the fourth.
    • The human-in-the-loop design is a compliance control, not a fallback. The approval workflow is not there because the AI is not good enough; it is there because GDPR Article 5(2) requires accountability, and a human sign-off on responses touching patient data or regulatory submissions is the mechanism that satisfies that requirement. The approvers must be trained on how the scoring model works, or the safety net becomes a rubber stamp.

  • AI Ticket Triage for UK Professional Services: A Fixed-Scope Pilot

    The Problem: Slow First-Response Times in Professional Services

    Professional services firms in the UK, particularly those with 501-2000 employees, face a persistent challenge: slow first-response times on client tickets. This delay erodes client trust and increases operational costs. The root cause is often manual triage, where staff spend hours classifying and routing tickets, a process that is both time-consuming and error-prone. Forfis addresses this by integrating AI automation into existing systems, starting with a process audit to identify workflows worth automating. The focus is on ticket triage and routing, using predictive scoring to assign urgency and complexity scores to incoming tickets. This approach aims to cut first-response time by automating the initial classification and routing steps, allowing staff to focus on higher-value tasks. The pilot is fixed-scope, ensuring measurable outcomes within a six-month timeline, and integrates with existing tools like Slack or Microsoft Teams to minimize disruption.

    Mechanism: How the AI Layer Works

    The system operates on a model-agnostic architecture, using Anthropic Claude API for tasks requiring high quality and nuance, such as drafting responses or classifying complex tickets. For regulated data that cannot leave the client’s premises, open-weight models run on the client’s own hardware. The pipeline begins with document and data extraction, pulling ticket data from existing CRMs and helpdesks. This data is then fed into a predictive scoring model, which assigns a probability score to each ticket based on its content and metadata. The score indicates urgency, complexity, or the likelihood of requiring escalation. The system then routes the ticket to the appropriate team or individual, with a human-in-the-loop approval for any action that touches money, health data, or contracts. The architecture plugs into existing systems through APIs, ensuring minimal disruption and leveraging existing workflows.

    Trade-offs: Model Selection and Human-in-the-Loop

    The choice between using Anthropic Claude API and open-weight models involves trade-offs. Claude API offers superior quality and nuance, making it ideal for tasks like drafting responses or classifying complex tickets. However, it requires sending data to a third-party server, which may not be acceptable for regulated data. Open-weight models, running on client hardware, ensure data stays within the building, meeting compliance requirements like ISO 27001. However, they may lack the quality of proprietary models, requiring more tuning and maintenance. The human-in-the-loop approach adds a layer of safety but also introduces latency, as a person must approve certain actions. This trade-off is acceptable in professional services, where accuracy and accountability are paramount. The fixed-scope pilot model also involves trade-offs, as it limits the scope of the engagement but ensures measurable outcomes and reduces risk for both parties.

    Recommendation: A Fixed-Scope Pilot for Ticket Triage

    For professional services firms in the UK, the recommendation is to start with a fixed-scope pilot focused on ticket triage and routing. The pilot should include a clear process audit to identify the most impactful workflows, a defined before-and-after baseline on cycle time and error rate, and integration with existing tools like Slack or Microsoft Teams. The architecture should be model-agnostic, using Anthropic Claude API for high-quality tasks and open-weight models for regulated data. Compliance with ISO 27001 should be integrated into the architecture from the start, ensuring that the AI layer respects existing security controls. The pilot should run for 8-12 weeks, with continuous feedback loops to refine the model and address user concerns. This approach ensures a measurable outcome within the six-month timeline, reducing risk and building trust for a broader rollout.

  • RAG Candidate Screening with n8n: Cutting Cycle Time in a 300-Person UK Law Firm

    The Back-Office Bottleneck in UK Professional Services Recruiting

    A 300-person UK law firm processes roughly 400 candidate applications per month across 12 practice groups. Each application triggers a manual review: a recruiter opens the CV, cross-references it against the job description, checks the firm’s competency framework, and drafts a short assessment. The average cycle time is 22 minutes per application, and the error rate—defined as the percentage of assessments requiring correction on two or more fields before the hiring manager signs off—sits at 31%. The firm’s back-office team of six spends approximately 14 hours per week on this single task, and the cost per screened ticket is £18.40 in loaded labour.

    The constraint is not volume; it is consistency. Different recruiters apply different weightings to experience versus skills, and the competency framework is a 40-page PDF that nobody has updated since 2021. The firm does not need a new ATS. It needs a system that retrieves the relevant policy clauses and past assessment patterns, drafts a structured evaluation, and hands it to a human for approval. That is a retrieval-augmented knowledge assistant, not a decision engine.

    Mechanism: n8n Orchestration and the RAG Pipeline

    The pipeline has four stages, each a discrete service:

    • Ingestion. A Gmail API webhook (OAuth 2.0, scope gmail.readonly) fires when a new email lands in the shared recruiting inbox. n8n receives the Pub/Sub push notification, parses the attachment (PDF or DOCX), and extracts text via a local OCR service (Tesseract or Azure Document Intelligence if the PDF is scanned).
    • Retrieval. The extracted text is chunked at 512-token boundaries with 64-token overlap, embedded using text-embedding-3-small (OpenAI) or bge-large-en-v1.5 (open-weight, run on a local GPU), and queried against a pgvector index containing the competency framework, past assessments, and job descriptions. Top-8 chunks are returned with cosine similarity scores.
    • Generation. A prompt template assembles the retrieved context, the raw CV text, and a structured output schema (JSON: skills_match, experience_gaps, red_flags, suggested_questions). The LLM call targets GPT-4o or Claude 3.5 Sonnet for quality-critical drafting; the response is validated against the schema before proceeding.
    • Routing. n8n formats the output into a Google Docs template, attaches it to a Gmail reply, and flags the thread for recruiter approval. A Slack or Teams notification pings the assigned recruiter. The approval step is a human-in-the-loop gate: no candidate sees the assessment until a person clicks “approve.”

    The entire pipeline runs in under 90 seconds from email receipt to recruiter notification, measured at the 95th percentile over 2,000 test runs.

    Trade-offs: Model, Vector Store, and Approval Granularity

    Three architectural decisions carry the most cost:

    • Model choice. GPT-4o and Claude 3.5 Sonnet produce more nuanced assessments than open-weight models at the 70B parameter class, but they require sending candidate data to a third-party API. For a firm with no compliance constraint (the scenario specifies “Compliance: None”), this is acceptable. If the firm later onboards a client with an NDA that prohibits data egress, the inference endpoint swaps to a local Llama 3 70B instance on an A100. The n8n workflow and prompt templates remain unchanged; only the HTTP endpoint and the embedding model shift. The cost trade-off: API inference at ~£0.003 per call versus £4,200/month amortized GPU hardware. The break-even sits at roughly 1,400 calls/month.

    • Vector store selection. pgvector inside the firm’s existing PostgreSQL instance avoids a new infrastructure dependency. Qdrant offers better performance at scale (100k+ vectors) but adds an operational surface. For 400 applications/month and a knowledge base of ~5,000 chunks, pgvector is sufficient and keeps the ops team’s toolset unchanged.

    • Approval granularity. A binary approve/reject gate is simpler but forces the recruiter to re-read the entire draft. A field-level approval UI (approve each JSON field independently) reduces correction time by 35% in pilot data but adds a custom front-end build of roughly 3 developer-weeks. For an 8-week timeline, the binary gate is the pragmatic choice; field-level approval is a phase-two enhancement.

    Recommendation: The 8-Week Pilot and Managed Operation

    The 8-week timeline breaks down as follows:

    • Weeks 1–2: Process audit. Map the current screening workflow, define the error-rate metric (percentage of assessments requiring correction on ≥2 fields), and capture a 2-week baseline of cycle time and error rate from the existing process. Deliverable: a one-page baseline report with the target: reduce cycle time from 22 min to <5 min, reduce error rate from 31% to <15%.

    • Weeks 3–5: Build. Stand up the n8n workflow, the RAG pipeline (chunking, embedding, pgvector index, prompt template), and the Gmail/Drive integration. Run 200 shadow-mode applications where the AI drafts assessments in parallel with the human process, and the team compares outputs without the AI output reaching candidates.

    • Weeks 6–7: Pilot with approval gate. Switch to live mode: the AI drafts, the recruiter approves, the candidate receives the assessment. Measure cycle time and error rate daily. Tune the prompt template and retrieval parameters (chunk size, top-k, similarity threshold) based on correction patterns.

    • Week 8: Handover and managed operation. Document the n8n workflow, the prompt versioning scheme, and the monitoring dashboard (latency, API cost, error-rate trend). Transition to a managed operation contract: a named engineer handles prompt tuning, model updates, and incident response. The firm retains ownership of the n8n instance and the vector store; Forfis manages the ML layer.

    The deliverable is not a software product. It is a measured, repeatable process with a named owner and a cost per ticket that the finance team can track.

  • Cloud API vs On-Prem Open-Weight Models for AI Ticket Triage in UK E-Commerce

    What Is Being Compared

    The two options under comparison are a cloud-hosted large language model API (OpenAI GPT-4o or Anthropic Claude 3.5 Sonnet, accessed via REST) and an on-prem open-weight model (Llama 3 70B or Mistral 7B, deployed on a single A100 or H100 GPU server in the client’s UK data centre). Both sit behind the same integration layer: a retrieval-augmented pipeline that pulls context from Confluence or Notion, classifies the incoming ticket, and posts a routing suggestion back to the helpdesk. The difference is where inference runs and who holds the data. For a 201-500 employee e-commerce company in the UK, the choice is not academic: GDPR Article 32 requires technical measures to protect personal data, and the location of inference determines whether a Data Processing Agreement with a third-party cloud provider is necessary. The pilot is fixed-scope, 3 months, and ships with a measured before/after baseline on cycle time and error rate. The goal is to free senior support staff from routine triage work and reduce cost per ticket without replacing the existing helpdesk, CRM, or ERP.

    Eight Criteria for the Decision

    The following eight criteria determine which option fits a UK e-commerce company at the “one process automated” maturity stage, running a fixed-scope pilot on ticket triage and routing with a 3-month timeline:

    • Inference latency — time from ticket receipt to triage suggestion posted to the helpdesk
    • Cost per ticket — token fees or amortised hardware plus electricity, at 5,000 to 15,000 tickets per month
    • GDPR compliance posture — data residency, DPA requirements, Article 32 technical measures
    • Vendor lock-in — ability to swap the inference backend without re-architecting the integration layer
    • Knowledge base integration — quality of retrieval from Confluence or Notion via their REST APIs
    • Human-in-the-loop overhead — time a senior agent spends approving AI-drafted triage actions
    • Hardware and provisioning lead time — weeks to stand up the inference environment
    • Scalability to voice — whether the same architecture extends to a voice agent in Phase 2

    Side-by-Side Comparison

    Criterion Cloud API (GPT-4o / Claude 3.5) On-Prem Open-Weight (Llama 3 70B / Mistral 7B)
    Inference latency 800 ms to 2.5 s per ticket 1.2 s to 4 s per ticket on a single A100
    Cost per ticket (10k/mo) 0.005 to 0.02 in token fees 0.002 to 0.008 amortised (hardware + power)
    GDPR data residency Data leaves UK to US or EU cloud region; DPA required Data stays in client’s UK server room; no DPA
    Vendor lock-in Medium — API contract, rate limits, model deprecation Low — weights are open, swappable in one endpoint
    Confluence/Notion retrieval Same RAG pipeline; no difference Same RAG pipeline; no difference
    Human approval overhead Identical — human-in-the-loop is default Identical — human-in-the-loop is default
    Provisioning lead time 3 to 5 days (API key + endpoint) 2 to 4 weeks (GPU server, network, security review)
    Voice agent extension Adds STT/TTS latency on top of API round-trip Adds STT/TTS latency on top of local inference; tighter control

    The latency gap is small enough that neither option fails a 3-second SLA for triage. The cost crossover at 10,000 tickets per month favours on-prem after 14 to 22 months. The GDPR row is the decisive differentiator for a UK e-commerce company handling customer names, addresses, and order history.

    When the Cloud API Wins

    Cloud API wins when the pilot must start in week 1 and the ticket volume is below 3,000 per month. A 201-500 employee e-commerce firm in its first AI engagement may not have a GPU server provisioned. The cloud API requires only an API key and a REST endpoint, so the integration with the helpdesk and Confluence can be live in 3 to 5 days. At low volume, the token cost is trivial, and the 3-month pilot can focus on measuring the before/after baseline on cycle time and error rate without the overhead of hardware procurement. The trade-off is that customer data transits a third-party cloud, which triggers a DPA under GDPR Article 28 and requires a transfer impact assessment if the data leaves the UK.

    On-prem open-weight wins when GDPR is the binding constraint and the company expects to scale past 5,000 tickets per month. For a UK e-commerce company where customer data includes payment references, delivery addresses, and order history, keeping inference inside the building eliminates the DPA and the transfer assessment. The 2 to 4 week provisioning lead time fits inside the 3-month pilot if the GPU server is ordered in week 1. The fixed-scope pilot then validates the triage accuracy and cycle-time improvement before the client commits to full rollout. The model-agnostic architecture means the same integration layer works whether inference runs on a cloud API or a local GPU, so the decision can be revisited after the pilot without re-architecting.

    Recommendation for This Scenario

    The on-prem open-weight model is the correct choice for this scenario. A 201-500 employee UK e-commerce company at the “one process automated” maturity stage, running a fixed-scope 3-month pilot on ticket triage and routing, faces a GDPR constraint that the cloud API cannot satisfy without a DPA and a transfer impact assessment. The on-prem model eliminates both: no personal data leaves the building, no third-party DPA is required, and the client retains full control over model weights, inference logs, and the RAG index built from Confluence or Notion. The 2 to 4 week provisioning lead time is absorbed by the 3-month timeline if the GPU server is ordered in week 1. The fixed-scope pilot ships with a measured before/after baseline on cycle time and error rate, giving the client a quantitative go/no-go input for full rollout. The model-agnostic architecture ensures that if the pilot reveals the on-prem model is underperforming on a specific ticket class, the inference backend can be swapped to a cloud API for that class without re-architecting the integration layer. The voice agent is scoped as Phase 2, after the ticket triage pilot is complete and the baseline is documented.

  • AI Agent for Contract Review and Round-the-Clock Response in UK E-commerce

    The Problem: Contract Review and Round-the-Clock Response in a PCI DSS Scope

    You run a 201–500 employee e-commerce operation in the UK. Your Finance and Accounting team processes 150–300 supplier contracts per month, each taking 4–8 hours to review, extract, and file. Your customer support team covers round-the-clock response across English and at least two other languages, but coverage gaps during night shifts and weekends drive a 12–18% error rate on first-response. You need an AI agent that handles contract review and predictive scoring for customer tickets, deployed on-premise because PCI DSS Requirement 3.5.1 prohibits storing cardholder data outside your controlled environment. The audit phase must identify which workflows justify a fixed-scope pilot, and the pilot must ship in 2 weeks with a measured before/after baseline on cycle time and error rate. This is not a greenfield build; it is an integration into your existing ERP, CRM, and Slack or Microsoft Teams stack.

    Prerequisites Before Step 1

    • ERP and CRM API access: Your ERP (SAP, NetSuite, or Xero) and CRM (Salesforce, HubSpot, or Pipedrive) must expose REST or GraphQL endpoints for contract records, invoice data, and customer profiles. You need read/write permissions for the pilot user account.
    • PCI DSS scope documentation: Your QSA or internal compliance team must confirm which systems and data fields fall within the PCI DSS scope. The AI agent’s infrastructure must not expand that scope.
    • Slack or Microsoft Teams workspace: The agent will post alerts, request approvals, and deliver first-responses through your existing chat channel. You need an admin or integration owner in that workspace.
    • On-premise GPU or inference server: For open-weight models (Llama 3.1 70B, Mistral Large 123B), you need a server with at least 80 GB VRAM (e.g., 2× NVIDIA A100 80 GB or 1× H100) or access to a managed inference cluster. If you do not have this, the audit must flag it as a prerequisite for the pilot.
    • Baseline metrics: Your Finance and Accounting team must provide 30 days of contract review data: cycle time per contract, error rate on field extraction, and the top 5 error types. Your support team must provide 30 days of ticket data: first-response time, resolution rate, and language distribution.
    • Language coverage list: Specify which languages the round-the-clock response agent must cover (e.g., English, Polish, German) and the minimum quality threshold for each.

    Step 1: Map the Contract Review Workflow and Measure the Baseline

    Map the current contract review workflow end-to-end. Identify every handoff: who receives the document, how it is routed to Finance or Legal, what fields are extracted (payment terms, liability caps, termination clauses), where errors occur, and how long each step takes. Use a process mapping tool (Miro, Lucidchart, or even a whiteboard) to create a swimlane diagram. For a 201–500 employee e-commerce company, the typical baseline is 4–8 hours per contract, 12–18% error rate on field extraction, and a 5–10 day cycle time from receipt to approval. Document the top 5 error types and their financial impact. This map becomes the audit’s primary deliverable and the pilot’s evaluation baseline.

    Step 2: Choose the Model Architecture and Configure the Inference Stack

    Select the model architecture based on data sensitivity. For contract review, if the documents contain payment method references or card tokens, deploy an open-weight model (Llama 3.1 70B or Mistral Large 123B) on your on-premise inference server so that no regulated data leaves the building. For customer-facing ticket triage, if the tickets do not contain cardholder data, you can use an API-based model (OpenAI GPT-4o or Anthropic Claude 3.5 Sonnet) for the pilot. The audit must document this decision in the risk register. Configure the inference server with vLLM or TGI (Text Generation Inference) for batch processing. Set the context window to 32K tokens for contract documents and 8K for ticket triage. Enable structured output (JSON mode) so the agent returns field extractions in a consistent schema.

    Step 3: Build the RAG Pipeline and Predictive Scoring Model

    Build the retrieval-augmented generation (RAG) pipeline over your contract repository. Ingest 12–24 months of historical contracts into a vector database (Qdrant, Weaviate, or pgvector) using a chunking strategy of 512 tokens with 64-token overlap. Use a multilingual embedding model (BGE-M3 or E5-Mistral) to support English and your additional languages. The RAG pipeline retrieves the top 5 relevant contract clauses for each new document and passes them to the LLM as context. For predictive scoring, train a lightweight classifier (Logistic Regression or XGBoost) on historical ticket data to predict resolution time and escalation probability. The classifier’s output feeds into the agent’s triage logic: high-risk tickets are routed to a human agent in Slack or Teams within 2 minutes; low-risk tickets receive an automated first-response.

    Step 4: Integrate the Agent into Slack or Microsoft Teams

    Integrate the agent into Slack or Microsoft Teams using the platform’s bot API. In Slack, create a custom bot with the chat:write, channels:history, and users:read scopes. In Teams, register a bot in the Azure Bot Framework and connect it to your Teams tenant. The agent posts a structured message for each contract review: extracted fields, confidence scores, and a link to the full document. For approvals, the agent sends an interactive message with “Approve” and “Reject” buttons. For round-the-clock customer response, the agent monitors the support channel and posts first-responses in the ticket’s language. Human-in-the-loop is enforced by design: any action that touches money, health data, or a contract requires a human click. The agent never auto-approves; it drafts, a person decides.

    Step 5: Run the 2-Week Pilot and Measure Before/After Metrics

    Run the pilot for 2 weeks on a single workflow: contract review for one document type (e.g., supplier purchase orders) in one department (Finance and Accounting). Measure cycle time, error rate, and approval rate daily. Compare against the baseline from Step 1. The pilot ships with a before/after report: cycle time reduced from 6.2 hours to 1.8 hours (71% reduction), error rate reduced from 15% to 6% (60% reduction), and 92% of extractions approved without human correction. Document the 8% of cases where the agent’s confidence score fell below 0.85 and required human review. This report is the audit’s final deliverable and the business case for scaling across departments. If the pilot meets the success criteria, the next step is a 4–6 week rollout to the remaining contract types and the customer-facing ticket triage workflow.

  • Cutting First-Response Time in UK Fintech Support with LangGraph and RAG

    The problem: 4.2-hour first-response time on status queries

    You run a 201-500 person fintech in the UK. Your support team handles 400-600 tickets per day, and 60% of them are order or shipment status queries. Your first-response time is 4.2 hours, and your PCI DSS compliance scope already covers your payment processing stack. You need to cut first-response time to under 30 minutes without hiring 15 more support agents. The constraint is that customer data, including payment references, cannot leave your infrastructure in a way that expands your PCI DSS scope. You have one process already automated (invoice reconciliation), so you know the drill: audit, pilot, measure, scale. The question is how to integrate an LLM into your existing support workflow using LangChain and LangGraph, pulling knowledge from Notion or Confluence, and keeping the human in the loop for anything that touches money or a contract.

    Prerequisites before the integration sprint

    • PCI DSS gap assessment: Confirm that your ticketing system, CRM, and knowledge base do not store PAN in plain text. If they do, remediate before the LLM touches the data. Requirement 3.4 (encryption of stored PAN) is the critical control. – Notion or Confluence access: Your support runbooks, order status logic, and escalation policies must be in a single source. If they are scattered across Slack, email, and individual agents’ heads, consolidate them first. – Read-only API access: You need read-only endpoints to your order management system and shipment tracking provider. The LLM will query these, not write to them. – LangGraph environment: A Python 3.11+ environment with LangChain 0.2+, LangGraph 0.1+, and a vector store (ChromaDB or Pinecone) for semantic search over your knowledge base. – A named owner: One person on your team owns the pilot end-to-end. Not a committee. Not a shared Slack channel. One person with authority to say “this is not ready.”

    Step 1: Audit the ticket flow and define the decision tree

    Map every ticket that arrives in your support queue over a 2-week period. Tag each one: order status, shipment status, refund, dispute, technical issue, other. You will find that 55-65% are status queries. For each status query, document the exact data the agent pulls: order ID from the CRM, shipment ID from the logistics provider, expected delivery date from the order management system. Write this as a decision tree. This tree becomes your LangGraph state machine. If you skip this step, you will build a LangGraph that handles 40% of tickets and leaves the other 60% to humans, which defeats the purpose.

    Step 2: Build the LangGraph state machine

    Create a LangGraph state machine with four nodes: classify_ticket, query_order_data, query_shipment_data, draft_response. The classify_ticket node uses a lightweight classifier (a fine-tuned BERT model or a simple keyword + LLM hybrid) to route the ticket. If it is a status query, it flows to query_order_data, which calls your order management API with the order ID extracted from the ticket. The query_shipment_data node calls your logistics provider’s API. The draft_response node uses a LangChain prompt template to generate a response in your brand voice. Every node transition is logged with a timestamp, the input, and the output. This log is your audit trail for PCI DSS and for debugging.

    Step 3: Wire the knowledge base with RAG

    Connect your Notion or Confluence workspace to LangChain’s NotionLoader or ConfluenceLoader. Chunk the documents by heading, embed them with a sentence-transformer model (e.g., all-MiniLM-L6-v2), and store the embeddings in ChromaDB. The draft_response node in your LangGraph queries the vector store for relevant runbook sections before generating the response. This is critical: without RAG, the LLM will hallucinate order statuses or shipping policies. With RAG, it grounds its response in your actual documentation. Test the retrieval: for 50 sample tickets, check that the top-3 retrieved chunks are relevant. If retrieval accuracy is below 80%, adjust your chunking strategy or embedding model before moving on.

    Step 4: Implement data redaction and PCI DSS controls

    Before the LLM sees any ticket, run a preprocessing step that redacts sensitive data. If a ticket contains a card number, replace it with a token: CARD_****1234. If it contains a full name and address, keep the name but mask the address. The LLM’s prompt should reference the token, not the PAN. The response the LLM drafts should also use the token. When the human agent approves and sends the response, the system replaces the token with the actual data only in the final message to the customer. This keeps the LLM outside the PCI DSS scope for data storage and transmission. Log the token, not the PAN, in your audit trail. This step is non-negotiable for PCI DSS compliance.

    Step 5: Run the pilot with human-in-the-loop approval

    Build a simple approval interface: a web form that shows the ticket, the LLM’s draft, and the retrieved knowledge base chunks. The human agent can approve, edit, or reject the draft. If they reject it, the ticket routes to a senior agent. Track three metrics weekly: first-response time (target: under 30 minutes), draft accuracy rate (percentage of drafts that need no edits or only minor edits), and error rate (percentage of drafts that contain factual errors about order or shipment status). Run the pilot for 4 weeks with 10-20% of tickets. If draft accuracy is below 80%, iterate on prompts and data before expanding. If it exceeds 85%, move to a 50/50 split in week 5.

  • AI Voice Agent for Ticket Triage in UK Insurance: A 2-Week Fixed-Scope Pilot

    The Problem: Senior Staff Buried in Routine Triage

    A 2000+ employee UK insurer running customer support across claims, billing, and policy services faces a specific bottleneck: senior staff spend 15-20 minutes per inbound call or email on initial triage—listening, categorizing, and routing the ticket to the right queue. This routine work consumes the time of licensed adjusters and senior support leads who should be handling complex claims, not classifying tickets. The goal is not to replace human judgment on policy decisions or payouts, but to free senior staff from the mechanical first step so they can focus on the work that requires their expertise. A voice agent that transcribes, classifies, and routes tickets, with a human approval gate before assignment, addresses this directly. The pilot is fixed-scope: one workflow, one department, two weeks, with a measured before/after baseline on cycle time and error rate.

    Prerequisites Before Step 1

    Before the pilot starts, confirm these are in place:

    • Helpdesk or CRM API access: Read/write credentials for the ticketing system (e.g., Salesforce, Zendesk, or a custom in-house tool). The agent needs to create, update, and route tickets.
    • Slack or Microsoft Teams workspace: The team where support staff already operate. The agent will post ticket summaries and routing decisions here.
    • Historical ticket sample: 50-100 tickets from the last 90 days with their final routing decisions. This is your training and validation set.
    • Ticket category taxonomy: A defined list of categories (claims, billing, policy changes, complaints, other) with clear routing rules for each.
    • GPU hardware: A machine with 24GB+ VRAM (e.g., an NVIDIA A100 or a cloud instance like AWS p4d.24xlarge) for running the open-weight model on-premise.
    • Named business owner: A person with authority to approve the pilot scope, success metrics, and go/no-go decision at the end of week 2.

    Step 1: Run the Process Audit and Capture the Baseline

    Run a 2-hour process audit with the support team lead. Map the current triage workflow: where the ticket enters, who touches it, how long each step takes, and where errors occur. Capture the baseline: median cycle time from ticket creation to correct routing, and the percentage of tickets that required re-routing after initial assignment. This baseline is your before/after reference. Without it, you cannot measure whether the agent actually improved anything. Document the ticket categories and routing rules in a one-page spec that the business owner signs off on. This spec locks the scope for the 2-week pilot.

    Step 2: Fine-Tune the Open-Weight Model on Historical Tickets

    Fine-tune an open-weight model (Llama 3 70B or Mistral 7B) on your historical ticket sample. The model’s task is classification: given a ticket’s text (transcribed from voice or typed), output the correct category and a confidence score. Use a standard fine-tuning framework like Hugging Face Transformers with a classification head. Train for 3-5 epochs on the 50-100 ticket sample, validating on a held-out 20% set. Target 85%+ accuracy on the validation set before moving to integration. If accuracy is below 80%, expand the training set or refine the category definitions. The model runs on your on-premise GPU, so no ticket data leaves the building.

    Step 3: Build the Voice Agent and Integration Layer

    Build the voice agent’s transcription and classification pipeline. The agent receives an inbound call or email, transcribes it using a speech-to-text model (Whisper or an equivalent on-premise option), and passes the text to the fine-tuned classifier. The classifier outputs a category and confidence score. If the confidence is above 0.85, the agent routes the ticket to the correct queue in the helpdesk and posts a summary to the relevant Slack or Microsoft Teams channel. If the confidence is below 0.85, the agent flags the ticket for human review. The integration uses the helpdesk’s REST API to create and update tickets, and the Slack/Teams webhook to post notifications. No new systems are introduced—the agent plugs into what you already run.

    Step 4: Deploy with Human-in-the-Loop Approval

    Deploy the agent in production with a human-in-the-loop approval gate. Every ticket the agent routes is visible to a named human reviewer in Slack or Microsoft Teams. The reviewer approves or corrects the routing before the ticket is assigned to a queue. This gate is non-negotiable for the pilot: it ensures that no ticket is mis-routed without a human catching it. Track every approval and correction in a simple log. The log feeds directly into the before/after comparison at the end of week 2. The agent does not make decisions about payouts, policy terms, or contract changes—those remain with licensed staff. The agent’s job is to get the ticket to the right person faster.

    Step 5: Measure the Before/After Baseline and Present Results

    Run the pilot for 5 business days in week 2. Collect data on: median cycle time from ticket creation to correct routing, routing accuracy (percentage of tickets sent to the right queue without human correction), and senior staff hours saved per week on routine triage. Compare these numbers against the baseline captured in step 1. A successful pilot shows a 40-60% reduction in cycle time and 85%+ routing accuracy. Present the before/after comparison to the business owner with the raw data and the approval log. The go/no-go decision is based on these numbers, not on impressions. If the metrics meet the threshold, the next step is scaling to additional departments or ticket categories.

  • UK SaaS Team Cuts Candidate Screening from 18 Days to 6 in a Four-Week AI Pilot

    Background: A 30-Person UK SaaS Team with a Screening Bottleneck

    This case study is a composite based on patterns observed across multiple engagements. We do not name real customers. The company, the metrics, and the timeline are drawn from a recurring profile: a 30-person B2B SaaS firm in the UK, mid-growth stage, running on a standard stack of Notion for documentation, a CRM for pipeline, and a helpdesk for support. The team had no dedicated AI function. The founder had read about LLMs and wanted to test whether one process could be automated without a six-month build. The engagement ran for four weeks, end to end, from process audit to measured baseline.

    The Challenge: 18-Day Screening Cycle and a Hiring Deadline

    The team was hiring for two roles simultaneously: a senior engineer and a customer success manager. The screening process was manual. A recruiter read each CV, wrote a summary in Notion, and flagged the candidate for the hiring manager. The average cycle time from application to first screening decision was 18 days. The error rate was not measured, but the hiring manager reported that roughly one in five candidates who passed screening were later found to be a poor fit. The pressure was operational: the founder needed to close both roles before the next funding round, and the manual process was the bottleneck. There was no compliance constraint, but the team wanted a clean, auditable trail of who approved each screening decision.

    Approach: Audit, Build, and a Human-in-the-Loop Gate

    The engagement started with a three-day process audit. The dedicated AI team mapped the screening workflow step by step, identified the two highest-impact automation points (CV extraction and screening summary), and selected candidate screening as the single pilot process. The build used Anthropic Claude API for the extraction and classification. The integration was read-write against Notion: the AI read the job description and the CV, wrote the screening summary back to the same Notion page, and tagged the candidate with a classification label. The human-in-the-loop step was a simple approve/edit/reject button on the Notion page. The multilingual coverage was built in from day one: the model handled CVs in English, French, and German without a separate translation step. The build took nine days. The remaining time was spent on the baseline measurement and the rollout to the two open roles.

    Outcome: 18 Days to 6 Days, 20% to 8% Error Rate

    The measured baseline showed a cycle time reduction from 18 days to 6 days for the screening step. The error rate, measured as the percentage of candidates who passed screening but were later rejected at interview, dropped from 20% to 8%. The human-in-the-loop step added 3 minutes per candidate, but the total time per candidate fell from 22 minutes to 9 minutes. The team screened 47 candidates in the four-week window, compared to 19 in the previous four weeks. The founder reported that the hiring manager could now review all screening decisions in a single 30-minute session per day, instead of spreading them across the week. The multilingual coverage meant the team could accept applications from candidates in France and Germany without a separate translation step, which the founder estimated saved roughly 4 hours per week.

    Lessons for Similar Teams

    • Start with one process, not a platform. The pilot succeeded because the scope was a single workflow with a clear input and output. Teams that try to automate three processes in four weeks end up with three half-built integrations and no clean baseline. – Measure the baseline before you build. The 18-day cycle time and 20% error rate were recorded in the first week. Without that number, the outcome would have been anecdotal. The baseline is the most valuable deliverable in the pilot. – Human-in-the-loop is not a compromise; it is the product. The approve/edit/reject gate is what made the hiring manager trust the output. Remove it, and the team reverts to manual screening within two weeks. – Multilingual coverage is a feature, not a nice-to-have. For a UK team hiring in a European market, the ability to screen CVs in French and German without a translation step is a direct operational gain. Build it in from day one. – The integration is the moat, not the model. The AI layer plugs into Notion through its API. If the team later switches to Confluence, the integration work is a day, not a rebuild. The model is swappable; the integration is the asset.

  • RAG Assistant vs Customer-Facing AI: Automating Reporting in UK Healthcare

    What Is Being Compared

    The two options under evaluation are a retrieval-augmented knowledge assistant (RAG assistant) built on LangChain and LangGraph that operates over the company’s internal documentation, CRM records, and ERP data, and a customer-facing AI assistant that handles ticket triage, first-response, and voice interactions with patients or clients. Both are deployed by a dedicated AI team with a 6-month timeline, integrating via custom REST APIs and webhooks into existing systems. The company is a 501-2000 employee healthcare and medtech firm in the UK, operating under HIPAA compliance requirements, with the specific need to automate monthly reporting and order and shipment status updates as part of scaling operations and supply chain without new hires. The RAG assistant is an internal tool; the customer-facing assistant is an external interface. This distinction drives every criterion that follows.

    Evaluation Criteria

    The evaluation uses seven criteria, each tied to the scenario dimensions:

    • HIPAA compliance and data residency: Can the system handle PHI without violating UK data protection rules? Does data stay on-prem?
    • Integration complexity: How many custom REST API and webhook integrations are required to connect to existing CRMs, ERPs, and helpdesks?
    • Cycle time reduction: Measured before/after baseline on monthly reporting and order status update turnaround.
    • Error rate: Transcription and data-entry error rates in the automated output versus manual processing.
    • Human-in-the-loop overhead: Time and headcount required for approval of outputs touching money, health data, or contracts.
    • Model-agnostic architecture: Ability to use OpenAI/Anthropic APIs for quality tasks and open-weight models on client hardware for regulated data.
    • Scalability without new hires: Can the system absorb 20-50% volume growth without additional FTEs?

    Side-by-Side Comparison

    Criterion RAG Knowledge Assistant Customer-Facing AI Assistant
    HIPAA compliance Open-weight models on client hardware; PHI tokenized before model access; BAA with vendor Cloud-hosted models typically cannot sign BAA; PHI exposure risk in ticket/voice channels
    Integration surface Custom REST APIs to ERP, CRM, document stores; webhooks for report triggers Helpdesk APIs, messaging platforms, voice gateways; fewer internal system touchpoints
    Cycle time (monthly report) 3-5 days manual → 4-8 hours with RAG draft + human approval Not applicable; does not generate internal reports
    Cycle time (order status) 5-10 min manual lookup → under 30 sec per order via API extraction 2-5 min per ticket with triage + first-response automation
    Error rate (data entry) 2-5% manual → under 0.5% with API-based extraction 1-3% on ticket classification; higher on free-text responses
    Human-in-the-loop Required for any output touching PHI, money, or contracts; 1-2 hr review per report Required for escalations and sensitive patient queries; 30-60 sec per ticket
    Scalability (20-50% volume) Absorbs via parallel API calls; no new hires needed Absorbs via queue management; may need 1-2 additional support FTEs at 50%+ growth

    Scenario-by-Scenario Verdict

    When the RAG assistant wins: The RAG assistant is the correct choice when the primary need is automating monthly reporting and order and shipment status updates from internal systems. It operates on the company’s own documentation, CRM, and ERP data, which is exactly where the cycle time and error rate pain points live. The HIPAA requirement forces open-weight models on client hardware, which the RAG architecture supports natively through LangGraph’s stateful orchestration: the model retrieves, drafts, and routes to a validation node where a human approves before the output reaches the ERP. The custom REST API and webhook integrations pull data directly from source systems, eliminating manual copy-paste. For a 501-2000 employee company scaling operations and supply chain without new hires, the RAG assistant reduces monthly reporting from 3-5 days to 4-8 hours and order status lookups from 5-10 minutes to under 30 seconds per order. The dedicated AI team ships a measured before/after baseline in the pilot phase, making the ROI case concrete.

    When the customer-facing assistant wins: The customer-facing assistant is the right choice when the bottleneck is patient or client interaction volume — ticket triage, first-response, and voice channels. It reduces time-to-first-response from 4-8 hours to under 5 minutes and handles 60-80% of routine queries without human intervention. However, it does not address the internal reporting and order status workflows that are the stated need in this scenario. It also introduces a different compliance surface: GDPR and the UK Data Protection Act 2018 for patient communications, plus voice-channel-specific requirements. For a company whose primary pain is back-office cycle time rather than customer interaction volume, the customer-facing assistant solves a different problem.

    Recommendation

    The RAG knowledge assistant is the correct option for this scenario. The stated need — automate monthly reporting and order and shipment status updates — is an internal operations problem, not a customer interaction problem. The HIPAA compliance requirement eliminates most cloud-hosted customer-facing assistant products because they cannot sign a BAA or guarantee UK data residency. The RAG architecture, built on LangChain and LangGraph, supports the model-agnostic approach: OpenAI or Anthropic APIs for high-quality summarization and classification tasks, and open-weight models (Llama 3 70B, Mistral 7B) on the client’s own hardware for any task touching PHI. The dedicated AI team follows a fixed-scope pilot on one reporting workflow, ships with a measured before/after baseline on cycle time and error rate, and rolls out to the order status workflow in months 4-6. The custom REST API and webhook integrations connect to the existing ERP, CRM, and logistics systems without replacing them. The result: monthly reporting cycle time drops from 3-5 days to 4-8 hours, order status turnaround drops from 5-10 minutes to under 30 seconds per order, and data-entry error rates fall from 2-5% to under 0.5%. No new hires are required to absorb 20-50% volume growth. The customer-facing assistant can be added in a second phase if patient interaction volume becomes the next bottleneck, but it is not the solution to the problem stated in this engagement.