Er is een heel specifiek soort onbehagen dat opkomt wanneer u een vijf jaar oude klantexport opent. De helft van de telefoonnummers heeft een +386-prefix, de andere helft niet. Een kolom genaamd “Notities” gooit drie verschillende soorten informatie op een hoop, afhankelijk van wie er die dag haast had. De bedrijfsnaam van iemand is op twee verschillende manieren gespeld in twee verschillende rijen, en u weet echt niet of dat dezelfde klant is.
Zou het niet fijn zijn als u die rommel gewoon kon uploaden zoals hij is, zonder eerst op te schonen, zonder herformattering, en het systeem u eerlijk zou vertellen wat het gevonden heeft, wat het gegokt heeft en wat het niet kon invullen? Nu kan dat. Wij hebben Craft11 gebouwd om zich aan te passen aan hoe echte bedrijven hun administratie daadwerkelijk bijhouden, niet andersom.
Hoe het echt werkt
Wanneer u een bestand uploadt (CSV, Excel, PDF, zelfs een gescande prijslijst), gaat het naar Neo, het onderdeel van Craft11 dat documenten leest. Neo probeert uw spreadsheet niet te passen in een star schema. Het leest de daadwerkelijke inhoud en stelt gestructureerde records voor: dit lijkt op een naam, dit lijkt op een e-mailadres, dit lijkt op een sector of categorie. Elk voorstel draagt een betrouwbaarheidsniveau (hoog, gemiddeld, laag), zodat u nooit hoeft te raden bij welke velden het zeker is en bij welke het een redelijke gok waagt.
Er wordt nog niets aangemaakt. U ziet eerst een controletabel. Betrouwbaarheidsstippen naast elke rij, inline bewerken als er iets niet klopt, een duidelijk overzicht van wat compleet is en wat niet. U keurt goed wat goed is. U kunt een tikfout ter plekke corrigeren als u wilt, of het gewoon laten staan en later verbeteren. Beide kan.
Dit is het deel dat mensen verrast: het blokkeert u nooit vanwege onvolledige gegevens. Als bij 47 van uw 300 contacten het telefoonnummer ontbreekt, worden de andere 253 gewoon netjes geïmporteerd, en krijgt u een eerlijke, concrete lijst van die 47, geen vage waarschuwing zoals “sommige records zijn mogelijk onvolledig”, maar een echt aantal dat pas verdwijnt als het daadwerkelijk is opgelost. Stark kan u helpen deze conversationeel op te sporen zodra u een paar minuten heeft. De ontbrekende gegevens zijn informatief, geen blokkade.
Het duplicatenprobleem waar niemand het over heeft
Hier is iets dat in de meeste pitches voor importtools niet voorkomt: wat gebeurt er als u dezelfde lijst twee keer uploadt? Of wanneer een collega een klant al half handmatig heeft ingevoerd, en de bulkimport nu op het punt staat een tweede kopie van dezelfde persoon aan te maken onder een iets andere spelling?
Wij pakken dit aan met een bewust eenvoudige regel, die automatisch wordt toegepast voordat u het controlescherm überhaupt te zien krijgt. Bij klantimports is dat een hoofdletterongevoelige e-mailmatch met uw bestaande records. Bij een resourcecatalogus is dat een hoofdletterongevoelige naammatch. Elke rij die op een waarschijnlijk duplicaat lijkt, wordt gemarkeerd en staat in de controletabel standaard niet aangevinkt: niet geblokkeerd, niet automatisch samengevoegd, gewoon niet aangevinkt. U kunt het vakje nog steeds aanvinken en het toch importeren als dat echt uw bedoeling was. Het systeem mag dat niet voor u beslissen. Het zorgt er alleen voor dat een vergissing niet stilzwijgend doorglipt.
We hebben dit direct getest: we hebben een bestand geüpload met een contact wiens e-mailadres exact overeenkwam met een bestaande klant, naast een echt nieuw contact. Het duplicaat werd gemarkeerd en bleef niet aangevinkt. Het nieuwe contact werd netjes geïmporteerd. Hetzelfde bestand een tweede keer opnieuw uitvoeren creëerde niets extra’s. Dat is precies het punt: opnieuw uploaden zou niets moeten zijn waar u voorzichtig mee moet zijn.
Een echte bug, op eerlijke wijze gevonden
Ik wil u vertellen over iets dat daadwerkelijk misging tijdens het bouwen hiervan, want het alternatief, doen alsof het van meet af aan perfect werkte, zou precies het soort marketingoneerlijkheid zijn dat we proberen te vermijden.
De importer voor de resourcecatalogus heeft een btw-tariefveld. Onze database vereist dit. De standaardwaarde is 25%, het normale tarief, dus een resource zonder expliciet tarief zou automatisch op die standaardwaarde moeten terugvallen. Behalve dat het dat niet deed. Als u een prijslijst zonder btw-kolom uploadde (wat extreem vaak voorkomt, veel prijslijsten hebben er simpelweg geen), crashte de import met een rauwe serverfout op het moment dat u probeerde deze te activeren.
De reden was subtiel: de eigen standaardwaarde van de database wordt alleen geactiveerd wanneer een veld volledig wordt weggelaten uit de invoeging. Onze code schreef expliciet null naar dat veld in plaats van het weg te laten, waardoor het vangnet van de database nooit de kans kreeg om dit op te vangen. We hebben dit alleen ontdekt omdat we een echte end-to-end test uitvoerden, met een realistisch bestand dat daadwerkelijk geen btw-kolom had (geen hypothese, een echte upload), en zagen dat het faalde. De fix was één regel: standaard 25% in de code, hetzelfde getal dat de database zelf als standaard documenteert, alleen toegepast wanneer het bronbestand hier daadwerkelijk niets over zegt.
Ik vertel u dit niet omdat het een vleiend verhaal is, maar omdat het de daadwerkelijke textuur is van zoiets eerlijk bouwen. Het instinct om die bug te vinden door daadwerkelijk een rommelig echt bestand te testen, in plaats van het ideale scenario aan te nemen, is hetzelfde instinct achter de hele functie. Software die zelfverzekerd is over gegevens die het in werkelijkheid nooit heeft gezien, is precies het soort software dat we proberen niet te bouwen.
We hebben het geheel getest op een bedrijf dat nog niet bestaat
Voordat dit live ging, hebben we een volledig gesimuleerde gebruiksmaand gedraaid voor een adviesteam van vier personen: echte binnenkomende aanvragen, echte klantgesprekken, echte catalogusimports, tegen een speciale test-tenant, de hele tijd met een echt AI-model, geen script. We konden dit zo grondig doen omdat we vanaf dag één al een groot, realistisch deel aan gegevens hadden ingevoerd en Velvet hadden gebouwd, onze eigen testsimulator, juist om niet beperkt te zijn tot het controleren van één randgeval tegelijk. Meerdere rommelige scenario’s liepen in dezelfde maand samen: een CSV met een contact dat al bestond, gemengd met echt nieuwe, naast al het andere wat die maand naar het systeem gooide.
De totale AI-kosten voor die hele gesimuleerde maand, voor vier personen, waren minder dan een dollar. We noemen dit omdat “AI-gedreven” importtools de reputatie hebben, soms terecht, om een dure abonnement-achter-het-abonnement te worden. Op deze schaal houdt die angst gewoon geen stand.
Wat dit niet doet
In de geest van dit niet te overdrijven: het is geen OCR-magie voor werkelijk onleesbare scans, en het zal geen veld raden dat nooit in het bronbestand stond. Gestructureerde PDF’s en nette spreadsheets werken goed; een gefotografeerde, handgeschreven factuur uit 2019 heeft meer menselijke controle nodig, en het systeem zegt dat eerlijk in plaats van een gok te verzinnen.
Het voegt ook expres geen duplicaten automatisch samen. Dat blijft een menselijke beslissing, niet die van de software. Duidelijk markeren en standaard “dit niet twee keer importeren” is precies de juiste hoeveelheid hulp.
Als u nu naar uw eigen rommelige export staart
Het eerlijke antwoord op “hoe lang gaat dit duren” is: waarschijnlijk een middag, geen week. Upload het bestand. Bekijk wat Neo gevonden heeft. Keur goed wat klopt, corrigeer wat niet klopt, laat de gaten voor later staan als u wilt. Ze blijven er, duidelijk geteld, wanneer u er klaar voor bent. Het doel was nooit om uw gegevens perfect te maken voordat u begint. Het was om te voorkomen dat perfecte gegevens de toegangsprijs zouden zijn.
De Migration Engine van Craft11 behandelt zowel Klanten- als Resource-imports met dezelfde hierboven beschreven architectuur: extractie met betrouwbaarheidsscore, duplicaatdetectie en eerlijke opvolging van ontbrekende gegevens. Bekijk het in de producttour →