Jest takie szczególne uczucie niepokoju, które pojawia się przy otwieraniu pięcioletniego eksportu klientów. Połowa numerów telefonów ma prefiks +386, a połowa nie. Kolumna nazwana “Notatki” miesza ze sobą trzy różne rodzaje informacji, w zależności od tego, kto danego dnia się spieszył. Nazwa czyjejś firmy jest zapisana na dwa różne sposoby w dwóch różnych wierszach, i naprawdę nie wiesz, czy to ten sam klient.
Czyż nie byłoby wspaniale móc po prostu wrzucić ten bałagan dokładnie takim, jaki jest, bez wcześniejszego czyszczenia, bez przeformatowywania, a system uczciwie powiedziałby ci, co znalazł, co założył i czego nie udało mu się uzupełnić? Teraz możesz. Zbudowaliśmy Craft11 tak, by dostosowywał się do tego, jak realne firmy faktycznie prowadzą swoją ewidencję, a nie odwrotnie.
Jak to naprawdę działa
Kiedy przesyłasz plik (CSV, Excel, PDF, nawet zeskanowany cennik), trafia on do Neo, części Craft11, która czyta dokumenty. Neo nie próbuje dopasować twojego arkusza do sztywnego schematu. Czyta rzeczywistą treść i proponuje ustrukturyzowane rekordy: to wygląda jak imię, to wygląda jak e-mail, to wygląda jak branża lub kategoria. Każda propozycja ma poziom pewności (wysoki, średni, niski), więc nigdy nie musisz zgadywać, przy których polach system jest pewny, a przy których stawia rozsądną hipotezę.
Nic jeszcze nie powstaje. Najpierw widzisz tabelę przeglądu. Kropki pewności przy każdym wierszu, edycja w miejscu, jeśli coś jest nie tak, wyraźne zliczenie tego, co jest kompletne, a co nie. Zatwierdzasz to, co dobre. Możesz od razu poprawić literówkę, jeśli chcesz, albo po prostu zostawić ją na później. Obie opcje są w porządku.
To jest ta część, która ludzi zaskakuje: system nigdy nie blokuje cię z powodu niedoskonałych danych. Jeśli 47 z twoich 300 kontaktów nie ma numeru telefonu, pozostałe 253 i tak zostaną czysto zaimportowane, a ty dostajesz uczciwą, konkretną listę tych 47, a nie mgliste ostrzeżenie w stylu “niektóre rekordy mogą być niekompletne”, tylko realną liczbę, która nie znika, dopóki sprawa nie zostanie faktycznie rozwiązana. Stark może pomóc ci je odnaleźć w rozmowie, kiedy tylko masz kilka wolnych minut. Ta luka jest informacją, nie barierą.
Problem duplikatów, o którym nikt nie mówi
Oto coś, co nie pojawia się w większości prezentacji narzędzi do importu: co się dzieje, gdy prześlesz tę samą listę dwa razy? Albo gdy współpracownik już częściowo ręcznie wprowadził klienta, a masowy import zaraz utworzy drugą kopię tej samej osoby pod nieco inną pisownią?
Rozwiązujemy to celowo prostą regułą, stosowaną automatycznie, zanim jeszcze zobaczysz ekran przeglądu. Przy imporcie klientów jest to dopasowanie e-maila bez rozróżniania wielkości liter do istniejących rekordów. Przy katalogu zasobów jest to dopasowanie nazwy bez rozróżniania wielkości liter. Każdy wiersz, który wygląda na prawdopodobny duplikat, zostaje oznaczony i domyślnie pozostaje odznaczony w tabeli przeglądu: nie zablokowany, nie scalony automatycznie, po prostu odznaczony. Nadal możesz zaznaczyć pole i zaimportować go mimo to, jeśli rzeczywiście taki był zamiar. System nie może decydować o tym za ciebie. Po prostu nie pozwala, by przypadek prześlizgnął się po cichu.
Przetestowaliśmy to bezpośrednio: przesłaliśmy plik zawierający kontakt, którego e-mail dokładnie pasował do istniejącego klienta, obok kontaktu rzeczywiście nowego. Duplikat został oznaczony i pozostał odznaczony. Nowy kontakt zaimportował się bez problemu. Ponowne uruchomienie tego samego pliku po raz drugi nie stworzyło nic dodatkowego. O to właśnie chodzi: ponowne przesłanie pliku nie powinno być czymś, przy czym trzeba zachować szczególną ostrożność.
Prawdziwy błąd, znaleziony w uczciwy sposób
Chcę opowiedzieć ci o czymś, co naprawdę poszło nie tak podczas budowy tego rozwiązania, bo alternatywa, udawanie, że wszystko zadziałało idealnie od początku, byłaby dokładnie tym rodzajem marketingowej nieuczciwości, której staramy się unikać.
Importer katalogu zasobów ma pole stawki VAT. Nasza baza danych tego wymaga. Domyślna wartość to 25%, standardowa stawka, więc zasób bez jawnie podanej stawki powinien automatycznie wracać do tej wartości domyślnej. Tyle że tego nie robił. Jeśli przesyłałeś cennik zupełnie bez kolumny VAT (co jest niezwykle powszechne, wiele cenników po prostu jej nie ma), import padał z surowym błędem serwera w momencie, gdy próbowałeś go aktywować.
Przyczyna była subtelna: własna wartość domyślna bazy danych włącza się tylko wtedy, gdy pole jest całkowicie pominięte przy wstawianiu. Nasz kod jawnie wpisywał null do tego pola zamiast po prostu go pominąć, co oznaczało, że siatka bezpieczeństwa bazy danych nigdy nie miała szansy tego złapać. Odkryliśmy to tylko dlatego, że przeprowadziliśmy prawdziwy test end-to-end, z realistycznym plikiem, który rzeczywiście nie miał kolumny VAT (nie hipotetycznym, tylko faktycznym przesłaniem), i zobaczyliśmy, jak to zawodzi. Poprawka to jedna linijka: domyślnie 25% w kodzie, ta sama liczba, którą sama baza danych dokumentuje jako standard, stosowana tylko wtedy, gdy plik źródłowy rzeczywiście milczy w tej sprawie.
Mówię ci o tym nie dlatego, że to pochlebna historia, ale dlatego, że to prawdziwa faktura uczciwego budowania czegoś takiego. Instynkt, żeby znaleźć ten błąd, faktycznie testując bałaganiarski, prawdziwy plik, zamiast zakładać idealny scenariusz, to ten sam instynkt, który stoi za całą tą funkcją. Oprogramowanie, które jest pewne co do danych, których w rzeczywistości nigdy nie widziało, to dokładnie ten rodzaj oprogramowania, którego staramy się nie budować.
Przetestowaliśmy całość na firmie, która jeszcze nie istnieje
Zanim to zostało wdrożone, przeprowadziliśmy pełny symulowany miesiąc użytkowania dla czteroosobowego zespołu konsultingowego: prawdziwe napływające zapytania, prawdziwe rozmowy z klientami, prawdziwe importy katalogu, na dedykowanym testowym najemcy, przez cały czas korzystając z prawdziwego modelu AI, a nie skryptu. Mogliśmy zrobić to tak dokładnie, bo już od pierwszego dnia zasialiśmy dużą, realistyczną porcję danych i zbudowaliśmy Velvet, nasz własny symulator testowy, właśnie po to, żeby nie być ograniczonymi do sprawdzania jednego przypadku brzegowego naraz. W tym samym miesiącu razem działało kilka bałaganiarskich scenariuszy: CSV z kontaktem, który już istniał, wymieszanym z rzeczywiście nowymi, obok wszystkiego innego, co ten miesiąc rzucił na system.
Całkowity koszt AI za cały ten symulowany miesiąc, dla czterech osób, wyniósł mniej niż dolara. Wspominamy o tym, bo narzędzia do importu “napędzane AI” mają reputację, czasem zasłużoną, stawania się drogą subskrypcją-za-subskrypcją. Przy tej skali ta obawa po prostu się nie sprawdza.
Czego to nie robi
W duchu tego, żeby nie przesadzać z obietnicami: to nie jest magia OCR dla naprawdę nieczytelnych skanów, i nie zgadnie pola, którego nigdy nie było w pliku źródłowym. Ustrukturyzowane pliki PDF i czyste arkusze kalkulacyjne działają dobrze; sfotografowana, odręcznie napisana faktura z 2019 roku wymaga więcej ludzkiej weryfikacji, i system uczciwie to mówi, zamiast wymyślać przypuszczenie.
Celowo też nie scala duplikatów automatycznie. To pozostaje decyzją człowieka, nie oprogramowania. Wyraźne oznaczanie i domyślne “nie importuj tego dwa razy” to dokładnie odpowiednia dawka pomocy.
Jeśli właśnie teraz patrzysz na własny bałaganiarski eksport
Uczciwa odpowiedź na “ile to potrwa” brzmi: prawdopodobnie popołudnie, nie tydzień. Prześlij plik. Przejrzyj to, co znalazło Neo. Zatwierdź to, co jest prawidłowe, popraw to, co nie jest, a luki zostaw na później, jeśli chcesz. Nadal tam będą, wyraźnie policzone, kiedy tylko będziesz gotowy. Celem nigdy nie było uczynienie twoich danych idealnymi, zanim zaczniesz. Celem było powstrzymanie tego, żeby idealne dane były ceną wstępu.
Migration Engine Craft11 obsługuje zarówno import Klientów, jak i Zasobów w oparciu o tę samą architekturę opisaną powyżej: ekstrakcję z oceną pewności, wykrywanie duplikatów i uczciwe śledzenie luk. Zobacz to w prezentacji produktu →