Een klant of partner richt het Artific-platform in langs vier vragen: hoe gebruikers ermee interacteren, hoe klanten van elkaar gescheiden zijn, wat je instelt, en of eigen systemen toegang dienen te krijgen tot AI via het platform. Gebruik deze pagina om de inrichting vorm te geven.
Hoe interacteren gebruikers met het systeem?
Hoe rol je klanten uit op het platform?
Welke context en mogelijkheden wil je instellen?
Wil je dat systemen via het platform toegang krijgen tot AI?
Dit is wat de klant zelf al weet en als eerste vertelt. Een klant kiest vaak meerdere vormen, één per doelgroep: de eigen medewerkers in de workspace, de bezoekers via een widget, het eigen systeem via de API.
Gebruikers loggen in op het Artific-portaal en werken daar: ze chatten met assistants, draaien toolbox-elementen en gebruiken bestanden, projecten en de kennisbank. Beheerders richten in dezelfde omgeving alles in. Er hoeft niets bij de klant geïnstalleerd of gebouwd te worden.
De eigen medewerkers van de klant dagelijks met AI werken en de klant het beheer in dezelfde omgeving wil.
Het portaal draagt de branding van de organisatie. Bij een gedeelde organisatie (B2) zien alle eindklanten dus dezelfde branding.
De klant plaatst een klein stukje code op zijn website of in zijn app, en daar verschijnt het Artific-chatvenster in zijn eigen kleuren. De klant bouwt zelf geen chat. Het venster kan anoniem werken of de ingelogde gebruiker van de klant herkennen, en de website kan het gesprek aansturen en informatie meegeven. Nieuwe mogelijkheden van het chatvenster, zoals spraak of bestanden meesturen, krijgt de klant automatisch.
De klant zijn eigen bezoekers of gebruikers wil helpen en tevreden is met een chatvenster in zijn eigen kleuren.
De assistant reageert in een kanaal dat de eindgebruiker al gebruikt: hij beantwoordt een e-mail of neemt een telefoongesprek aan. De eindgebruiker hoeft niets te installeren of ergens in te loggen en merkt niet dat er een platform achter zit.
De eindgebruikers al via dat kanaal contact hebben en je hun gedrag niet wilt veranderen.
E-mail en telefonie kunnen vandaag. Kanalen als WhatsApp en Teams zijn in ontwikkeling.
De klant bouwt de schermen zelf, in zijn eigen product, en stuurt vragen naar het platform. Het platform geeft het antwoord terug en de klant toont het in zijn eigen vormgeving. De eindgebruiker ziet alleen het product van de klant. Hoe de klant aansluit staat in D: eigen software, een workflowtool of een eigen agent.
De klant een eigen product heeft waar het gesprek native in moet passen.
Er is geen gebruiker die iets intypt. Een tijdstip of een gebeurtenis start de assistant, bijvoorbeeld elke ochtend om negen uur een rapport, of een bevestiging zodra een bestelling binnenkomt. Het resultaat landt in een systeem, een mailbox of het portaal. De ene vraag die ertoe doet is waar het draaiboek staat, en die bepaalt meteen de behoefte voor "headless integratie" (opties D).
In het portaal stel je in dat een assistant op een vast moment een opdracht uitvoert, of zodra een ander systeem een webhook stuurt. Opdracht, prompt en bestemming staan in het platform. De klant programmeert niets en ziet of het gelukt is.
Hun software, workflowtool of agent roept assistants en elementen in het platform aan en bepaalt zelf de vervolgstappen. Dezelfde aandachtspunten als A4.
Achtergrondtaken plannen in het portaal is in ontwikkeling. De variant vanuit hun eigen systeem kan vandaag al via de API.
Krijgt iedere klant of eindklant een eigen organisatie, of zitten ze samen in één? Dit is de vraag die de klant zelf meestal niet stelt, en die het meeste bepaalt over beheer, scheiding, branding en wat een klant zelf kan toevoegen.
Elke klant heeft een eigen, afgesloten omgeving. Alleen de eigen beheerder bepaalt wie toegang heeft, welke assistants er zijn, welke bestanden en koppelingen erin zitten en hoe het eruitziet. Niets daarvan is zichtbaar voor andere klanten. Daar staat tegenover dat elke omgeving apart wordt ingericht en onderhouden.
De klant zelf wil beheren, eigen koppelingen, bestanden of bronnen wil toevoegen, gegevens heeft die strikt gescheiden moeten blijven, of eigen branding wil voeren.
Meer inrichtingswerk per klant.
Alle eindklanten werken in dezelfde omgeving en één partij beheert die. Met groepen bepaal je welke eindklant welke assistants en bronnen ziet. Dat is snel opgezet en goedkoop in beheer. Maar alles wat je in de omgeving toevoegt, geldt voor iedereen: één branding, één set koppelingen, één set bestanden en bronnen. Een eindklant kan niets eigens toevoegen en kan geen beheerrechten krijgen, want dan ziet hij de gegevens van de andere eindklanten.
De beheerder één partij is, de eindklanten alleen gebruiken, en het aanbod voor alle eindklanten hetzelfde mag zijn.
De hele configuratie uit C geldt hier voor alle eindklanten tegelijk: één branding, één set koppelingen, één kennisbank. Eindklanten kunnen niets eigens toevoegen en nooit beheerrechten krijgen. Zodra dat nodig is, moet die eindklant naar een eigen organisatie.
Elke eindklant houdt een eigen omgeving, maar de assistants en toolbox-elementen komen uit een centrale catalogus. Je bouwt ze eenmalig en installeert ze in elke omgeving. Werk je de bron bij, dan krijgt elke installatie die wijziging mee. Per omgeving kan de eindklant er eigen bestanden, koppelingen en instructies aan toevoegen, zonder dat andere eindklanten dat zien.
Je hetzelfde aanbod bij veel klanten wilt uitrollen zonder de scheiding op te geven. Combineert de scheiding van B1 met het gemak van B2.
De marketplace is in ontwikkeling. Vandaag kan een partner assistants kopiëren naar de organisatie van een eindklant; die kopie is los, dus latere wijzigingen in de bron sijpelen niet door.
Vier gesprekken die je in elke intake voert. Per onderdeel zijn er varianten, en die verschillen vooral in wie het doet. Het bouwen van assistants en toolbox-elementen is geen apart onderdeel; dat is het werk dat op deze configuratie rust.
Hoe de organisatie zich gedraagt en wat er voor haar aanstaat. Dit is het eerste gesprek met de beheerder en het raakt alles wat daarna gebouwd wordt.
De beheerder van de klant, of Artific of de partner bij de eerste inrichting.
Dit is geen volledige lijst. Alles wat per organisatie instelbaar is valt hieronder; het portaal is leidend. Voor een overzicht van alle functies kijk dan op product.artific.nl.
Toegang loopt via groepen: een groep bepaalt welke assistants, elementen en kennis iemand ziet. De vraag is hoe de klant zijn mensen erin krijgt en of ze met een eigen account of via het eigen systeem inloggen.
De documenten en bronnen die assistants moeten kennen, geordend in collecties met per assistant de vraag welke collecties hij mag gebruiken. De vraag is waar de kennis nu staat en hoe vaak ze verandert: losse documenten die zelden wijzigen, een bron die leeft, of een eigen systeem dat kennis genereert.
De systemen waarin assistants moeten kunnen lezen en handelen: agenda, CRM, ticketsysteem, eigen applicaties. De assistants roepen die systemen dan aan. Wat een assistant met een koppeling mag doen, bepaal je per assistant in het portaal.
Een assistant raadpleegt het CRM, de agenda, een API of een MCP-server van de klant als hulpmiddel. Het draaiboek staat in het platform en de beheerder stelt het in via het portaal.
Voor de meeste klanten is het antwoord nee: alles loopt via het portaal, de widget en de kanalen. Voor klanten met eigen software, workflowtools of eigen AI-agents is het platform de integratielaag waarmee zij veilig bij AI komen, met de kennis, koppelingen en regels die in het platform zijn ingesteld. Allemaal via dezelfde API en hetzelfde rechtenmodel.
De systemen van de klant roepen het platform niet aan. Gebruikers werken in het portaal, de widget of een kanaal, en de hele configuratie wordt door een beheerder ingesteld.
De klant geen eigen software of workflows heeft die AI nodig hebben.
Niet mogelijk in combinatie met A4, en niet met A5 als het draaiboek bij hen staat.
Een stap in n8n, Make of Zapier stuurt een vraag naar een assistant of element en gebruikt het antwoord in de volgende stap. Zo krijgt bestaande automatisering veilig toegang tot AI, met de kennis, tools en regels die in het platform zijn ingesteld. Geen programmeurs nodig, wel iemand die de tool beheerst.
Hun systeem roept assistants en elementen in het platform aan en beslist wat er met het antwoord gebeurt. Het draaiboek staat in hun systeem.
De klant al automatiseert met zo'n tool, meestal voor A5 met het draaiboek bij hen.
Vandaag via een generieke HTTP-stap tegen de API. Een kant-en-klare Artific-stap voor deze tools is in ontwikkeling.
De software van de klant, met of zonder AI erin, roept het platform aan via de API: assistants laten antwoorden, elementen uitvoeren, widget-sessies aanmaken voor ingelogde gebruikers, kennis aanleveren. Met beheerrechten ook organisaties, gebruikers en assistants aanmaken. Technisch dezelfde koppeling als D1, maar gebouwd door ontwikkelaars met de SDK en documentatie.
Hun systeem roept assistants en elementen in het platform aan en beslist wat er met het antwoord gebeurt. Het draaiboek staat in hun systeem.
De klant een eigen product heeft (A4), eigen systemen die het platform aansturen (A5), of de ingelogde gebruiker wil doorgeven aan de widget (A2).
Antwoorden komen in één keer terug; woord-voor-woord meelezen via de API is in ontwikkeling. Verbruik wordt gerapporteerd per organisatie, nog niet per afzonderlijke koppeling.
De eigen agent van de klant, of een assistent zoals Claude, ChatGPT of Copilot, gebruikt het platform via MCP: assistants raadplegen, elementen uitvoeren, in de kennisbank zoeken, en met beheerrechten het platform configureren. De agent beslist zelf wanneer hij het platform inschakelt. De klant hoeft niets te programmeren, alleen de koppeling te activeren.
Hun systeem roept assistants en elementen in het platform aan en beslist wat er met het antwoord gebeurt. Het draaiboek staat in hun systeem.
De klant zelf al agents draait en het platform daarin wil opnemen zonder te bouwen.
Artific als MCP-server is in ontwikkeling; tot die tijd is D2 het alternatief. Niet verwarren met de eigen MCP-server onder C4: daar gebruikt een assistant hun MCP-server, hier gebruikt hun agent het platform.
Dezelfde vragen als in de intake, in volgorde: ervaring, indeling, dan de opties uit C en D. Doorloop hem per doelgroep als een klant meerdere ervaringen nodig heeft.