Existe uma angústia muito particular em abrir uma exportação de clientes com cinco anos. Metade dos números de telefone tem o prefixo +386, a outra metade não. Uma coluna chamada “Notas” mistura três tipos diferentes de informação, consoante quem estava com pressa naquele dia. O nome da empresa de alguém está escrito de duas formas diferentes em duas linhas diferentes, e você genuinamente não sabe se se trata do mesmo cliente.
Não seria bom poder simplesmente carregar a confusão tal como está, sem uma limpeza prévia, sem reformatação, e ter o sistema a dizer-lhe honestamente o que encontrou, o que presumiu e o que não conseguiu preencher? Agora pode. Construímos o Craft11 para se adaptar à forma como as empresas reais realmente mantêm os seus registos, não o contrário.
Como funciona realmente
Quando carrega um ficheiro (CSV, Excel, PDF, até uma lista de preços digitalizada), ele vai para o Neo, a parte do Craft11 que lê documentos. O Neo não tenta encaixar a sua folha de cálculo num esquema rígido. Lê o conteúdo real e propõe registos estruturados: isto parece um nome, isto parece um e-mail, isto parece um setor ou categoria. Cada proposta traz um nível de confiança (alto, médio, baixo), por isso nunca fica a adivinhar em que campos o sistema tem certeza e em quais está a fazer uma estimativa razoável.
Ainda não é criado nada. Primeiro vê uma tabela de revisão. Pontos de confiança junto a cada linha, edição direta se algo estiver errado, uma contagem clara do que está completo e do que não está. Aprova o que está bem. Pode corrigir um erro de digitação ali mesmo, se quiser, ou simplesmente deixá-lo e corrigi-lo mais tarde. Ambas as opções servem.
Esta é a parte que surpreende as pessoas: nunca o bloqueia por causa de dados imperfeitos. Se 47 dos seus 300 contactos não tiverem número de telefone, os outros 253 são na mesma importados sem problemas, e recebe uma lista honesta e concreta desses 47, não um aviso vago do tipo “alguns registos podem estar incompletos”, mas uma contagem real que não desaparece até ser efetivamente resolvida. O Stark pode ajudá-lo a localizá-los de forma conversacional sempre que tiver uns minutos. A lacuna é informativa, não uma barreira.
O problema dos duplicados de que ninguém fala
Aqui está algo que não aparece na maioria das apresentações de ferramentas de importação: o que acontece quando carrega a mesma lista duas vezes? Ou quando um colega já introduziu manualmente meio-cliente, e agora a importação em massa está prestes a criar uma segunda cópia da mesma pessoa com uma grafia ligeiramente diferente?
Tratamos isto com uma regra deliberadamente simples, aplicada automaticamente antes mesmo de ver o ecrã de revisão. Para importações de clientes, é uma correspondência de e-mail insensível a maiúsculas/minúsculas com os seus registos existentes. Para um catálogo de recursos, é uma correspondência de nome insensível a maiúsculas/minúsculas. Qualquer linha que pareça um duplicado provável é assinalada e fica por defeito por assinalar na tabela de revisão: não bloqueada, não fundida automaticamente, apenas por assinalar. Você pode sempre marcar a caixa e importá-la mesmo assim, se essa era realmente a sua intenção. O sistema não pode decidir isso por si. Apenas garante que um erro não passa despercebido em silêncio.
Testámos isto diretamente: carregámos um ficheiro contendo um contacto cujo e-mail correspondia exatamente a um cliente existente, ao lado de um genuinamente novo. O duplicado foi assinalado e permaneceu por assinalar. O novo contacto foi importado sem problemas. Executar novamente o mesmo ficheiro uma segunda vez não criou nada adicional. É esse todo o objetivo: voltar a carregar um ficheiro não devia ser algo com que tem de ter cuidado.
Um bug real, encontrado de forma honesta
Quero contar-lhe algo que correu mesmo mal enquanto construíamos isto, porque a alternativa, fingir que correu tudo perfeitamente desde o início, seria exatamente o tipo de desonestidade de marketing que tentamos evitar.
O importador do catálogo de recursos tem um campo de taxa de IVA. A nossa base de dados exige-o. Tem um valor por defeito de 25%, a taxa normal, pelo que um recurso sem uma taxa explícita deveria recorrer automaticamente a esse valor por defeito. Só que não recorria. Se carregasse uma lista de preços sem qualquer coluna de IVA (o que é extremamente comum, muitas listas de preços simplesmente não têm uma), a importação falhava com um erro de servidor em bruto no momento em que tentasse ativá-la.
A razão era subtil: o valor por defeito da própria base de dados só entra em ação quando um campo é totalmente omitido da inserção. O nosso código escrevia explicitamente null nesse campo em vez de o deixar de fora, o que significava que a rede de segurança da base de dados nunca tinha hipótese de o apanhar. Só descobrimos isto porque corremos um verdadeiro teste ponta a ponta, com um ficheiro realista que genuinamente não tinha coluna de IVA (não uma hipótese, um carregamento real), e vimos falhar. A correção foi uma linha: por defeito 25% no código, o mesmo número que a própria base de dados documenta como padrão, aplicado apenas quando o ficheiro de origem está genuinamente calado sobre o assunto.
Estou a contar-lhe isto não porque seja uma história lisonjeira, mas porque é a textura real de construir algo assim com honestidade. O instinto de encontrar esse bug testando realmente um ficheiro real e desorganizado, em vez de assumir o caminho ideal, é o mesmo instinto por trás de toda a funcionalidade. Software que está confiante sobre dados que nunca realmente viu é exatamente o tipo de software que tentamos não construir.
Testámos tudo isto numa empresa que ainda não existe
Antes de isto ser lançado, corremos um mês inteiro simulado de utilização para uma equipa de consultoria de quatro pessoas: pedidos reais a chegar, conversas reais com clientes, importações reais de catálogo, contra um tenant de teste dedicado, usando um modelo de IA real do início ao fim, não um script. Conseguimos fazer isto com tanto rigor porque já tínhamos semeado, desde o primeiro dia, uma grande porção realista de dados e construído o Velvet, o nosso próprio simulador de testes, precisamente para não ficarmos limitados a verificar um caso limite de cada vez. Vários cenários confusos correram em conjunto no mesmo mês: um CSV com um contacto que já existia misturado com outros genuinamente novos, juntamente com tudo o resto que esse mês atirou ao sistema.
O custo total de IA para todo esse mês simulado, para quatro pessoas, foi de menos de um dólar. Mencionamos isto porque as ferramentas de importação “com IA” têm fama, por vezes merecida, de se tornarem uma subscrição cara escondida atrás da subscrição. Nesta escala, esse receio simplesmente não se sustenta.
O que isto não faz
No espírito de não sobrevalorizar isto: não é magia de OCR para digitalizações genuinamente ilegíveis, e não vai adivinhar um campo que nunca existiu no ficheiro de origem. PDFs estruturados e folhas de cálculo organizadas funcionam bem; uma fatura fotografada e manuscrita de 2019 precisa de mais revisão humana, e o sistema diz isso honestamente em vez de inventar uma suposição.
Também não funde duplicados automaticamente, de propósito. Isso continua a ser uma decisão humana, não do software. Assinalar claramente e deixar por defeito “não importar isto duas vezes” é exatamente a medida certa de ajuda.
Se está agora mesmo a olhar para a sua própria exportação desorganizada
A resposta honesta a “quanto tempo é que isto vai demorar” é: provavelmente uma tarde, não uma semana. Carregue o ficheiro. Reveja o que o Neo encontrou. Aprove o que está certo, corrija o que não está, deixe as lacunas para depois, se quiser. Vão continuar lá, claramente contabilizadas, sempre que estiver pronto. O objetivo nunca foi tornar os seus dados perfeitos antes de começar. Foi impedir que dados perfeitos fossem o preço da entrada.
O Migration Engine do Craft11 trata tanto as importações de Clientes como de Recursos com a mesma arquitetura descrita acima: extração com pontuação de confiança, deteção de duplicados e acompanhamento honesto de lacunas. Veja isto na visita guiada ao produto →