Portal de Conciliação · REFIS 2026 · Estado do Espírito Santo
O portal de conciliação da dívida ativa do Espírito Santo já existia. Mas com a chegada do novo programa de refinanciamento, nosso desafio ficou imediatamente claro: evitar que o que ocorreu no REFIS 2025 se repetisse.
O REFIS é o maior programa de renegociação de dívidas fiscais do estado — com alta concentração de acessos em um período crítico e curtíssimo. Em 2025, o sistema simplesmente não aguentou.
Diferente do que se imaginava inicialmente, o maior problema não estava na etapa de assinatura do acordo. Estava muito antes: na jornada de negociação em si, marcada por lentidão estrutural, quedas constantes do sistema e falhas críticas de sessão.
O desafio não era apenas assinar o acordo. Era conseguir sobreviver à jornada sem que o sistema caísse ou a sessão fosse perdida no meio do caminho.
Mapeamos quatro problemas estruturais que travavam o sistema e a experiência do contribuinte — um ciclo onde cada falha retroalimentava a próxima. A gravidade ficou registrada nos próprios chamados internos abertos ao longo da operação de 2025.
O volume de acessos derrubava a infraestrutura durante os picos. O sistema ficava processando indefinidamente — sem timeout, sem mensagem de erro, sem feedback. Contribuintes esperavam mais de 15 minutos por uma resposta que nunca chegava. Nos dias mais críticos, o banco de dados atingiu 100% de uso de CPU, tornando o portal completamente inoperante.
Sem feedback do sistema, os usuários abriam, em média, 5 simulações de negociação antes de efetivar um acordo. Cada tentativa realizava uma nova consulta pesada ao banco de dados — retroalimentando diretamente a lentidão.
Os usuários solicitavam a negociação, mas o sistema não deixava claro se a ação tinha sido registrada. Sem confirmação visual, a reação natural era tentar de novo — e de novo — até o portal cair.
Em um ambiente instável, quem perdia a conexão ou tinha a sessão interrompida precisava recomeçar do zero. Um problema técnico virava uma experiência de frustração completa — gerando mais volume desnecessário no servidor.
O sistema não conseguia se comunicar bem com o usuário - o que agravava o número de consultas ao ponto de inoperar o sistema.
Para entender exatamente onde o fluxo quebrava, direcionamos nossa pesquisa para quem esteve na linha de frente do caos no ano anterior. Não havia dados de usabilidade estruturados — então fomos buscar os dados onde eles estavam.
Conversas com a Procuradoria Geral do Estado para entender os gargalos de
atendimento e as queixas mais recorrentes. Quem opera o programa no lado institucional enxerga os
problemas de uma ângulo que nenhum log de sistema captura.
O relato principal era
consistente: os contribuintes simplesmente não sabiam se o que tinham feito havia funcionado.
Coleta de relatos qualitativos com o time de Customer Success da Coreplan, que atuou diretamente segurando as pontas no REFIS 2025. Esses relatos foram a principal fonte primária do projeto.
Mergulhamos no histórico de tickets e registros internos do REFIS de 2025. O volume
era alto — e para extrair padrões com agilidade, utilizei IA generativa para categorizar os chamados por tipo de falha, frequência e momento da
jornada. O processo que levaria dias em análise manual foi reduzido a horas de
validação.
Espaços reservados para comparação visual entre a experiência anterior e a solução implementada no REFIS 2026.
Por questões de arquitetura e infraestrutura, a simulação dos valores da dívida continuou rodando via JOB — um processamento em segundo plano que não podia ser eliminado no curto prazo.
A tentação seria tentar otimizar tecnicamente esse processamento. Mas a pesquisa apontou para outra direção: o problema não era quanto tempo o sistema demorava. Era que o usuário não sabia que o sistema estava trabalhando.
Mudamos radicalmente a forma como o sistema lidava com a expectativa do usuário. Implementamos uma confirmação imediata de solicitação na interface, atrelada a uma esteira de comunicação por e-mail em duas etapas:
O usuário recebe um e-mail de confirmação de solicitação — sabe que o sistema registrou.
Quando o JOB conclui o cálculo, o usuário recebe um e-mail com o resultado da simulação e o link direto para efetivar.
"Ainda que o resultado não fosse instantâneo, o usuário agora sabia que o resultado chegaria."
Essa previsibilidade matou a ansiedade. E a ansiedade era a origem do comportamento que derrubava o sistema — os usuários pararam de sobrecarregar o banco de dados com requisições repetidas porque tinham a certeza de que a informação chegaria por e-mail. Uma mudança de UX resolveu um problema de infraestrutura.
Ajustamos a jornada para refletir a nova realidade da comunicação assíncrona, eliminando a necessidade do usuário ficar monitorando o portal aguardando uma resposta que o sistema não conseguia entregar em tempo real.
O fluxo de espera foi completamente abstraído. O usuário sai do portal com a certeza de que sua vez está garantida — e volta apenas quando há algo concreto para fazer. A carga no servidor caiu proporcionalmente.
Com o time de produto (PGE + Coreplan):
As entrevistas com a Procuradoria e com o CS foram conduzidas em conjunto com o PM do projeto. As
descobertas foram documentadas e apresentadas ao time técnico antes de qualquer decisão de interface —
garantindo que as escolhas de UX fossem viáveis dentro das restrições reais de arquitetura.
O "eu" virou "nós" desde o diagnóstico. Isso importa porque as restrições técnicas que moldaram o redesign só se tornaram visíveis quando o time conversou cedo o suficiente.
Com o time de desenvolvimento:
O redesign da jornada exigia nova lógica de backend — o JOB de cálculo precisava disparar eventos
para o sistema de e-mail. Documentei no Figma o fluxo de estados com anotações
de comportamento, não apenas visual.
simulacao_solicitada →
email_confirmacaosimulacao_concluida →
email_resultado + link de retorno
A implementação foi fiel à proposta de UX porque o time entendeu o por que de cada decisão — não apenas o o quê. Isso eliminou retrabalho e garantiu que a lógica chegasse completa ao ar no prazo.
Devido às restrições de calendário para a aprovação e o lançamento do REFIS 2026, não realizamos testes de usabilidade prévios com usuários finais.
Nos casos de governo, isso é mais comum do que parece. O ciclo político e administrativo impõe janelas de entrega que simplesmente não permitem ciclos completos de discovery.
A base, no entanto, era sólida: as decisões de design foram construídas diretamente sobre a pesquisa das falhas de 2025 — com rastreabilidade direta entre cada decisão e um dado ou um relato de campo.
A validação real ocorreu na prática, com o portal no ar, monitorando a absorção do fluxo pelos usuários em tempo real. Os números confirmaram o diagnóstico — e a estratégia.
A estratégia de focar na clareza da informação e na gestão de expectativas por e-mail salvou a operação do colapso — e entregou o maior REFIS da história do estado.
Com a certeza de que a informação chegaria por e-mail, os usuários pararam de sobrecarregar o sistema com requisições repetidas. O portal se manteve de pé durante todo o período crítico de adesão — algo que não havia acontecido no REFIS anterior. Uma mudança de comunicação resolveu um problema que parecia ser de infraestrutura.
Nem sempre o problema é onde parece. O sistema "lento" era, na realidade, um sistema silencioso — e usuários em silêncio reagem com repetição. A lição central: comunicação é infraestrutura. Quando o usuário sabe o que está acontecendo, ele para de criar o caos que ele próprio tanto teme.
Sobre o processo: a IA acelerou a análise de chamados que, manualmente, consumiria dias. Sobre o design: nenhum componente bem construído resolve um fluxo fundamentalmente quebrado — mas um fluxo bem desenhado falha silenciosamente se os componentes de feedback forem descuidados. Os dois lados importam.