Projetos
B2B · Fiscal · Backoffice

Emissão em Lote
de Notas Fiscais

Quando a tecnologia não escala junto com o negócio, o operador paga o preço. Mais de 3.000 notas por ciclo, emitidas uma a uma, por duas pessoas. O problema não era falta de vontade — era ausência de produto.

UX Research Discovery B2B · Fiscal Backoffice Eficiência Operacional
60%
menos etapas no fluxo
3.1×
redução de cliques por operação
1200×
mais rápido em alto volume
100%
satisfação no piloto

O negócio cresceu. O produto ficou parado.

Grandes franquias que operam com alto volume de trocas e devoluções precisam emitir centenas, às vezes milhares, de notas fiscais ao final de cada ciclo comemorativo. O sistema existia. O fluxo existia. Mas havia sido desenhado para operação unitária.

Dois operadores. Mais de 3.000 notas por período. Dois minutos por nota. Mais de 100 horas de trabalho manual concentradas em poucos dias, exatamente quando o time já estava exausto pelo pico operacional.

A situação era agravada pela migração de sistema em curso: as franquias comparavam ativamente a nova ferramenta com a anterior. Qualquer sensação de regressão aumentava a resistência e o custo político do projeto.

Execução linear em operação que pedia escala.

O diagnóstico inicial apontava para "lentidão do sistema". Mas ao aproximar, o problema era estrutural: a ferramenta exigia microexecução manual em uma tarefa repetitiva, previsível e completamente passível de agrupamento.

Sintomas visíveis
  • Emissão individual, nota a nota
  • Nenhuma visão consolidada do lote
  • Erros exigiam reprocessamento manual
  • Em estados como RJ, emissão por consumidor multiplicava o retrabalho
  • Workarounds constantes para compensar a ferramenta
Impacto real
  • +100h de trabalho por ciclo
  • Alta dependência de dois perfis específicos
  • Risco operacional concentrado
  • Percepção de regressão tecnológica
  • Escalabilidade zero em crescimento
Insight central

O sistema obrigava execução linear de uma tarefa que era, por natureza, volumétrica e simultânea. A ferramenta exigia microexecução onde a operação precisava de escala.

Não era acelerar a emissão. Era mudar a lógica dela.

O objetivo não era tornar a emissão individual mais rápida. Era redesenhar a jornada para que o operador deixasse de ser um executor repetitivo e passasse a ser um gestor de decisão — alguém que configura, supervisiona e valida, não quem clica centenas de vezes seguidas.

  • Escalabilidade: eliminar repetição desnecessária e viabilizar operação em lote sem exigir perfis técnicos específicos.
  • Centralização: visão única do conjunto — status, erros e pendências em um único lugar.
  • Autonomia com segurança: cada nota mantém individualidade fiscal, prevenindo falhas em cadeia em contextos regulatórios sensíveis.

Discovery, definição e entrega do fluxo completo.

Atuei como designer responsável por todo o ciclo do projeto, da imersão operacional ao handoff para engenharia. Conduzi o discovery, defini a arquitetura da solução, prototipei e validei com operadores reais antes da implementação final.

Trabalhei diretamente com franquias, coordenadores de praça, stakeholders de produto e a área de implantação, transitando entre perspectivas muito diferentes sobre o mesmo problema.

Entender o que faziam — e por que faziam assim.

Discovery intensivo de duas semanas. Mais do que mapear etapas, busquei compreender comportamento: como organizavam os pedidos antes de começar, onde erravam com mais frequência e em que momento o processo "quebrava".

1

Imersão com operadores reais

Observação direta do fluxo de trabalho durante um ciclo de emissão. Entrevistas com franquias e CPs para entender a lógica real de operação, não a documentada, mas a que acontecia na prática.

2

Mapeamento de workarounds

Cada desvio do fluxo oficial era um sinal. Catalogamos os workarounds recorrentes como sintomas de onde a ferramenta não refletia a realidade operacional.

3

Alinhamento regulatório por estado

Entender os limites fiscais, especialmente o RJ, antes de desenhar qualquer solução. Não era possível simplificar o que era obrigação legal; era preciso simplificar tudo ao redor.

4

Redesenho da arquitetura da tarefa

Não um redesign visual, uma reorganização estrutural do fluxo. A lógica de execução foi reconstruída com base na realidade operacional mapeada.

5

Validação antes do lançamento

Piloto com franquias reais. Feedback coletado sistematicamente. Ajustes realizados antes da implementação definitiva.

Interface como camada de gestão, não de execução.

A solução foi construída em torno de uma lógica de emissão em lote que preservava a autonomia individual de cada nota, garantindo conformidade fiscal sem sacrificar a eficiência em volume.

  • Visão consolidada do lote: painel único com status de cada nota, pendências e erros — sem precisar abrir item por item.
  • Seleção múltipla inteligente: agrupamento por critérios operacionais relevantes, sem perder rastreabilidade individual.
  • Redução de etapas manuais: o que exigia dezenas de cliques passou a exigir uma decisão e uma confirmação.
  • Feedback granular por nota: erros são isolados e reportados individualmente, sem paralisar o lote inteiro por uma inconsistência pontual.
  • Estrutura à prova de erro em cascata: especialmente relevante para o contexto do RJ, onde erros tinham alto custo de reprocessamento.

"Antes levávamos semanas para fechar esse volume. Agora entregamos antes do fim do mês."

— Operador de franquia, piloto de validação

"A rotina ficou mais leve. Ficou bem mais prático — até para quem não é da área."

— Coordenador de praça, feedback pós-lançamento

Os números contam parte da história.

60%
menos etapas no fluxo de emissão
3.1×
redução de cliques por operação
1200×
mais rápido em cenários de alto volume
100%
satisfação na validação com pilotos

Mas os números capturam só a eficiência. O impacto mais relevante foi comportamental: operadores foram liberados para outras funções. Horas extras deixaram de ser inevitáveis em picos. A dependência de perfis técnicos específicos caiu. O sistema, pela primeira vez, escalonou junto com a operação.

O que esse projeto ensina sobre produto de backoffice.

  • Workarounds são o produto real. Cada adaptação que o operador criava era uma funcionalidade que o sistema deveria ter. Mapeá-los foi mais revelador do que qualquer entrevista direta.
  • Complexidade regulatória não é desculpa para má UX. O RJ exigia emissão por consumidor — mas isso não impedia que a interface gerenciasse esse detalhe de forma transparente.
  • Redesenhar a arquitetura da tarefa é diferente de redesenhar a interface. A melhoria real não estava nos componentes visuais — estava em como a lógica de execução foi reorganizada.
  • Validação com operadores reais antes do lançamento salva retrabalho. O piloto revelou ajustes que nenhum protótipo teria capturado.
Princípio que guiou o projeto

Se a tecnologia não está escalando junto com o negócio, o problema é de produto — e ele vai além da interface.

Ver outros projetos

Quatro cases do setor financeiro — cada um com um problema diferente.

Ver todos os projetos Entrar em contato