Fotografar cartões de visita, guardar folhetos e anotar conversas numa feira é fácil; encontrar depois o contacto certo e lembrar o contexto da conversa é que costuma dar trabalho. A Bootly, aplicação que a iServices anunciou que vai apresentar na Web Summit 2026, propõe centralizar esse material com OCR e Inteligência Artificial. A ideia é útil, mas o valor real depende de uma questão técnica menos vistosa: transformar dados capturados em informação organizada, pesquisável e segura.
Segundo o Sapo.pt, a Bootly nasceu de necessidades identificadas pelas equipas da própria iServices e foi pensada para organizar contactos, produtos e informação recolhida em feiras profissionais. A fonte não detalha funcionalidades, fornecedores de OCR, arquitetura ou políticas de retenção. Por isso, separo aqui o que foi anunciado da análise técnica: não vou atribuir à aplicação capacidades que ainda não foram divulgadas.
O problema técnico de organizar contactos recolhidos em feiras
Uma feira gera dados em formatos diferentes: uma fotografia de cartão, um vídeo de demonstração, uma conversa anotada à pressa, uma página de catálogo e, por vezes, um contacto introduzido manualmente. Esses elementos não têm necessariamente um identificador comum. Sem uma ligação explícita entre eles, a equipa acaba com ficheiros espalhados e contexto perdido.
Uma aplicação como a Bootly pode ajudar se permitir associar cada registo a uma pessoa, empresa, produto e nota de contexto. Por exemplo: “falámos sobre integração com ERP no segundo dia, junto ao expositor B”. Uma lista de contactos sem essa ligação resolve apenas uma parte do problema. O que interessa é recuperar a história da interação, não só o número de telefone.
Na minha experiência, esse detalhe faz a diferença entre uma ferramenta de captura e um sistema de trabalho. O OCR reduz a digitação, mas não decide sozinho se “Acme Ltd.” e “ACME” são a mesma empresa, nem se uma anotação pertence a determinado cartão. Essa camada de organização precisa de regras claras e de uma forma simples de correção humana.
Como OCR e IA podem trabalhar juntos numa aplicação de eventos
OCR é a tecnologia que reconhece texto numa imagem. Num cartão de visita, pode extrair nome, cargo, empresa, telefone e e-mail. A IA pode ajudar a classificar os campos, resumir notas ou sugerir relações entre registos. São funções complementares, não sinónimas: OCR produz texto; a aplicação ainda precisa de interpretar, validar e armazenar esse texto.
Um fluxo técnico razoável começa pela captura e termina com uma confirmação do utilizador:
- Captura: guardar a imagem original e os metadados, como data e evento, com consentimento e finalidade definidos.
- Pré-processamento: corrigir rotação, contraste e perspetiva. Uma imagem inclinada ou desfocada costuma prejudicar o reconhecimento.
- Extração: executar OCR e manter a confiança associada a cada campo, em vez de tratar toda a saída como igualmente fiável.
- Normalização: padronizar telefones, e-mails e nomes sem apagar o valor original reconhecido.
- Revisão: apresentar os campos para confirmação, sobretudo quando a confiança é baixa ou há dados ambíguos.
- Associação: ligar o contacto a notas, fotografias de produtos e empresa, mantendo a origem de cada informação.
O motivo para preservar a imagem e o texto original é simples: extração automática não é verdade absoluta. Se o sistema transformar um “8” num “B” num telefone, a pessoa precisa de conseguir corrigir o campo e, idealmente, perceber de onde veio o valor. Guardar proveniência também ajuda a diagnosticar erros e melhorar o processo.
Exemplo funcional: validar e normalizar campos extraídos
O exemplo abaixo não representa código da Bootly. É uma pequena etapa que eu incluiria num protótipo TypeScript após receber os campos do OCR. Ela limpa espaços, valida o e-mail e sinaliza campos que precisam de revisão. A normalização telefónica é deliberadamente conservadora: sem país ou biblioteca especializada, não é seguro inventar um indicativo.
type OcrField = {
value: string;
confidence: number;
};
type ExtractedContact = {
name?: OcrField;
company?: OcrField;
email?: OcrField;
phone?: OcrField;
};
type ContactDraft = {
name: string | null;
company: string | null;
email: string | null;
phone: string | null;
needsReview: string[];
};
function clean(value?: OcrField): string | null {
const text = value?.value.replace(/\s+/g, " ").trim();
return text || null;
}
function normalizeEmail(value: string | null): string | null {
if (!value) return null;
const email = value.trim().toLowerCase();
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email) ? email : null;
}
function normalizePhone(value: string | null): string | null {
if (!value) return null;
// Mantém apenas dígitos e o sinal + inicial.
const compact = value.replace(/[^\d+]/g, "");
const phone = compact.startsWith("+")
? `+${compact.slice(1).replace(/\+/g, "")}`
: compact.replace(/\+/g, "");
return phone.length >= 7 ? phone : null;
}
function createDraft(input: ExtractedContact): ContactDraft {
const needsReview: string[] = [];
const fields = Object.entries(input);
for (const [key, field] of fields) {
if (field && field.confidence < 0.85) {
needsReview.push(key);
}
}
const rawEmail = clean(input.email);
const rawPhone = clean(input.phone);
const email = normalizeEmail(rawEmail);
const phone = normalizePhone(rawPhone);
if (rawEmail && !email) needsReview.push("email");
if (rawPhone && !phone) needsReview.push("phone");
return {
name: clean(input.name),
company: clean(input.company),
email,
phone,
needsReview: [...new Set(needsReview)]
};
}
const draft = createDraft({
name: { value: " Ana Costa ", confidence: 0.96 },
company: { value: "Exemplo, Lda.", confidence: 0.91 },
email: { value: "ANA@EXEMPLO.PT", confidence: 0.98 },
phone: { value: "+351 912 345 678", confidence: 0.72 }
});
console.log(draft);
O resultado mantém os casos duvidosos visíveis para revisão em vez de “corrigi-los” silenciosamente. Num produto real, eu também guardaria o valor bruto, a versão normalizada, a confiança, a data de processamento e a versão do motor de OCR. Isso permite reprocessar dados e comparar resultados quando o modelo ou as regras mudarem.
Bootly, CRM, notas e apps de digitalização: o que comparar
A Bootly entra num espaço que já tem alternativas, embora nem todas resolvam o mesmo problema. Um CRM, como HubSpot, é mais adequado quando o objetivo principal é gerir o ciclo comercial, tarefas e histórico de clientes. Notion ou Airtable podem servir para criar uma base flexível, mas exigem que a equipa desenhe o modelo e mantenha a disciplina de preenchimento.
Aplicações de digitalização de cartões focam-se sobretudo em converter uma imagem em contacto. Google Lens pode ajudar a copiar texto de uma imagem, mas isso não equivale, por si só, a gerir relações entre contactos, notas e produtos ao longo de um evento. A diferença que a iServices terá de demonstrar é a qualidade do fluxo completo: captura rápida, correção simples, pesquisa e exportação para ferramentas que a equipa já usa.
Eu avaliaria qualquer solução com perguntas práticas: funciona sem rede? Exporta os dados em formatos comuns? Permite corrigir OCR em poucos toques? Tem pesquisa por empresa, evento e nota? Evita duplicados sem fundir contactos errados? A fonte não confirma se a Bootly oferece estas capacidades; são critérios que considero essenciais antes de a adotar numa equipa.
Privacidade e arquitetura: decisões que não podem ficar para depois
Cartões de visita contêm dados pessoais. Fotografias de stands podem incluir outras pessoas, e notas comerciais podem revelar informação confidencial. Uma aplicação de captura precisa de explicar para que usa os dados, quem lhes pode aceder, por quanto tempo os mantém e se imagens ou textos são enviados a serviços externos de processamento.
Do ponto de vista de engenharia, eu definiria a política de retenção antes de escolher o fornecedor de OCR. Também separaria permissões por equipa, usaria encriptação em trânsito e em repouso, manteria registos de acesso e permitiria eliminar um registo e os respetivos ficheiros associados. Se houver processamento em terceiros, a equipa deve entender os termos, a localização e a retenção aplicáveis.
Outra decisão importante é o modo offline. Em pavilhões, a rede pode ser instável. Uma app que só funciona com ligação constante cria atrito precisamente no momento de maior uso. Uma estratégia possível é guardar a captura localmente, encriptada, e sincronizar depois; mas isso exige resolver conflitos, expiração de sessão e eliminação segura dos dados locais.
Na Prática: como avaliar uma ferramenta de captura numa feira
Antes de migrar contactos para uma nova plataforma, eu faria um piloto controlado com uma equipa pequena. O objetivo não é provar que o OCR consegue ler um cartão perfeito. É descobrir se a solução melhora o trabalho depois da captura.
- Defina o resultado: por exemplo, reduzir o tempo entre a conversa e o primeiro seguimento comercial, sem perder o contexto.
- Escolha uma amostra real: inclua cartões em idiomas diferentes, imagens com reflexo e contactos anotados manualmente.
- Meça a correção: registe quantos campos exigem edição e quais erros se repetem. Um valor médio de precisão pode esconder falhas críticas em e-mails.
- Teste a recuperação: peça a alguém que encontre, mais tarde, um contacto usando uma nota, empresa ou produto, sem saber onde o registo foi guardado.
- Teste a saída: confirme exportação, cópia de segurança e integração com o CRM ou sistema de vendas existente.
- Revise segurança e retenção: verifique acessos, sincronização, política de eliminação e subprocessadores antes de usar dados reais em escala.
Eu compararia os resultados com o processo atual, não apenas com uma demonstração comercial. Se a equipa continua a copiar tudo manualmente para o CRM no dia seguinte, a captura automatizada pode estar apenas a deslocar o trabalho. O ganho aparece quando os dados chegam utilizáveis ao próximo passo do fluxo.
Erros comuns ao implementar OCR e gestão de contactos
- Tratar a confiança do OCR como certeza: um campo reconhecido com confiança baixa deve ser revisto. E-mail e telefone merecem validações específicas.
- Apagar o original após normalizar: sem o texto ou imagem de origem, fica difícil corrigir e auditar um erro.
- Deduplicar apenas pelo nome: duas pessoas podem ter o mesmo nome, e uma mesma empresa pode aparecer com abreviações diferentes. Use vários sinais e ofereça confirmação antes de fundir registos.
- Enviar tudo para a IA: não é necessário processar imagens e dados pessoais sem uma finalidade concreta. Minimize o que é enviado e documente o fluxo.
- Ignorar interoperabilidade: dados presos numa aplicação viram dívida operacional. Exporte contactos e notas em formatos utilizáveis e teste a exportação antes de depender da ferramenta.
- Automatizar sem desenhar a revisão: se corrigir um campo der mais trabalho do que digitá-lo, a equipa vai abandonar o sistema. A interface de revisão é parte central do produto.
O que a apresentação da Bootly pode significar para equipas de desenvolvimento
O anúncio da iServices aponta para um caso de uso concreto de IA aplicada: reduzir trabalho administrativo após eventos profissionais. Gosto desse enquadramento porque o valor pode ser medido em tempo poupado, dados recuperáveis e seguimentos feitos com contexto, em vez de depender apenas de uma demonstração impressionante de reconhecimento.
A iServices Apps, unidade de desenvolvimento de software da empresa, é apresentada como responsável por aplicações móveis, plataformas digitais e soluções tecnológicas. Ainda assim, a informação divulgada não permite avaliar desempenho, integrações ou segurança da Bootly. Para uma decisão de adoção, eu esperaria detalhes técnicos e testaria o produto com dados e condições próximas das reais.
FAQ sobre OCR e a aplicação Bootly
O que é a Bootly?
Segundo o Sapo.pt, é uma aplicação da iServices para centralizar contactos, produtos e informação recolhida em feiras profissionais, usando OCR e Inteligência Artificial. As funcionalidades específicas não foram detalhadas na informação de referência.
OCR substitui a revisão manual de cartões de visita?
Não de forma segura em todos os casos. Reflexos, baixa resolução, fontes incomuns e cartões em vários idiomas podem causar erros. O melhor fluxo combina extração automática com revisão dos campos incertos.
Como comparar a Bootly com um CRM?
Compare o fluxo completo: captura, associação de notas, pesquisa, deduplicação, exportação e integração. Um CRM pode ser melhor para gerir vendas; uma ferramenta de eventos pode facilitar a recolha inicial. A escolha depende de onde está o maior atrito da equipa.
Que cuidados de privacidade devo ter ao usar OCR na nuvem?
Confirme que dados são enviados, quem os processa, quanto tempo são mantidos, onde ficam armazenados e como podem ser eliminados. Também verifique permissões de equipa, encriptação e condições contratuais do fornecedor.
Que métrica usar num piloto de OCR para eventos?
Meça o tempo até ao seguimento, a proporção de campos corrigidos, a taxa de contactos duplicados e o sucesso na recuperação de informação. A precisão isolada do OCR não mostra se a ferramenta melhorou o processo comercial.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.