Replace traditional form intakes with a conversational AI flow that understands context, asks follow-up questions at the right moment, and delivers structured data for your EHR, CRM, HRIS or case management system. For healthcare, legal, HR, insurers, government and B2B sales. Not a standalone chatbot experiment, but a defined intake layer, in your brand, with GDPR, NEN 7510 and the AI Act in order from the start.
Most intake flows in Dutch organisations still look the same: a long questionnaire, locked into dropdowns and mandatory fields, forcing the user to squeeze into the categorical logic of the system behind it. A patient with a complaint, a client registering a case, a new employee, all passing through the same rigid funnel. The result: half-completed forms, misclassifications, a second-line colleague who still has to call, and data that ends up in the wrong field.
An AI intake works differently. The user describes what's going on in their own words, either by typing or speaking, and a language model translates that into the structure your back-end system needs. Is information missing? The AI asks a follow-up question. Does something seem off? It asks for confirmation. Once the conversation is complete, it produces a clean JSON payload with exactly the fields your EHR, CRM, HRIS or case management system expects. This is the core of what we build every day in our AI development work.
What makes the difference: we don't build a general-purpose chatbot that you then try to trim down. We build a clearly bounded intake layer based on the JSON schema the back end needs. The AI knows which questions to ask to fill that schema, and stops once everything is in place. No open ends, no improvising advice the model isn't permitted to give. Sector knowledge (clinical intake protocols, complaint classifications, legal request types) is added through a targeted RAG layer. Fast, inexpensive to run, and explainable to the regulator.
In our experience, AI intake integrations fall roughly into three categories, each with a different emphasis on compliance, depth of integration and user experience. Which form suits your organisation depends on the kind of decision taken after the intake and the sensitivity of the data being collected.
A conversational intake component you can embed in an existing website, customer portal or mobile app. Users stay within your own branding and are never redirected to a third-party domain. Suitable for insurers taking in claims, municipalities running a reporting flow, or B2B sales teams automating an initial needs assessment. The output lands directly in your CRM, ticketing system or case management system.
The user calls or speaks in an app, the AI listens in, structures the conversation into the fields of your intake schema, and the staff member on the other end receives a clear summary instead of a raw call recording. Ideal for care triage, municipal 14-number lines, claims lines and high-volume support call centres. We connect a speech recognition engine to an LLM layer that turns the transcript into a structured intake record.
An intake layer built entirely for one domain: a GP history app that asks questions in line with NHG guidelines, a law firm intake that performs practice-area classification and conflict checks up front, or an HR onboarding flow that lands directly in the HRIS. For healthcare contexts we work within the framework of our client appointment portal, with NEN 7510 compliance from the first sprint.
A production-ready AI intake integration that fits the workflow of your people and the architecture of your IT, plus everything needed to manage, audit and extend it. The code, prompts, schemas and models are yours. We only handle the management if you want us to; you can take it elsewhere tomorrow if that suits you better.
Eight patterns where AI intake adds value in practice. If you recognise your organisation or use case in one of these profiles, we'd be happy to talk further, even if you're still unsure whether your own integration is the right choice instead of an off-the-shelf package.
Patients describe their complaint in their own words through a secure patient portal flow, and the AI structures it into an NHG-compliant medical history with red flags highlighted in advance. For the GP or mental health practitioner, consultations are shorter and better prepared, and the SOEP-S field in the EHR is already filled in. For sensitive patient groups such as paediatrics, psychiatry or oncology, we agree explicitly which questions an AI may ask and which must be guided by a human beforehand. See also our approach to client appointment portals.
A prospective client describes their matter; the AI classifies the area of law (family law, employment law, corporate law, criminal law), assesses urgency, runs an initial conflict check against the firm's system and determines which partner is best placed to take the matter on. Clients receive a more targeted response faster, and the firm spends less time on matters outside its practice. For the high-risk tier under the AI Act, we build in the human review step for every matter that is actually accepted.
A new employee goes through a conversational onboarding in which the AI asks the full set of questions HR would otherwise collect via Excel or email: home address, BSN, holiday arrangements, hardware preferences, travel expense claims. The data flows directly into the HRIS, IT provisioning, the expense tool and payroll. For the employee, it feels like a single conversation.
A business customer describes their requirement to the AI, which asks the discovery questions a sales engineer would normally ask (user numbers, integration requirements, decision-making process) and delivers a complete brief instead of a raw lead.
An policyholder reporting a collision, claiming fire damage or reporting a stolen phone describes the incident in an AI-guided intake conversation. The AI probes the facts, accepts photos through an upload step, classifies the type of damage and raises an initial fraud signal where the factors warrant it. The claims handler picks it up with a largely complete file.
Residents who submit a report, lodge a complaint or send in an application do so through a conversational flow that delivers far better-prepared information to the caseworker than the current form. The AI categorises the submission, routes it to the right department and asks follow-up questions.
Patients awaiting surgery complete a digital intake beforehand that gathers the information the anaesthetist and theatre team would otherwise have to pull out verbally: medication, allergies, previous procedures, comorbidities, mobility. The AI adapts to each answer and produces a structured pre-operative checklist that lands directly in the EHR, alongside your existing records management system.
For universities of applied sciences, municipal services or education enrolments: an AI flow that guides the applicant through all the relevant questions and places the application in the back-office system in a structured form. With attention to accessibility, B1 language level, and alternative routes for those who would rather speak to a person.
We do not pick a single favourite model in advance. We decide only once we know the use case, the data category, the languages and the privacy requirements. A brief orientation per candidate, which we will walk through with you in an initial session. We work vendor-independently: you own the prompts and the schema, and we can switch models tomorrow should the market or pricing give cause.
For healthcare, government and financial clients often the practical choice: EU residency in Western Europe, integration with Azure AD, a data block against training, and an existing Microsoft contract that simplifies procurement. Strong support for structured outputs and function calling.
For customers on AWS who want to run with strict privacy: Claude models via Bedrock in EU regions, with strong performance on Dutch-language context and a conservative response profile that works well in compliance-sensitive intake processes.
For customers who, for policy reasons, do not want a US cloud provider in the stack, such as academic hospitals, law firms or defence contexts, we run an open-source LLM in your own cloud or on-premises. Lower out of the box, but compensated for with fine-tuning and RAG.
For domain knowledge, we use a vector database (pgvector, Qdrant or Weaviate) with your organisation's own documents as the source. Alongside it, an evaluation pipeline automatically tests the intake prompt against a growing set of realistic cases, so that a prompt change cannot quietly break one type of intake.
For voice intake, we connect a speech recognition engine (Deepgram, AssemblyAI or Azure Speech) to a telephony or WebRTC layer (Twilio, Genesys, Amazon Connect) and to the LLM. The AI listens in, structures the conversation, and can route the caller to a human at the right moment.
We build the intake component as a lightweight JS widget that fits into your portal, with SSO integration (Azure AD, DigiD, eHerkenning, Auth0). For mobile, we use a native React Native or Flutter component.
A conversation in which we establish exactly what the intake flow will be: who the end user is, what data needs to come out at the end, which back-end system it lands in, and which decisions follow from the intake. Together we draft the JSON schema that describes the output. This is often an eye-opener for organisations that have never seen their existing intake form laid out that way on a drawing board. Sometimes a short advisory phase is the right first step; see our page on AI development.
For intakes that involve personal data, as is inherently the case in healthcare, legal, HR or government, we start the DPIA in parallel with the build. We classify the intake under the AI Act and address the related obligations directly in the design. Chat flow, retention policy, encryption, sub-processor choices and LLM data residency come together in a single architecture document that your data protection officer can also review. We align with an existing ISMS.
The system prompt and the structured output definitions take shape based on the schema from step 1. We build the RAG layer on the organisational knowledge the model needs in order to respond in the same style the organisation itself would. From day one, prompts and evaluation cases live in a git repository with code review.
Every short sprint produces a working build on staging. We build incrementally: first the basic flow with structured output, then the RAG layer, then the downstream integration, then the human-in-the-loop step, then the audit trail. With every prompt or schema change, an evaluation set of realistic cases runs and scores results per cohort. A change that improves overall quality but worsens one target group is something we want to see before release. An intake that silently fills in the wrong fields is worse than one that is occasionally a bit slower.
Phased rollout: first a pilot group with dual intake (AI and the existing form side by side), then a wider rollout, and finally a full transition. Short training for the staff who need to process intake records, a guide for end users, and ongoing management for model updates, prompt iterations and security patches. We monitor intake quality per cohort and keep adjusting.
An AI intake layer often handles sensitive data and, on the way to a decision, has an impact on a person: a patient, a client, an applicant. For healthcare, legal and public-sector applications, a well-built AI intake is by definition also a well-documented, GDPR-compliant and AI Act-compliant integration. We take care of that layer from the first sprint, not as a closing paperwork exercise.
Every intake collects personal data, often sensitive: a care complaint, a legal matter, a BSN (citizen service number), a consultation report. We carry out a targeted DPIA, put data processing agreements in place with sub-processors (LLM provider, hosting, vector database), and build retention and erasure policies into the intake flow itself.
The EU AI Act has been in force since 2026. A general B2B discovery intake is low-risk, but once the intake feeds into medical triage, legal decisions or HR assessments, the system falls into the high-risk category. We carry out the classification up front and put in place the risk management documentation, data quality requirements, transparency layer and human oversight mechanism.
For healthcare organisations, we follow the NEN 7510 control set from the outset: access management, logging, encryption, supplier management. We align with your existing ISMS. See also our approach to NEN 7510-compliant software.
Intakes involving minors — youth psychiatry, school care, youth services — are subject to additional rules. Under the age of sixteen, consent from a parent or guardian is generally required; that consent should be part of the intake flow itself, without making the process unnecessarily burdensome for the young person.
For intakes that end in a formal declaration or consent — an injury claim, an onboarding contract, consent to share medical data — we build an eIDAS-compliant signature step. Using DigiD or eHerkenning for public-sector parties, or an advanced electronic signature for B2B.
Every intake has traceable provenance: which questions, which answers, which model and version, which RAG sources, which human actions, and what was passed on to the underlying system. For high-risk applications, explicit human-in-the-loop steps are included before the outcome affects decision-making.
What clients typically want to know before we begin an AI intake integration.
A no-obligation introductory conversation. Tell us who will use the intake, which system the record will ultimately land in and what compliance context applies. We will think along with you and be honest about whether a custom integration is the right answer. Sometimes the right first step is a short advisory phase via AI development; sometimes building is the immediate priority. You can also email us: fabian.vandijk@appfront.nl.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
