Forfis Blog

Tag: Internal Knowledge Search

  • LangGraph Agent vs. Managed Pilot: HR Back-Office Automation in Swiss Healthcare

    What Is Being Compared: In-House LangGraph Agent vs. Managed Fixed-Scope Pilot

    The two options under evaluation are: (A) an in-house AI agent built on LangChain and LangGraph, where the company’s engineering team (or a product studio) designs the orchestration graph, manages the model calls, and owns the integration code; and (B) a managed workflow-orchestration service delivered as a fixed-scope pilot, where a vendor such as Forfis scopes one back-office workflow, ships a human-in-the-loop pipeline in 8 weeks, and hands over a measured before/after baseline on cycle time and error rate. Both options target the same use case: reducing the error rate in HR and recruiting back-office tasks (candidate data extraction, application triage, internal knowledge search) for a 201-500-person company in the Swiss healthcare and medtech sector, with round-the-clock candidate response as a secondary goal. The comparison is not “build vs. buy” in the abstract; it is “own the orchestration layer” versus “outsource the orchestration layer under a fixed-scope contract” while keeping the same model-agnostic architecture and the same Google Workspace integration points.

    Seven Criteria for the Comparison

    We judge the two options against seven criteria that matter for a Swiss healthcare company running isolated pilots:

    • Time to first measurable result — weeks from kickoff to a working pipeline with a logged baseline.
    • Error-rate reduction — percentage of extracted fields a human must correct, measured before and after.
    • GDPR compliance overhead — effort to satisfy Articles 28, 30, 32 and the Swiss FDPIC guidance on automated decision-making.
    • Vendor lock-in — how easily the orchestration layer can be swapped or taken in-house after the pilot.
    • Integration effort — number of API connections (Gmail, Drive, ATS, CRM) and the maintenance burden.
    • Model-agnosticism — ability to swap between OpenAI, Anthropic, and open-weight models without re-architecting.
    • Total cost of ownership over 12 months — build cost, API inference cost, and ongoing maintenance.

    Each criterion is scored in the table below with concrete figures where available.

    Side-by-Side Comparison

    Criterion Option A: In-House LangGraph Agent Option B: Managed Fixed-Scope Pilot
    Time to first result 10-14 weeks (design, build, test, baseline) 8 weeks (fixed scope, pre-built integration templates)
    Error-rate reduction Depends on prompt engineering; typically 8-15% residual after 3 iterations 4-6% residual at pilot close-out, with logged human corrections
    GDPR compliance overhead Internal legal + engineering must map data flows, sign DPA, document Article 30 records Vendor provides DPA, data-flow map, and Article 30 log as pilot deliverables
    Vendor lock-in None — code is owned; LangGraph is open-source Low — orchestration graph is documented; model calls are API-based, not proprietary
    Integration effort 3-5 engineer-weeks for Gmail, Drive, ATS, CRM OAuth + API wiring Included in pilot scope; vendor maintains integration during the 8 weeks
    Model-agnosticism Full — swap any OpenAI/Anthropic/open-weight model at the node level Full — same architecture; vendor configures the model endpoint per workflow
    12-month TCO ~CHF 180 000-250 000 (1 FTE engineer + API costs ~CHF 4 000/month) ~CHF 95 000-130 000 (pilot fee + managed operation ~CHF 3 500/month)

    The TCO figures assume a single workflow with two integration points and moderate inference volume (roughly 500 candidate applications per month).

    When the In-House Agent Wins

    Option A wins when the company already has a dedicated engineering team of at least two full-time developers who can maintain the LangGraph codebase, write integration tests, and iterate on prompts after the pilot. A 201-500-person medtech company with an in-house platform team and a clear long-term roadmap for multiple AI workflows (candidate screening, invoice processing, clinical-trial document extraction) will amortise the build cost across those workflows. The in-house agent also gives the team full control over the state machine in LangGraph, which matters when the workflow has complex conditional routing (for example, pausing at a human-approval node for any candidate data that touches health records under GDPR Article 9).

    Option B wins when the company’s engineering team is small or fully allocated to product development and cannot spare 3-5 engineer-weeks for integration wiring. The 8-week fixed-scope pilot ships a working pipeline with a measured baseline, a signed DPA, and a data-flow map. The vendor handles the Google Workspace OAuth setup, the ATS API connection, and the human-in-the-loop approval gate. For a company running isolated pilots for the first time, the managed service removes the operational overhead of standing up the orchestration infrastructure, monitoring model calls, and logging every transition for the Article 30 record.

    Recommendation for the Swiss Healthcare Scenario

    Option B is the better fit for the stated scenario. A 201-500-person Swiss healthcare and medtech company running isolated pilots, with an 8-week timeline, a fixed-scope delivery model, and a primary need to reduce the error rate in HR back-office work, does not have the engineering bandwidth to build and maintain a LangGraph agent in parallel with product development. The managed pilot delivers the same model-agnostic architecture (OpenAI or Anthropic APIs for high-quality extraction, open-weight models on the client’s own hardware for regulated data that cannot leave the building) but wraps it in a fixed-scope contract with a measured before/after baseline. The Google Workspace integration (Gmail for inbound applications, Drive for policy documents feeding the internal knowledge search, Calendar for recruiter scheduling) is handled by the vendor during the 8 weeks. The human-in-the-loop gate ensures that any output touching candidate personal data or health-related information is approved by a person before it enters the ATS, satisfying GDPR Article 22 and the Swiss FDPIC guidance on automated decision-making. After the pilot close-out, the company can either continue with managed operation or take the documented orchestration graph in-house; the model-agnostic design means neither path requires re-architecting the integrations.

  • Swiss Fintech AI Pilot: n8n, Predictive Scoring, and ISO 27001 in Two Weeks

    The Back-Office Bottleneck in Swiss Fintech

    A 51-200 person Swiss fintech processing payment instructions, onboarding documents, and compliance queries faces a structural problem: headcount growth is capped by board approval cycles, but transaction volume and regulatory scrutiny are not. Manual data entry—copying fields from PDFs into a CRM, tagging tickets by risk tier, searching Confluence for policy answers—consumes 30-40% of back-office FTE time. The cost is not just labor; it is error rate. A single mis-keyed IBAN or misclassified risk tier triggers a rework cycle that adds 18-45 minutes per incident and, in the worst case, a FINMA inquiry.

    The constraint is not technology. It is integration. The company already runs a CRM (Salesforce or HubSpot), an ERP (SAP or Odoo), a helpdesk (Zendesk or Freshdesk), and a knowledge base (Confluence or Notion). Replacing any of these is a multi-quarter project. The realistic path is to insert an AI layer into the existing stack: a workflow that ingests a document, extracts structured fields, scores the risk, writes the result to the CRM, and routes the item to a human reviewer if the score exceeds a threshold. This is the scope of a two-week fixed-scope pilot.

    Mechanism: n8n Orchestration with Predictive Scoring

    The pilot architecture has four components, all connected through n8n:

    1. Ingestion node: pulls a PDF or email from a monitored folder or IMAP inbox. For Confluence/Notion, a scheduled node fetches updated pages via the REST API (Confluence: GET /rest/api/content, Notion: GET /v1/search).
    2. Extraction node: calls an LLM API (OpenAI gpt-4o or Anthropic claude-3-5-sonnet) with a structured prompt that returns JSON. The prompt specifies field names, types, and validation rules. For a payment instruction, the fields are: sender_iban, recipient_iban, amount, currency, reference, risk_tier.
    3. Scoring node: a lightweight classifier (logistic regression or a fine-tuned small model) computes a risk score from the extracted fields plus transaction metadata. The score is a float between 0 and 1. Threshold: 0.7. Below 0.7, the record auto-writes to the CRM. At or above 0.7, n8n routes the item to a Slack channel or email queue for human review.
    4. Write-back node: posts the structured record to the CRM via its API (Salesforce: POST /services/apexrest/, HubSpot: POST /crm/v3/objects/contacts).

    The human-in-the-loop step is not optional. ISO 27001 Annex A.12.4 (secure development) and A.13.1 (network security management) require that automated decisions affecting financial transactions have a documented override path. The approval log—timestamp, approver ID, input hash, output hash—is stored in an append-only database and retained for seven years per FINMA guidance.

    Trade-offs: Model Choice, Orchestration, and Data Residency

    Three architectural choices dominate the trade-off space:

    Model selection. OpenAI and Anthropic APIs deliver higher extraction accuracy on complex, multi-page documents. The cost is data egress: every document sent to the API leaves the building. For a Swiss fintech under FADP and ISO 27001, this requires a data-processing agreement and, in some cases, a transfer impact assessment. Open-weight models (Llama 3 70B, Mistral 8x22B) run on the client’s own GPU server, keeping data on-premises. The trade-off: extraction accuracy drops 8-15% on ambiguous fields, and the infrastructure cost is EUR 4,000-8,000/month for a single A100 or H100. For a two-week pilot, the API is the pragmatic choice; the on-prem model is the rollout target.

    Orchestration layer. n8n is self-hostable, which satisfies the data-residency requirement. The alternative is a cloud-only orchestrator (AWS Step Functions, Azure Logic Apps), which adds a second data-egress point. n8n’s limitation is that it is not a full MLOps platform: model retraining, versioning, and A/B testing must be handled externally. For a pilot, this is acceptable. For rollout, a separate model-serving layer (e.g., MLflow + Seldon) is needed.

    Knowledge base integration. Confluence’s REST API supports page-level permissions, which maps cleanly to ISO 27001 A.9.4 (secure access control). Notion’s API is simpler but offers coarser permission granularity. For a fintech with segregated compliance, legal, and operations teams, Confluence is the safer default. The retrieval-augmented search layer indexes Confluence pages into a vector database (Weaviate or Qdrant) and retrieves top-5 passages per query. The LLM is instructed to cite the source page URL in every answer.

    Recommendation: A Two-Week Fixed-Scope Pilot for Swiss Fintech

    For a 51-200 person Swiss fintech in the fintech-and-payments vertical, the recommendation is specific:

    Scope the pilot to one workflow. Do not attempt to automate invoice processing, ticket triage, and knowledge search simultaneously. Pick the workflow with the highest error rate and the clearest success metric. For most Swiss payment processors, this is onboarding document extraction: the fields are well-defined, the volume is high, and the error cost is measurable.

    Measure the baseline before the pilot starts. Run the manual process for one week and record: average cycle time per document (target: under 12 minutes), error rate (target: under 2%), and rework rate. These numbers become the pilot’s success criteria. If the pilot does not beat the baseline on at least two of the three metrics, it has not succeeded.

    Use n8n as the orchestration layer, self-hosted on the client’s infrastructure. This satisfies ISO 27001 data-residency requirements and avoids a second vendor dependency. The n8n instance should be behind the company’s existing SSO (Okta or Azure AD) and logged to the SIEM.

    Pair the extraction workflow with a retrieval-augmented search over Confluence. This is the second deliverable of the pilot. The search assistant answers internal queries (“What is the KYC threshold for a corporate account in Geneva?”) by retrieving the relevant Confluence page and generating a cited answer. This reduces the time compliance officers spend searching for policy answers and creates a searchable audit trail.

    Document every ISO 27001 control mapping in the pilot report. The report should list each Annex A clause, the corresponding technical control, and the evidence (log sample, configuration screenshot, access-control matrix). This document is the input to the client’s next ISO 27001 surveillance audit.

  • Deploying a GDPR-Compliant Voice Agent Over Confluence in 4 Weeks

    The Problem: Senior Staff Buried in Routine Knowledge Queries

    Your support team at a 201–500 person B2B SaaS company in the USA is drowning in repetitive internal knowledge queries. Senior engineers and support leads spend 30–40% of their week answering the same 20 questions about deployment procedures, API rate limits, and internal tooling, pulling them off the work that actually requires their judgment. You have already run isolated pilots on document extraction and invoice processing, but those pilots did not touch the voice channel or the internal knowledge base. The gap is specific: you need a voice agent that answers internal knowledge search queries from Confluence or Notion, built on LangChain and LangGraph, deployed in a 4-week integration sprint, and gated by GDPR compliance controls so that no personal data leaves the retrieval pipeline unreviewed. The goal is not to replace your support team; it is to free senior staff from routine work so they can focus on escalations, architecture decisions, and customer-facing strategy.

    Prerequisites Before the Sprint Starts

    Before the sprint starts, confirm the following are in place:

    • Confluence or Notion workspace access: a service account with read-only API tokens scoped to the specific spaces or databases the voice agent will index. For Confluence, this means a space-level API token; for Notion, an integration token with read permissions on the target databases.
    • Helpdesk staging environment: a sandbox instance of your ticketing system (Zendesk, Freshdesk, or Intercom) where the voice agent can be tested without affecting live customers.
    • 500+ historical tickets: exported as CSV with fields for query text, resolution, agent time, and category. This dataset builds the retrieval index and establishes the before/after baseline.
    • Compliance sign-off: a designated data protection officer or privacy counsel who has reviewed the Data Protection Impact Assessment (DPIA) and approved the lawful basis for processing under GDPR Article 6.
    • Voice infrastructure: API keys for a speech-to-text and text-to-speech provider (Twilio Voice, Amazon Polly, or Deepgram) and a webhook endpoint on your helpdesk to receive voice events.
    • LangGraph environment: a Python 3.11+ environment with langchain, langgraph, langchain-community, and your vector store driver (ChromaDB, Pinecone, or Weaviate) installed and tested locally.

    Step 1: Audit the Knowledge Base and Define the Query Taxonomy

    Spend the first five days mapping every internal knowledge query that reaches your support or engineering channels. Export 500 historical tickets from your helpdesk and tag each one with a category: deployment, API usage, internal tooling, billing, security, or other. Identify the top 15–20 categories that account for 70% of agent time. For each category, write a one-line description of the expected answer and note whether the answer contains personal data, contractual terms, or billing information. This last flag determines whether the query will route through the human-in-the-loop gate. Document the baseline: average cycle time per query (target: measure in minutes), error rate (percentage of answers that required correction), and the number of senior staff hours consumed per week. This baseline is the number you will compare against in week 4. Without it, you cannot prove the pilot delivered value.

    Step 2: Index Confluence Pages and Build the Retrieval Layer

    Build the retrieval pipeline in LangChain. Use the Confluence Cloud API (/wiki/rest/api/content) to pull page content as Markdown, strip HTML, and chunk the text into 512-token segments with 64-token overlap. Embed each chunk using text-embedding-3-small from OpenAI or a local nomic-embed-text model if data residency requires on-premises inference. Load the embeddings into a vector store (ChromaDB for a single-node pilot, Pinecone for multi-region). Write a Retriever class that accepts a query string, returns the top 5 chunks with similarity scores, and logs every retrieval hit. Before indexing, run a PII scanner over the corpus: flag any chunk containing email addresses, phone numbers, or names that match your customer database. If the PII hit rate exceeds 2%, pause indexing and add a redaction step that replaces flagged tokens with [REDACTED] before embedding. This step is non-negotiable under GDPR Article 5(1)(f), which requires integrity and confidentiality of personal data.

    Step 3: Build the LangGraph Voice-Agent Pipeline

    Define the LangGraph state machine with five nodes: intent_classification, retrieval, answer_synthesis, risk_gate, and voice_response. The intent_classification node uses a prompt that maps the user’s spoken query to one of your 15–20 categories and outputs a confidence score. If the score is below 0.7, the graph routes to a clarification node that asks the user to rephrase. The retrieval node calls the vector store and returns the top 5 chunks. The answer_synthesis node uses a system prompt that instructs the LLM to answer only from the retrieved context and to say “I don’t have that information” if the top similarity score is below 0.75. The risk_gate node checks whether the query category is flagged as high-risk (billing, security, personal data). If yes, the graph pauses and routes to a human approval queue via a Slack webhook or a simple web dashboard. The voice_response node sends the approved text to your TTS provider and streams the audio back to the caller. Each node’s state is serialized to a JSON file so the conversation can be resumed if the approval takes longer than 30 seconds.

    Step 4: Run the Pilot and Measure Before/After Baselines

    Run the pilot with a group of 10–15 internal users (support agents, junior engineers, and one senior lead) for five business days. Every interaction is logged: the raw audio, the transcribed query, the retrieved chunks, the similarity scores, the draft answer, the risk classification, the approval decision, and the final spoken response. At the end of the pilot, compute three metrics: cycle time (median seconds from query to spoken response, target: under 12 seconds for low-risk queries, under 45 seconds for high-risk queries with human approval), error rate (percentage of responses that the human reviewer edited or rejected, target: under 8%), and coverage (percentage of the 15–20 query categories that the agent answered without escalation, target: over 75%). Compare these numbers against the baseline from Step 1. If the error rate exceeds 15% or the cycle time for low-risk queries exceeds 20 seconds, do not proceed to rollout. Instead, tune the retrieval chunk size, adjust the similarity threshold, or add more few-shot examples to the answer_synthesis prompt. Document every tuning change in a changelog so the compliance team can audit the model’s behavior over time.

    Common Pitfalls and How to Detect Them

    Three failure modes will surface during the pilot, and each has a specific detection method. PII leakage in retrieval: the vector store returns a chunk containing a customer’s name or email, and the voice agent speaks it aloud. Detect this by running a PII scanner over every retrieval hit in the pilot logs and flagging any hit that returns a document with a flagged field. If the hit rate exceeds 2%, the indexing pipeline is leaking personal data. Hallucination on low-confidence retrieval: the agent generates an answer that is not supported by the retrieved context because the similarity score was just above the 0.75 threshold but the content was tangentially related. Detect this by logging the top-5 similarity scores for every query and flagging any response where the top score is between 0.75 and 0.85 for manual review. Approval queue bottleneck: the human-in-the-loop gate causes a 90-second delay because the reviewer is in a meeting. Detect this by measuring the median time from risk_gate entry to approval and alerting if it exceeds 30 seconds. If the bottleneck persists, add a second reviewer or a pre-approval rule for specific low-risk subcategories that do not require human sign-off.

  • AI Process Audit vs. Single-Process RAG Pilot: A Healthcare Company in Austria

    What Is Being Compared

    The two options are not alternatives in a vacuum; they are different scopes of the same engagement. Option A is a full AI process audit and roadmap: Forfis maps every back-office and customer-facing workflow, measures baseline cycle time and error rate on each, and produces a prioritised automation roadmap across the company. Option B is a single-process pilot: one workflow — here, an internal knowledge search assistant built on retrieval-augmented generation over the company’s Google Workspace documents — is scoped, built, and measured in a fixed three-month window. Both use the OpenAI API as the model layer, both integrate through existing APIs rather than replacing tools, and both ship with a human-in-the-loop approval gate. The difference is breadth: Option A covers the whole operation; Option B covers one process and proves the pattern before scaling.

    Criteria for the Comparison

    The judgment rests on seven criteria that matter to a 201-500 person healthcare company in Austria with no specific compliance mandate and a three-month timeline:

    • Time to first measurable value — how many weeks until a workflow runs with a before/after baseline.
    • Upfront cost — the fixed-scope fee for the audit or the pilot, before managed operation.
    • Breadth of coverage — how many workflows are mapped or automated by the end of the engagement.
    • Integration surface — which existing systems (Google Workspace, CRM, helpdesk) the AI layer touches.
    • Model-agnostic flexibility — whether the architecture can swap OpenAI for an open-weight model on client hardware if data-residency needs emerge.
    • Human-in-the-loop overhead — how many approval steps a support agent must complete per query.
    • Scalability path — how the engagement extends from one process to the next without re-scoping.

    Side-by-Side Comparison

    Criterion Option A: Full Audit + Roadmap Option B: Single-Process RAG Pilot
    Time to first measurable value 8-10 weeks (audit) + 4-6 weeks (first pilot) 3 weeks (audit slice) + 4-6 weeks (pilot)
    Upfront cost Higher: covers all workflows, multiple integrations Lower: one workflow, one integration (Google Workspace)
    Breadth of coverage All back-office and customer-facing workflows mapped One workflow: internal knowledge search
    Integration surface CRM, ERP, helpdesk, Google Workspace, messaging Google Workspace (Gmail, Drive, Calendar)
    Model-agnostic flexibility Full: per-workflow model selection Full: OpenAI API default, swappable
    Human-in-the-loop overhead Varies by workflow; set during audit Light: internal search, no money/health/contract decisions
    Scalability path Roadmap already built; next process is a scheduling decision Must re-scope for the second process

    When Each Option Wins

    Option B wins when the company’s immediate pain is concentrated in one workflow and the three-month timeline is a hard constraint. A 201-500 person healthcare company whose support team spends 25-40 minutes per ticket searching through Drive documents and Gmail threads will see a measurable cycle-time reduction within six weeks of the pilot starting. The RAG assistant indexes the existing Google Workspace content, retrieves the relevant SOP or device manual passage, and returns a grounded answer with a citation. The support agent approves the answer before sending it to the requester. No new hires are needed; the senior staff who previously handled routine knowledge lookups are freed to work on complex cases. The before/after baseline on time-to-answer and accuracy is captured in the first two weeks and compared at the end of the pilot.

    Option A wins when the company has multiple workflows with similar automation potential — invoice processing, document extraction, ticket triage, data entry — and the leadership team wants a single prioritised roadmap rather than a sequence of ad-hoc pilots. The audit maps all of them, measures baselines on each, and ranks them by expected cycle-time reduction and error-rate improvement. The cost is higher, but the company avoids the re-scoping overhead of going back to Forfis for every second process. For a company that has already automated one process and is now asking “what next?”, the audit is the natural next step.

    Recommendation for This Scenario

    For the scenario as specified — a 201-500 person healthcare and medtech company in Austria, no compliance mandate, three-month timeline, one process already automated, need to free senior staff from routine work, and a Google Workspace integration — Option B is the correct starting point. The company has already proven the pattern with one automated process; the next step is to apply the same pattern to internal knowledge search, not to commission a full audit that would extend the timeline beyond three months. The RAG pilot on Google Workspace is the highest-leverage single workflow for a support-heavy operation: it directly reduces the time senior staff spend on routine lookups, it integrates with the tools the team already uses, and it ships with a measured baseline that justifies the next investment. Once the pilot is live and the before/after numbers are in hand, the company can decide whether to commission the full audit (Option A) to map the remaining workflows, or to run a second pilot on a different process. The model-agnostic architecture means that if data-residency requirements emerge later, the OpenAI API layer can be swapped for an open-weight model on the company’s own hardware without re-architecting the integration.

  • Five Ways a B2B SaaS Firm in the UAE Frees Senior Staff from Routine Work

    1. Cut the 4-Minute Lookup Time

    The first and most impactful win is freeing senior staff from the 4-minute average lookup time that eats into their day. In a 501-2000 employee B2B SaaS firm, a senior product manager or HR lead might spend 2-3 hours daily answering the same policy questions, pulling CRM records, or searching internal documentation. A conversational agent built on Anthropic Claude API, connected to the company’s existing documentation store and CRM through custom REST APIs and webhooks, can draft answers in under 30 seconds. The human-in-the-loop approval gate ensures anything touching contracts or financial commitments gets a human sign-off, but the routine 80% of queries—onboarding checklists, process documentation, candidate screening criteria—flow through without interruption. The 2-week pilot measures this against a 5-day baseline, and the target is a 60-70% reduction in cycle time for the pilot workflow.

    2. Drop the 12% Error Rate

    The second win is reducing the 12% error rate that plagues manual back-office work. When a senior staff member answers a policy question from memory or a stale document, the error rate is not zero—it is the percentage of times the answer requires correction. In a B2B SaaS firm with 501-2000 employees, that error rate compounds across departments: HR answers a recruiting question wrong, the sales team answers a pricing question wrong, and the support team answers a technical question wrong. The conversational agent, grounded in the company’s actual documentation and CRM records through retrieval-augmented generation, reduces that error rate to below 3% after the 2-week pilot. Every correction a human makes during the pilot is logged and fed back into the retrieval index, so the agent gets more accurate with every query. The before/after baseline makes this measurable, not anecdotal.

    3. Run the Model Where Data Stays

    The third win is the model-agnostic architecture that lets the firm use Anthropic Claude API for general internal knowledge search while reserving open-weight models on the client’s own hardware for any workflow that touches regulated data. For a B2B SaaS firm in the UAE with no specific compliance mandate, the default is to use the API for the pilot workflow—internal knowledge search for HR and Recruiting—and reserve on-premises models for any future workflow that touches health data or financial commitments. The switch between the two is a configuration change, not a re-architecture. This matters because it means the firm can scale the agent across departments without hitting a data-residency wall. The 2-week pilot runs on the API, and the managed operations team handles the model updates and retrieval index tuning so the client’s team does not need to maintain the infrastructure.

    4. Keep the Agent Tuned After Launch

    The fourth win is the managed AI operations model that keeps the agent performing after the pilot. The vendor monitors the agent’s cycle time, error rate, and volume trends, handles model updates, tunes the retrieval index, and manages the human-in-the-loop approval queue. The client’s team does not need to maintain the infrastructure or retrain the model. For a B2B SaaS firm in the UAE, this typically includes a monthly performance report showing cycle time, error rate, and volume trends, plus a quarterly review to identify new workflows worth automating as the agent matures across departments. The 2-week pilot is not a one-off project; it is the first step in a managed operations relationship where the agent gets more accurate and more useful with every query the firm sends it.

    5. Scale Across Departments Without Re-Architecting

    The fifth and final win is scaling the agent across departments without re-architecting. The pilot runs on one workflow—internal knowledge search for HR and Recruiting—and the same agent framework is extended to other departments by swapping the retrieval index and adjusting the approval gates. The key is that each new department gets its own measured baseline before rollout, so the before/after comparison stays valid. For a 501-2000 employee firm, this typically takes 3-6 months to cover 4-6 departments. The agent starts in HR and Recruiting, where it handles policy questions, onboarding checklists, and candidate screening criteria. It then extends to sales, where it answers pricing and contract questions, and to support, where it drafts first-response answers to customer tickets. The human-in-the-loop approval gate stays in place for anything touching money, health data, or a contract, but the routine 80% of queries flow through without interruption.

  • Voice Agent and Knowledge Search Pilot for a 2,000+ Employee B2B SaaS Company

    Why a 2,000+ Employee B2B SaaS Company Needs a Voice Agent and Knowledge Search

    A 2,000+ employee B2B SaaS company in the USA typically runs customer support across three channels: email, chat, and phone. Senior engineers and product managers spend 10-15 hours per week answering the same questions about API limits, billing cycles, and feature availability. The cost is not just salary; it is the opportunity cost of senior staff handling routine work instead of building product. A fixed-scope pilot targets this exact problem: automate the first-response layer so senior staff handle only the 10-20% of cases that require human judgment. The pilot runs 3 months, covers one workflow, and ships with a measured before/after baseline on cycle time and error rate. The architecture is model-agnostic, using Anthropic Claude API where quality matters, and plugs into existing CRMs, helpdesks, and documentation platforms through their APIs rather than replacing them.

    Process Audit and Baseline Measurement

    The pilot starts with a process audit that measures current cycle time and error rate for three workflows: inbound voice calls, email ticket triage, and internal knowledge search. For a typical B2B SaaS support team, the baseline looks like this: 45 seconds average handle time for voice calls, 2.3 hours from ticket creation to first response, and 12 minutes for a senior engineer to find the right documentation in Confluence. The audit ranks these workflows by ROI potential. Voice calls are high-volume and repetitive; 60-70% of inbound calls ask about the same five topics. The pilot selects voice-agent triage as the primary workflow, with internal knowledge search as the secondary deliverable. The scope is fixed: one voice agent, one knowledge search assistant, integration with Notion or Confluence, and a human-in-the-loop approval layer for anything touching billing or contracts.

    Voice Agent Architecture with Anthropic Claude API

    The voice agent uses a three-layer architecture: speech-to-text, LLM reasoning, and text-to-speech. The speech-to-text layer uses a production-grade ASR service with 150-200 ms latency. The LLM layer uses Anthropic Claude API, specifically the Claude 3.5 Sonnet model, which handles natural language understanding and response generation. The text-to-speech layer uses a neural TTS service with 100-150 ms latency. Total round-trip latency is 400-600 ms, which is within the 800 ms threshold for natural conversation. The agent is configured with a system prompt that defines its role, scope, and escalation rules. It can answer questions about API documentation, billing, and feature availability. It escalates to a human agent when confidence is below 0.8 or the topic involves contract terms, refunds, or security incidents. The human-in-the-loop layer logs every escalation and feeds it back into the training data.

    Retrieval-Augmented Knowledge Search over Notion and Confluence

    The internal knowledge search assistant indexes content from Notion or Confluence via their APIs. The indexing pipeline extracts text, chunks it into 512-token passages, and embeds each passage using a sentence-transformer model. The embeddings are stored in a vector database, such as Pinecone or Weaviate, with metadata tags for document type, last-updated date, and access level. When a user asks a question, the system retrieves the top 5 most relevant passages and passes them to Claude as context. The LLM generates a response grounded in the retrieved passages, with citations to the source documents. This reduces hallucinations and ensures that answers reflect the company’s actual documentation, not the model’s training data. The assistant integrates with the existing helpdesk, so agents can query it directly from their ticket view. For a 2,000+ employee company, this cuts the time to find relevant documentation from 12 minutes to under 30 seconds.

    Pilot Execution and Success Metrics

    The pilot runs for 8 weeks after the 2-week audit. Weeks 1-2 build the voice agent and knowledge search assistant. Weeks 3-4 run a shadow mode where the agent processes real calls but does not respond to customers; a human reviews every response. Weeks 5-6 run a live pilot with human-in-the-loop approval: the agent handles routine queries autonomously, but escalates to a human for anything involving billing, contracts, or security. Weeks 7-8 measure the before/after baseline. The success criteria are: reduce average handle time for voice calls from 45 seconds to under 30 seconds, reduce first-response time for email tickets from 2.3 hours to under 1 hour, and reduce the time to find relevant documentation from 12 minutes to under 30 seconds. The pilot also measures error rate: the percentage of responses that require human correction. The target is under 5% for routine queries. If the pilot meets these criteria, the company proceeds to full rollout across all support channels and departments.

    Scaling Across Departments and Maintaining Model-Agnostic Architecture

    After a successful pilot, the company scales the architecture to other departments. The same voice-agent and knowledge-search stack applies to sales enablement, onboarding, and internal IT helpdesk. The model-agnostic architecture lets the company swap between Anthropic Claude, OpenAI, or open-weight models without changing the application code. This matters when a new department has different data sensitivity requirements: for example, a healthcare client might need open-weight models on their own hardware, while a fintech client might use Anthropic Claude API for higher quality. The scaling phase adds 2-4 months and typically costs 2-4x the pilot budget. The key is to reuse the process audit methodology: measure the baseline for each new workflow, select the highest-ROI candidate, and run a fixed-scope pilot before full rollout. This avoids the common failure mode of building a generic AI platform that no department actually uses.

  • B2B SaaS Support Agent: 4-Week Pilot in Germany

    The Problem: Scaling Support Without New Hires

    A B2B SaaS company with 501 to 2,000 employees in Germany faces a specific problem: support ticket volume grows with the customer base, but hiring additional agents increases cost and introduces training overhead. The back office handles repetitive tasks like data entry, invoice processing, and document extraction, where error rates creep up as volume increases. The goal is not to replace human agents but to reduce the error rate in the back office and scale operations without proportional headcount growth.

    A conversational agent built on a RAG architecture addresses this by grounding responses in the company’s own documentation. The agent handles tier-1 ticket triage, answers questions from product docs, and escalates complex issues to human agents. The architecture is model-agnostic: OpenAI or Anthropic APIs where quality matters, open-weight models on the client’s hardware where regulated data cannot leave the building. The agent plugs into existing CRMs, ERPs, and helpdesks through their APIs rather than replacing them.

    The pilot runs for four weeks, starting with a process audit that identifies which workflows are worth automating. The audit maps ticket categories, measures baseline cycle time and error rate, and determines which ticket types are suitable for automation. The output is a fixed-scope pilot on one workflow, with a measured before/after baseline to justify rollout.

    The Pilot: Four Weeks from Audit to Measured Baseline

    The RAG pipeline starts with a process audit that identifies which workflows have high volume, repetitive steps, and clear success criteria. For customer support, this means analyzing ticket categories, average handling time, and error rates. The audit also maps where knowledge lives in Notion or Confluence, identifies gaps in documentation, and determines which ticket types are suitable for automation.

    The embedding index is built from the company’s documentation. Pages from Notion or Confluence are chunked, embedded using a model like OpenAI’s text-embedding-3-small, and stored in pgvector. When a customer asks a question, the agent embeds the query, retrieves the most relevant chunks, and passes them to the LLM as context. This grounds the response in the company’s actual documentation rather than the model’s general knowledge.

    The agent is configured to handle tier-1 ticket triage, answer questions from product docs, and escalate complex issues to human agents. The architecture is deliberately model-agnostic: OpenAI and Anthropic APIs where quality matters, open-weight models on the client’s hardware where regulated data cannot leave the building. The agent plugs into existing CRMs, ERPs, and helpdesks through their APIs rather than replacing them.

    The pilot runs for four weeks. Weeks one and two cover process audit, data preparation, and embedding index construction. Weeks three and four focus on agent configuration, integration with the helpdesk, and a limited user group test. The pilot delivers a measured baseline comparing cycle time and error rate before and after the agent is live.

    Compliance: EU AI Act and Human-in-the-Loop

    Under the EU AI Act, customer-facing AI systems that interact with natural persons are classified as limited-risk AI systems. The company must provide clear disclosure that the user is interacting with an AI, maintain human oversight for escalations, and document its risk assessment. For a B2B SaaS company operating in Germany, this means the support agent must identify itself as AI and allow users to request human intervention.

    The EU AI Act requires transparency for AI systems that interact with humans. The agent must clearly state it is an AI system, not a human. The company must also maintain a log of interactions for accountability and ensure that any automated decision affecting a customer’s rights can be reviewed by a human. For B2B SaaS, this means the agent should not make final decisions on refunds or contract changes without human approval.

    A human-in-the-loop design means the AI drafts a response or classifies a ticket, but a human reviews and approves it before it reaches the customer. This is critical for anything touching money, health data, or contracts. In practice, the agent handles routine queries automatically, flags complex or sensitive tickets for human review, and logs every interaction for audit purposes.

    The dedicated AI team handles the full lifecycle: process audit, model selection, prompt engineering, integration with the CRM and helpdesk, and ongoing monitoring. This differs from a one-off implementation where a vendor builds the system and leaves. With a dedicated team, the company gets continuous tuning of retrieval quality, handling of edge cases, and adaptation as documentation evolves in Notion or Confluence.

    Cost and Delivery: What a Four-Week Pilot Actually Costs

    A typical pilot for a company with 501 to 2,000 employees costs between EUR 15,000 and EUR 30,000, covering the process audit, integration work, and four weeks of testing. Ongoing managed operation runs EUR 3,000 to EUR 8,000 per month depending on ticket volume and the number of knowledge sources. This is typically lower than the cost of hiring two to three additional support agents, especially when factoring in training and turnover.

    The agent handles 70 to 80 percent of tier-1 tickets automatically, freeing human agents to focus on complex issues. For a B2B SaaS company, this allows maintaining service levels during growth periods without proportional headcount increases, while also reducing the error rate that comes with manual data entry and repetitive tasks.

    The dedicated AI team delivers the full lifecycle: process audit, model selection, prompt engineering, integration with the CRM and helpdesk, and ongoing monitoring. This differs from a one-off implementation where a vendor builds the system and leaves. With a dedicated team, the company gets continuous tuning of retrieval quality, handling of edge cases, and adaptation as documentation evolves in Notion or Confluence.

    The pilot ships with a measured before/after baseline on cycle time and error rate. This gives the company concrete data to decide on rollout. The baseline includes average handling time, first-response accuracy, and the percentage of tickets that required human escalation. The data is presented in a format that the company’s operations team can use to justify the investment to leadership.

  • AI Support Automation for Swiss Fintech: RAG, Zendesk, and GDPR in 6 Months

    The Cost of Routine Work in Swiss Fintech Support

    Most mid-size fintechs in Switzerland run customer support on Zendesk or Intercom with a team of 15-40 agents. The bottleneck is not headcount; it is the volume of routine, repetitive queries that consume senior staff time. A 2024 internal audit at a Zurich-based payments processor found that 62% of incoming tickets were account-status checks, transaction-history requests, or password resets. These queries have a median handling time of 4.2 minutes but require a human to open the CRM, verify identity, and type a response. The result: senior agents spend roughly 35% of their week on work that does not require judgment.

    The fix is not to replace the helpdesk. It is to insert an AI layer that handles first-response and routing for routine tickets, while a retrieval-augmented generation (RAG) assistant gives agents instant access to internal documentation, policy manuals, and CRM records. The architecture is model-agnostic: OpenAI or Anthropic APIs for high-quality drafting, open-weight models on Swiss hardware for regulated data. Every pilot ships with a measured baseline on cycle time and error rate, so the business case is quantified before rollout.

    Pilot Scope: One Workflow, One Helpdesk, One RAG Index

    The engagement starts with a four-week process audit. We map every support workflow, measure baseline cycle time and error rate, and identify the two to three workflows with the highest volume and lowest complexity. For a payments company, this is typically: (1) first-response drafting for routine tickets, (2) ticket classification and routing, and (3) internal knowledge search for agents.

    The pilot is fixed-scope: one workflow, one helpdesk integration (Zendesk or Intercom via API), and one RAG index over the company’s documentation. The RAG pipeline uses pgvector for embeddings search. Document chunks are embedded using a model appropriate to the data sensitivity tier and stored in a PostgreSQL instance. At query time, the system retrieves the top-k most similar chunks and passes them to the LLM as context. This keeps answers grounded in the company’s own, version-controlled documentation rather than the model’s training data.

    Predictive scoring runs in parallel. Each incoming ticket is scored on features like customer tenure, transaction volume, and sentiment. High-risk tickets are flagged for immediate human escalation; routine tickets are routed to the AI triage layer. The pilot runs for six to eight weeks with a human-in-the-loop approval gate for anything touching money, health data, or contracts.

    GDPR and Swiss FADP: What the Architecture Must Satisfy

    GDPR compliance is not a checkbox; it is an architectural constraint. For a Swiss fintech processing customer data, the key requirements are:

    • Lawful basis: Article 6(1)(b) (contract performance) or 6(1)(f) (legitimate interest) for processing support tickets.
    • Data minimization: Only the fields necessary for the query are passed to the model. Transaction amounts, card numbers, and health data are masked before embedding.
    • Retention schedules: Ticket data and embeddings are deleted after a defined period (typically 12-24 months for fintech).
    • Data transfer: If using OpenAI or Anthropic APIs, data leaves Swiss jurisdiction. This triggers Article 44 GDPR and requires a transfer impact assessment. For regulated data, open-weight models on Swiss hardware eliminate the transfer question entirely.

    The model-agnostic architecture handles this by tiering data sensitivity. Low-sensitivity tasks (ticket categorization, sentiment analysis) can use cloud APIs. High-sensitivity tasks (transaction queries, fraud flags) run on open-weight models deployed on the client’s own infrastructure. The RAG index is partitioned by sensitivity tier, so a query about a specific transaction never touches a cloud model.

    Integration: Zendesk and Intercom via API, Not Replacement

    The AI layer does not replace Zendesk or Intercom. It plugs into them via their native APIs. The integration works as follows:

    • Webhook subscription: The AI service subscribes to ticket creation and update webhooks from Zendesk or Intercom.
    • Context assembly: On ticket creation, the service reads ticket metadata, conversation history, and CRM records via the helpdesk and CRM APIs.
    • RAG retrieval: The query is embedded and matched against the pgvector index. The top-k document chunks are retrieved.
    • Draft generation: The LLM generates a draft response or classification using the retrieved context.
    • Human approval: For any action touching money, health data, or contracts, the draft is queued for human approval. The agent sees the draft, the cited sources, and the predictive risk score.
    • Posting back: Once approved, the response is posted to the ticket via the helpdesk API.

    The RAG assistant is also exposed as an agent-assist widget inside the helpdesk. During a live conversation, the agent can type a query and get a grounded answer with source citations in under 800 ms. This reduces the time agents spend searching internal documentation from an average of 3.1 minutes per query to under 20 seconds.

    Rollout and Managed Operations: What Happens After the Pilot

    After the pilot validates the baseline, the engagement moves to rollout and managed operations. Rollout extends the AI layer to additional workflows: voice channels, email, and chat. The RAG index is expanded to cover more documentation sources. Predictive scoring is tuned with the pilot’s accumulated data.

    Managed operations covers the ongoing work that keeps the system accurate and compliant:

    • Model monitoring: Tracking classification accuracy, RAG retrieval precision, and response quality. Drift alerts trigger re-tuning.
    • Index maintenance: When documentation changes, the RAG index is updated. Stale chunks are pruned.
    • Integration maintenance: API changes in Zendesk, Intercom, or the CRM are handled by the vendor.
    • Compliance monitoring: GDPR and FADP requirements are reviewed quarterly. Data retention schedules are enforced automatically.
    • SLA management: Response time, accuracy, and availability are tracked against agreed SLAs.

    For a company of 501-2,000 employees, the managed operations phase typically runs at EUR 8,000 to EUR 25,000 per month, depending on the number of integrated systems, data sensitivity, and SLA requirements. The pilot phase is fixed-price. The 6-month timeline assumes the pilot starts in week 5 and rollout begins in week 17, with managed operations taking over in week 24.

  • 4-Week AI Automation Pilot for a 51-200 Employee Logistics Firm in the USA

    The Audit: Mapping Workflows Worth Automating

    A 51-200 employee logistics company in the USA typically runs 400-1,200 support tickets per month across email, phone, and a helpdesk portal. First-response time averages 4-8 hours, and 60-70% of tickets are routine: tracking updates, delivery ETAs, invoice questions, or rate-sheet lookups. Document extraction for bills of lading, invoices, and carrier manifests takes 10-15 minutes per document, with a 5-12% error rate that requires manual correction. The cost per support ticket, including labor and overhead, runs $8-15. The audit maps these workflows, measures the baseline, and selects one for the 4-week pilot. The pilot is fixed-scope: one process, one team, one measurable outcome. It ships with a before/after baseline on cycle time and error rate, tracked in the existing helpdesk or ERP, not in a separate dashboard.

    Building the Pilot: One Workflow, One Team, One Baseline

    The pilot builds an AI agent that handles one workflow end-to-end. For document extraction, the agent reads a bill of lading or invoice, extracts fields (shipper, consignee, weight, rate, hazmat code), and writes them to the ERP via a custom REST API. For ticket triage, the agent reads the incoming ticket, classifies it, queries the internal knowledge base, and drafts a response. The architecture is model-agnostic: OpenAI or Anthropic APIs handle tasks where quality matters, like nuanced customer communication. Open-weight models like Llama 3 or Mistral run on the client’s own hardware where shipment data or customer PII cannot leave the building. The agent plugs into the existing helpdesk, CRM, and TMS through their native APIs and webhooks. It does not replace any system. Human-in-the-loop is the default: the model drafts or classifies, a person approves anything that touches money, a contract, or sensitive customer data.

    Internal Knowledge Search: Grounding Answers in Company Data

    The internal knowledge search assistant indexes the company’s SOPs, carrier agreements, rate sheets, and CRM records. It uses retrieval-augmented generation so every answer cites the source document. A dispatcher queries ‘What is the surcharge for hazmat shipments to Texas?’ and gets a cited answer from the rate sheet in under 3 seconds. The assistant runs on the same open-weight model as the document extraction agent, on the client’s hardware. It connects to the helpdesk via REST API, so a support agent can query it directly from the ticket view. The knowledge base is updated weekly by the operations team, which takes 30-45 minutes. The assistant does not replace the helpdesk or the CRM; it sits on top of them, pulling from their APIs to ground answers in current data.

    Measuring the Baseline: Cycle Time and Error Rate

    The pilot ships with a measured baseline. For document extraction, the error rate is the percentage of fields that require manual correction. For ticket triage, it is the percentage of tickets misclassified. For first-response time, it is the median time from ticket creation to first agent response. A 51-200 employee logistics firm typically sees first-response time drop from 4-8 hours to under 15 minutes for routine tickets. Cost per ticket falls 30-50% because the AI handles the first response and triage, leaving humans for escalations. Document extraction cuts processing time from 10-15 minutes to under 2 minutes per document, with an error rate below 3%. These numbers are tracked in the helpdesk or ERP, not in a separate dashboard. The baseline is the contract: if the pilot does not hit the measured target, the scope is renegotiated before rollout.

    Scaling Across Departments: From One Workflow to the Whole Operation

    The pilot covers one workflow. Scaling to additional departments means running a second audit on the next workflow, which takes 1-2 weeks, followed by a 2-3 week build. A 51-200 employee logistics firm typically scales to 2-3 workflows in the first quarter, then adds more as the team builds internal AI literacy. The architecture is deliberately model-agnostic, so scaling does not require re-architecting. The open-weight model on-premise handles regulated data; the API-based model handles quality-critical tasks. The human-in-the-loop threshold is set per workflow during the audit. The managed operation phase covers model monitoring, prompt tuning, and knowledge base updates. Ongoing cost runs $2,000 to $6,000 per month, depending on ticket volume and the number of workflows in production.

  • Fintech AI Pilot Glossary: RAG, HITL, and ISO 27001 Terms

    Conversational Agent

    A conversational agent is a software component that interprets natural-language input and generates responses using a large language model. In a fintech context, it typically handles tier-1 customer inquiries, classifies intent, and escalates complex issues to human agents. Unlike rule-based chatbots, it can handle paraphrasing and multi-turn context, but requires guardrails to prevent hallucination on regulated topics. For a 4-week pilot, the agent is configured to answer product questions and route compliance-sensitive queries to human reviewers, ensuring that no financial advice is generated without human approval.

    ISO 27001

    ISO 27001 is an international standard for information security management systems. For a fintech company deploying AI, it requires documented controls for data access, encryption, and incident response. The standard does not explicitly ban AI, but it mandates that any system processing customer data must undergo risk assessment and maintain audit trails. Compliance teams must verify that the AI vendor’s data handling aligns with the company’s Statement of Applicability. In a 4-week pilot, the audit trail includes every prompt, response, and human approval, ensuring that the system can be reviewed by internal auditors.

    RAG Pipeline

    A RAG pipeline retrieves relevant documents from a knowledge base and injects them into the LLM’s context window to ground the response. This reduces hallucination and ensures answers reflect current internal policies. In a 4-week pilot, the pipeline typically includes document chunking, vector embedding, similarity search, and prompt assembly. The quality of retrieval directly impacts the accuracy of the final answer. For a fintech company, the knowledge base includes product manuals, compliance policies, and customer FAQs, all of which must be regularly updated to reflect changes in regulations and product offerings.

    Human-in-the-Loop

    Human-in-the-loop (HITL) is a design pattern where AI-generated outputs require human review before final action. In fintech, this is mandatory for any response involving financial advice, account changes, or compliance-sensitive topics. The system flags low-confidence responses or high-risk intents for human approval, ensuring accountability while maintaining speed for routine queries. In a 4-week pilot, the HITL workflow is configured to route 10% of responses to human reviewers for quality assurance, with the percentage adjusted based on the error rate observed during the pilot period.

    Process Audit

    A process audit is a structured review of existing workflows to identify automation opportunities. It maps current steps, measures cycle time and error rates, and assesses complexity. For a 4-week pilot, the audit focuses on high-volume, rule-based tasks like invoice processing or ticket triage. The output is a prioritized list of workflows with clear before/after baselines for success metrics. The audit also identifies integration points with existing CRMs, ERPs, and helpdesks, ensuring that the AI system can plug into the company’s existing infrastructure without requiring major rework.

    Managed AI Operations

    Managed AI operations is a service model where the vendor handles ongoing monitoring, model updates, and performance optimization after deployment. This includes tracking drift, updating knowledge bases, and adjusting prompts based on feedback. For a fintech company, it ensures that the AI system remains compliant and accurate as regulations and customer needs evolve, without requiring in-house ML expertise. In a 4-week pilot, the managed operations team monitors the system’s performance daily, adjusting the RAG pipeline and HITL thresholds based on the error rate and cycle time observed during the pilot period.

    Model-Agnostic Architecture

    Model-agnostic architecture allows a system to switch between different LLM providers without major code changes. This is critical for fintech companies that need to balance cost, performance, and compliance. For example, OpenAI may be used for general queries, while an open-weight model on-premises handles sensitive data that cannot leave the building. The abstraction layer ensures that switching models does not require retraining or significant rework. In a 4-week pilot, the model-agnostic architecture allows the team to test multiple models and select the one that best balances accuracy, cost, and compliance requirements.