Pessoas que deveriam compartilhar uma visão tinham visões diferentes, porque um arquivo estava atualizado e o outro não. A área de dados não conseguia publicar um indicador sem antes discutir qual número estava certo.
A BT Créditos tirou o back-office das planilhas e do e-mail, e a fotografia mensal parou de custar três dias
A BT Créditos compra os direitos sobre créditos de processos trabalhistas e antecipa o valor ao trabalhador. A área de dados nasceu em cima de planilhas departamentais e de aprovações disparadas por e-mail. Hoje os processos que ainda não estavam no sistema core rodam num sistema feito sob medida, e o relatório do mês está pronto na hora em que é aberto.
Uma compradora de créditos judiciais cuja margem depende de o dado estar completo, consistente e atual.
Cada crédito tem um valor, uma fase, uma parte contrária, documentos e uma decisão sobre se e quanto antecipar. Originação, análise jurídica, financeiro e cobrança precisam olhar os mesmos números.
Cessão de crédito trabalhista
2019Fundada, número da empresa em 2026
~11 milProcessos transformados em crédito, número da empresa em 2026
~120Profissionais, número da empresa em 2026
2–3 dias → 0Fotografia mensal da área de dados, relato da entrevista de 2022
2–3 dias → 0Fotografia mensal da área de dadosLevava dois a três dias entre receber planilhas e resolver inconsistências, segundo o responsável pela área de dados. Hoje o dado já está no sistema quando o relatório é aberto. Não cronometrado.
~3h vs 2 mesesTempo até a primeira versão funcionalEstimativa do próprio entrevistado para a primeira versão do sistema de processos internos, comparada ao que ele calcula que levaria para programar com backend, front-end e banco de dados.
1 diaDe resistênciaA resistência do time caiu no momento em que testou o novo fluxo, segundo a entrevista. O case publicado em 2022 falou em "um único dia".
2 → 1Verificações duplicadas, agora uma de cadaO redesenho da aprovação de contrato expôs dois revisores conferindo os mesmos campos. Cada um passou a conferir só os seus.
“A gente começou a criar a área de dados aqui dentro e o que acontece: algumas informações bastante relevantes estavam espalhadas em planilhas entre as áreas da empresa. Então a gente tinha vários departamentos controlando informações que às vezes eram as mesmas, ou às vezes se complementavam, mas ainda em planilhas. A gente tem o sistema interno, um sistema proprietário para controlar processos, mas nem todos os processos estavam nesse sistema.”
Bruno PazettiHead of Analytics, BT Créditos, no case publicado em 2022
AntesDepois
- Uma planilha por departamento, versões sobrepostasUm banco relacional alimentando todos os times com os mesmos registros
- Fotografia mensal montada à mão em dois a três diasO relatório lê do banco ao vivo na hora em que é aberto
- Aprovação de contrato iniciada por e-mail, lacunas cobradas depoisUm formulário que não envia enquanto os campos obrigatórios não estiverem completos e válidos
- Dois revisores conferindo os mesmos campos sem saberCada revisor confirma só os campos atribuídos a ele
- Aviso de alteração na mão, ou esquecidoE-mail dispara quando o registro muda de etapa; comentários ficam no registro
O sistema proprietário de controle de processos da empresa ficou. Ele já rodava os processos maduros e estáveis. O novo sistema ficou com os processos que ainda não estavam digitalizados e virou o lugar onde um processo é desenhado, testado e revisado enquanto ainda muda. Quando o processo para de mudar, o modelo já existe e pode ser levado direto para o sistema core.
O gargalo é operacional, não comercial
A BT Créditos compra os direitos sobre créditos de processos trabalhistas em andamento e antecipa parte do valor esperado ao reclamante. Também antecipa honorários ao advogado. Segundo os números que a própria empresa publica no site, foi fundada em 2019, já transformou cerca de 11 mil processos em crédito, antecipou R$ 3,1 bilhões e tem cerca de 120 profissionais na equipe. Os critérios mínimos publicados são processo acima de R$ 50 mil, decisão favorável em duas instâncias e empresa ré financeiramente estável.
O negócio é uma carteira de créditos judiciais. Cada crédito tem um valor, uma fase, uma parte contrária, um conjunto de documentos e uma decisão sobre se e quanto antecipar. A margem depende de precificar bem essa decisão, e precificar depende de o dado de cada processo estar completo, consistente e atual nos times que o tocam: originação, análise jurídica, financeiro, cobrança.
Por isso o gargalo é operacional, não comercial. Quando uma empresa assim cresce, o número de processos em andamento cresce mais rápido do que o número de pessoas capazes de reconciliá-los na mão. Se a reconciliação mora em planilhas e caixas de e-mail, a área de dados passa a refazer a mesma foto todo mês em vez de melhorar a precificação.
Um sistema core para parte da operação, e nada estruturado para o resto
É o responsável pela área de dados descrevendo o que encontrou ao entrar na empresa, cerca de um ano antes da entrevista. A primeira tentativa dele foi montar os indicadores mais básicos consumindo essas planilhas diretamente. Quebrou na segunda rodada.
“A gente começou a criar a área de dados aqui dentro e o que acontece: algumas informações bastante relevantes estavam espalhadas em planilhas entre as áreas da empresa. Então a gente tinha vários departamentos controlando informações que às vezes eram as mesmas, ou às vezes se complementavam, mas ainda em planilhas. A gente tem o sistema interno, um sistema proprietário para controlar processos, mas nem todos os processos estavam nesse sistema. Então a gente tinha parte da informação no sistema, parte distribuída em planilhas entre as áreas.”
Sentar com duas áreas para tirar uma foto do mês significava esperar as planilhas chegarem, tirar dúvidas, achar células com dado inconsistente e voltar. A foto já estava atrasada antes de ficar pronta.
O pedido chegava por e-mail, muitas vezes com informação faltando, e o que faltava era cobrado em mensagens seguintes. Depois o pedido passava por uma cadeia de revisores. Ninguém enxergava a cadeia de ponta a ponta, e foi assim que dois desses revisores acabaram verificando os mesmos campos sem saber.
O padrão por trás das três falhas é o mesmo. A empresa tinha um sistema core para parte da operação e nada estruturado para o resto, e "o resto" era exatamente onde a área de dados precisava trabalhar. Programar esses processos no sistema core era possível, mas lento; deixá-los em planilha significava que o dado nunca seria confiável.
Item a item, o que fazia cada trabalho antes e o que faz hoje
| O que fazia isso antes | O que faz hoje |
|---|---|
| Uma planilha por departamento, cada uma com sua versão de informações sobrepostas | Um banco relacional com tabelas e relações definidas uma vez, alimentando todos os times com os mesmos registros |
| Fotografia mensal manual: receber arquivos, cobrar lacunas, limpar células inconsistentes | O relatório lê do banco ao vivo; nada é coletado à mão |
| Aprovação de contrato pedida por e-mail, informação completada em várias mensagens | Formulário com campos obrigatórios e máscaras; o pedido não sai incompleto nem com valor inválido |
| Revisão sequencial em que cada pessoa reconferia o que a anterior tinha conferido | Cada revisor vê e confirma só os campos atribuídos a ele, num pipeline em Kanban |
| Alguém atualiza a planilha e avisa o próximo na mão, ou esquece | Notificação por e-mail disparada automaticamente quando o registro muda de etapa |
| Contexto do pedido espalhado em threads de e-mail | Comentários ficam no próprio registro, visíveis para todo mundo que o toca entre os departamentos |
O que não foi trocado. O sistema proprietário de controle de processos da empresa ficou. Ele já rodava os processos maduros e estáveis. O novo sistema ficou com os processos que ainda não estavam digitalizados e virou o lugar onde um processo é desenhado, testado e revisado enquanto ainda muda. Quando o processo para de mudar, o modelo já existe e pode ser levado direto para o sistema core. O entrevistado descreveu isso como o segundo motivo de manter o sistema: é o campo de prova do que o core vai absorver depois.
O fluxo de aprovação de contrato, de ponta a ponta
- 1Formulário é preenchidoPessoa
Alguém do time abre o formulário e preenche os dados do contrato. Campos obrigatórios e máscaras de valor travam o envio até o dado estar completo e válido.
- 2Registro entra na primeira revisãoAutomático
O registro é criado no banco e entra na primeira etapa de revisão.
- 3Primeiro revisor confere os campos delePessoa
Notificado por e-mail, confere só os campos daquela etapa e confirma ou comenta no registro.
- 4Registro avançaAutomático
O registro avança para a segunda etapa e o segundo revisor é notificado.
- 5Segundo revisor confere os campos delePessoa
Confere só os campos dele e aprova ou devolve com comentário.
- 6Quem pediu é notificadoAutomático
Quem pediu é notificado do resultado.
- 7Dado chega aos painéisAutomático
O dado dos contratos aprovados fica disponível nos painéis da área de dados sem etapa de extração.
Os elos difíceis são o 1 e os de 3 a 5. O 1 é onde o processo antigo vazava: um e-mail com informação faltando custava várias idas e voltas antes de a revisão começar. Os de 3 a 5 são onde o trabalho duplicado estava escondido, e só ficou visível quando a cadeia foi desenhada como pipeline em vez de uma sequência de e-mails encaminhados. As automações no meio são simples. As decisões de desenho em volta delas é que tiraram o desperdício.
Cada número, com a base ao lado
| Indicador | Resultado | De onde sai |
|---|---|---|
| Fotografia mensal da área de dados | De dois a três dias para nenhum tempo gasto coletando | Descrição do entrevistado da rotina antiga e da atual. Não cronometrado |
| Tempo até a primeira versão funcional do sistema de processos internos | Cerca de três a quatro horas, contra estimativa de um a três meses para programar | Estimativa do próprio entrevistado para os dois lados; ele fechou em "três horas contra dois meses". O case publicado arredondou o lado programado para três meses |
| Adoção do time | Resistência caiu assim que as pessoas testaram | Relato do entrevistado; o case publicado diz "um único dia" |
| Aprovação de contrato | Dois revisores conferindo os mesmos campos, agora cada um confere só os seus | Relato do entrevistado sobre o redesenho. Horas economizadas não medidas |
"Três horas contra dois meses" é a estimativa de uma pessoa nos dois lados. As três horas são a lembrança do entrevistado da primeira versão, antes das rodadas de revisão. Os dois meses são a estimativa dele para programar a mesma coisa com backend, front-end e banco, e ele deu como faixa: pelo menos um mês, talvez dois ou três. Se dois meses forem lidos como cerca de 40 dias úteis de oito horas, a comparação é de cerca de três horas contra cerca de 320, mas essa leitura é nossa, não dele.
"Centenas de vezes mais rápido" não é um número medido. O entrevistado abriu com essa frase e disse na sequência que nunca parou para fazer a conta exata. Ela aparece neste case só como impressão dele, não como resultado.
"Até três dias" mede a fotografia antiga, não o relatório novo. Os três dias eram o tempo de coletar e limpar. O número novo não é um tempo menor; é que a etapa de coletar deixou de existir, porque o dado já está no banco quando o mês fecha.
O que este case não mede
Vale dizer, porque é o que normalmente aparece inflado.
Os dois números de tempo vêm de uma entrevista com o responsável pela área de dados. Nenhum foi cronometrado, registrado ou auditado.
O case não mede custo por processo, por contrato aprovado ou por relatório produzido, nem antes nem depois.
O entrevistado disse que o redesenho "vai colocando horas de time de volta" e disse explicitamente que não saberia mensurar quantas. Nenhuma contratação evitada ou função alterada é reivindicada.
A entrevista e o case publicado são de meados de 2022. Os números da empresa (cerca de 11 mil processos, R$ 3,1 bilhões antecipados, cerca de 120 profissionais) são do site da própria empresa em 2026. O que o sistema cobre hoje não foi reverificado.
O case de 2022 o nomeou como Head of Analytics. Fontes públicas consultadas em 2026 não confirmam se ele ainda ocupa a função ou ainda está na empresa.
O sistema cobre os processos que não estavam no sistema core da empresa. O case não afirma que o core foi substituído e não descreve o que roda nele.
Em 2022 o sistema foi montado pelo próprio responsável de dados do cliente. No arranjo atual, construir, configurar e manter ficam com a Jestor; o resultado operacional descrito aqui é o mesmo, a divisão de trabalho não.
O volume que entra na Justiça do Trabalho cresce mais rápido que a capacidade de reconciliar na mão
| Indicador | Número | Fonte |
|---|---|---|
| Casos novos no Poder Judiciário em 2025 | 40,9 milhões, maior volume desde 2004 | CNJ, dados prévios do Justiça em Números, divulgados em junho de 2026 |
| Tempo médio dos processos baixados em 2025 | 2 anos e 4 meses; 1 ano e 6 meses sem as execuções fiscais | CNJ, mesmos dados prévios |
| Casos novos na Justiça do Trabalho em 2024 | Cerca de 3,6 milhões, 16,1% acima de 2023 | TST, conforme reportado pelo ConJur em setembro de 2025 |
| Organizações em que planilhas continuam integrais à operação financeira | 90% | AutoRek, pesquisa com 500 gestores financeiros seniores nos EUA e Reino Unido, outubro de 2024 |
Um crescimento de 16,1% em casos novos num ano é um crescimento de 16,1% no universo que uma compradora de créditos precisa analisar, precificar e acompanhar. Planilha departamental não escala nesse ritmo sem duplicar gente.
Um crédito que leva anos para ser pago é um registro que muda de fase, valor e risco muitas vezes antes de fechar. Cada mudança precisa chegar a todos os times ao mesmo tempo, o que é exatamente o que as planilhas separadas não faziam.
O case publicado em 2022 falava em "cerca de 998 dias" para uma ação média. Não foi localizada fonte primária para esse número e ele não aparece aqui. Os dados do CNJ acima medem o tempo dos processos baixados no ano, que é uma coisa diferente de "duração de uma ação trabalhista média", e são usados só com essa ressalva.
O sistema é feito sob medida e a responsabilidade por ele continua nossa
Em 2022 o responsável de dados da BT Créditos montou a primeira versão sozinho numa tarde. A pergunta que importa no ano dois é outra: quem mexe quando o processo muda, quando essa pessoa sai, ou quando o próximo departamento pede o fluxo dele. Um sistema sob medida do qual ninguém é responsável é uma planilha com interface melhor, e volta a ser planilha em três anos.
Um construtor toca cada pedido do começo ao fim, com um sempre em execução.
Um novo fluxo, uma nova automação ou um novo relatório entram pelo mesmo canal, sem virar projeto novo.
Se o que foi construído não está bom, ele é refeito. Revisões ilimitadas dentro da assinatura.
Assento nunca é a régua de cobrança, o que importa quando originação, análise jurídica, financeiro e área de dados tocam a mesma operação.
As pessoas aprendem a usar o app delas como aprendem qualquer app, abrindo. Construir, configurar e manter continua do nosso lado.
Exportação completa a qualquer momento, por CSV e API. Conformidade SOC 2, sem taxa de saída. Dá para pausar em um clique e os sistemas continuam rodando.
Metodologia e fontes
A descrição do processo anterior, a fotografia de dois a três dias, a construção em três horas contra a estimativa de dois meses, o relato de adoção e o redesenho da aprovação de contrato vêm de uma entrevista gravada com o responsável pela área de dados da empresa, cruzada com o case que a Jestor publicou em julho de 2022. Nada disso foi auditado. Onde a entrevista e o case publicado divergem (dois meses contra três meses para programar; "assim que testaram" contra "um único dia"), as duas versões estão declaradas.
Ano de fundação, processos atendidos, volume antecipado e tamanho da equipe vêm do site da própria empresa (btcreditos.com.br) em setembro de 2026. São autodeclarados e quatro anos mais novos que a entrevista.
CNJ, dados prévios do relatório Justiça em Números, ano-base 2025, divulgados em junho de 2026. TST, casos novos na Justiça do Trabalho em 2024, conforme reportado pelo ConJur em 13 de setembro de 2025. AutoRek, pesquisa com 500 gestores financeiros seniores nos EUA e Reino Unido, outubro de 2024, conforme comunicado da empresa.
A frase "centenas de vezes mais rápido" é citada como impressão, não usada como resultado, porque o entrevistado disse na mesma fala que nunca fez a conta. O "998 dias" de duração média de uma ação, do case original, não tem fonte primária localizada e ficou de fora. O comentário do entrevistado de que "em duas horas você faz um CRM" é uma ilustração, não um processo da BT Créditos, e também ficou de fora.