Manual do usuário

Plataforma de Gestão e Inteligência de Recuperação de Crédito

Guia completo de uso do protótipo funcional da Fase 1.2: objetivo do produto, telas, funcionalidades, regras de negócio e dicionário de termos — para quem vai operar, validar ou avaliar o sistema.

Cooperativa: Sicoob União dos Vales Fase do projeto: 1.2 — Protótipo funcional frontend Data de referência dos dados: 09/09/2026 Versão do manual: 1.0
Introdução

1.Sobre a plataforma

O que este sistema é, para quem foi construído e qual problema ele resolve.

1.1 O que é a plataforma

Esta não é uma ferramenta simples de discagem ou de anotação de cobrança. É uma Plataforma de Gestão e Inteligência de Recuperação de Crédito: ela organiza, executa, acompanha, automatiza e analisa todo o processo de recuperação de crédito da cooperativa, unindo em um único histórico o trabalho de atendentes humanos e de agentes de Inteligência Artificial.

O sistema foi desenhado para responder rapidamente perguntas do dia a dia da operação de cobrança:

  • Quem eu preciso contatar hoje?
  • Quem já foi contatado e o que aconteceu?
  • Quem prometeu pagar — e quem quebrou a promessa?
  • Quanto da carteira já foi trabalhado neste período?
  • Qual atendente ou agente de IA está performando melhor?
  • Qual canal (telefone, WhatsApp, voz por IA) converte mais promessas em pagamento?

1.2 O conceito central

Todo o sistema gira em torno de um fluxo único, do dado importado até o acompanhamento do resultado:

Fluxo conceitual

Carteira → Régua → Cliente → Caso de Cobrança → Ação de Cobrança → Resultado → Acompanhamento

Um cliente pode ter várias dívidas/operações em aberto. A fila de trabalho nunca lista parcelas isoladas: ela é organizada pelo caso de cobrança do cliente, e o valor mostrado é o saldo vencido agregado — a soma de todas as dívidas vencidas daquele cliente. As dívidas individuais continuam disponíveis dentro do caso, na aba "Dívidas e operações".

1.3 A ação de cobrança é o elemento mais importante do sistema

Toda interação relevante com o cliente — ligação de um atendente, conversa por WhatsApp, ligação feita por um agente de IA por voz, mensagem enviada por um agente de IA, ou qualquer canal futuro — gera um registro de ação de cobrança. Humano e IA alimentam exatamente o mesmo histórico, o que permite comparar desempenho, auditar decisões e nunca perder contexto quando o caso muda de responsável ou de canal.

Uma ação registrada é imutável: ela nunca é editada livremente. Uma eventual correção entraria como um novo registro apontando para o original — essa tela ainda não existe nesta fase (ver seção 21).

1.4 Quem usa a plataforma — perfis

Cada perfil tem uma visão e um conjunto de permissões compatíveis com sua função. A estrutura organizacional Cooperativa → Agência existe desde o início do modelo de dados, permitindo segmentar carteira, usuários, clientes e indicadores.

PerfilEscopo de visãoUso típico
AdministradorConfiguração total do sistemaTI / configuração geral
Gestor de CobrançaToda a carteiraEstratégia, réguas, agentes de IA, indicadores
SupervisorSuas equipesAcompanha equipe, distribui casos, monitora IA
Atendente / NegociadorSua fila (casos atribuídos a si + sem responsável)Trabalho operacional diário na fila
JurídicoCasos escalonados (visão de toda a carteira)Casos encaminhados para tratamento judicial
Agência / CooperativaSua agência/unidadeAtendimento local na própria agência
AuditorTodo o histórico permitido, somente leituraConformidade, LGPD, Banco Central
Agente de IAIdentidade própria nas ações — não é um usuário humano convencionalExecuta ações de cobrança de forma autônoma ou assistida

A matriz completa de permissões por perfil está na seção 16.3 — Perfis e Permissões.

↑ voltar ao topo da seção

Introdução

2.Primeiros passos

Como entrar no sistema, entender a tela principal e usar os recursos de protótipo.

2.1 Como entrar (login)

Nesta fase não existe autenticação real — não há senha nem validação de credenciais. A tela de entrada apresenta uma lista de personas: usuários mockados, cada um já vinculado a um perfil e a uma unidade organizacional. Basta clicar em um nome e depois em "Entrar como {nome}".

Tela de login da plataforma, com lista de personas para seleção
Tela de entrada: painel esquerdo com a identidade Sicoob e o resumo do fluxo de cobrança; painel direito com a lista de personas.
  1. Escolha uma persona — clique em um dos nomes da lista à direita. Cada linha mostra as iniciais em avatar, o nome e o perfil (ex.: "Renata Salgado — Gestor de Cobrança").
  2. Confirme a entrada — o botão muda para "Entrar como {primeiro nome}" e fica habilitado somente após a seleção.
  3. Você cai no Dashboard — a tela inicial após o login é sempre o Dashboard.
As 10 personas disponíveis para login
NomePerfilUnidade
Marcelo AguiarAdministradorUnidade 1
Renata SalgadoGestor de CobrançaUnidade 1
Fábio ToledoSupervisorUnidade 1
Juliana PradoAtendente / NegociadorUnidade 2
Anderson VilelaAtendente / NegociadorUnidade 2
Camila BastosAtendente / NegociadorUnidade 3
Tiago MeirelesAtendente / NegociadorUnidade 4
Cristiane RochaJurídicoUnidade 1
Paulo Henrique SáAgência / CooperativaUnidade 5
Débora NunesAuditorUnidade 1
Nesta fase

Login por senha, SSO/AD e recuperação de acesso entram na Fase 2. Aqui, "entrar" é apenas escolher qual perfil você quer explorar — útil para comparar o que cada perfil enxerga.

2.2 Layout geral da aplicação

Todas as telas internas seguem a mesma estrutura: barra lateral recolhível, barra superior e uma faixa amarela de protótipo sempre visível.

Aplicação em tema claro
Tema claro (padrão)
Aplicação em tema escuro
Tema escuro
  • Sidebar (esquerda) — logo Sicoob, nome da cooperativa e o menu principal, agrupado por área (ver seção 3). Pode ser recolhida clicando no ícone de recolher; a preferência fica salva no navegador.
  • Faixa de protótipo (amarela) — sempre visível, avisa "Protótipo Fase 1.2 · dados fictícios, sem backend" e concentra as duas ferramentas de desenvolvimento: trocar de persona e restaurar dados de demonstração (ver 2.3).
  • Topbar (superior) — trilha de navegação (breadcrumb), botão de alternar entre tema claro/escuro, botão de notificações (apenas ilustrativo nesta fase), e no canto direito o nome, perfil e unidade do usuário logado, com botão "Sair".
  • Área de conteúdo — a tela da rota atual.

2.3 Trocar de persona e restaurar dados de demonstração

Como todas as ações (registrar cobrança, criar promessa, editar régua, ativar agente...) realmente alteram o estado da aplicação — guardado no navegador, não em um servidor — a faixa de protótipo oferece duas ferramentas:

  • Trocar persona Seletor na própria faixa amarela: escolha outro nome da lista e o sistema troca de usuário imediatamente, sem precisar sair e entrar de novo. Útil para comparar o que um Atendente vê contra o que um Gestor vê.
  • Restaurar dados de demonstração Botão que apaga tudo o que foi alterado durante a sessão e recarrega os dados originais dos arquivos de mock. Use sempre que quiser voltar a um estado limpo para uma nova demonstração ou teste.
  • Atenção

    Os dados ficam salvos apenas no navegador local (localStorage). Trocar de navegador, limpar dados do site ou usar outro computador não preserva o que foi alterado — e isso é esperado nesta fase.

    2.4 Formatos usados no sistema

    Todo o sistema segue o padrão brasileiro de formatação, de forma consistente em todas as telas:

    TipoFormatoExemplo
    MoedaR$ 0.000,00R$ 30.000,00
    Datadd/mm/aaaa09/09/2026
    Data e horadd/mm/aaaa hh:mm09/09/2026 14:30
    Decimalvírgula12,5%
    CPF/CNPJsempre mascarado nos mocks***.456.789-**
    Data de referência do protótipo

    Todos os cálculos de "hoje", atraso e vencimento usam uma data fixa: 09/09/2026. Isso evita que promessas e prazos "envelheçam" com o tempo real e distorçam a demonstração. Em produção, "hoje" será a data real do servidor.

    ↑ voltar ao topo da seção

    Introdução

    3.Menu e navegação

    Mapa completo do menu principal, na ordem em que aparece na barra lateral. Cada item só aparece para quem tem a permissão correspondente — se um grupo inteiro fica sem itens visíveis para o seu perfil, o grupo some.

    GrupoItemRotaPermissão necessária
    Visão geralDashboard/dashboard.view
    CobrançaFila de cobrança/filaqueue.view
    Clientes e casos/clientesqueue.view
    Ações de cobrança/acoesqueue.view
    Promessas e negociações/promessasqueue.view
    Inteligência e automaçãoRéguas de cobrança/reguasqueue.view (editar: rule.manage)
    Agentes de IA/agentesqueue.view (editar: agent.manage)
    Agenda e execuções/execucoesqueue.view
    DadosImportações/importacoesimport.manage
    Pagamentos/pagamentospayment.view
    GestãoEquipes/equipesuser.manage
    Usuários/usuariosuser.manage
    Perfis e permissões/perfisuser.manage
    GovernançaAuditoria/auditoriaaudit.view
    ConfiguraçõesConfigurações gerais/configuracoessettings.manage
    Regra de negócio

    Note que Fila, Clientes, Ações, Promessas, Réguas, Agentes e Execuções compartilham a mesma permissão base queue.view — não há hoje granularidade separada entre esses módulos: quem enxerga a fila enxerga todos eles. A edição (mudar régua, editar agente) é que exige a permissão específica de gestão.

    ↑ voltar ao topo da seção

    Cobrança

    4.Dashboard

    /· dashboard.view Tela inicial após o login

    Visão executiva e operacional da carteira, escopada automaticamente ao que o usuário logado pode ver (ver regra de escopo na seção 19.5).

    Dashboard com indicadores, gráficos e tabelas de performance
    Dashboard: cartões de indicadores, evolução da recuperação, distribuição por régua e faixa, e tabelas de produtividade.

    4.1 Indicadores (linha 1 — visão geral)

    IndicadorO que mostra
    Saldo vencido da carteiraSoma do saldo vencido agregado de todos os casos visíveis, com o número de casos ativos
    Recuperado no períodoValor recebido, com a taxa de recuperação (recuperado ÷ (vencido + recuperado))
    Clientes em cobrançaQuantidade de clientes com caso ativo, destacando quantos estão sem contato recente
    Saldo a vencerBase da carteira preventiva — parcelas ainda não vencidas

    4.2 Indicadores (linha 2 — operacionais)

    IndicadorO que mostra
    Promessas em abertoContagem e valor total das promessas ainda vigentes
    Promessas quebradasContagem e valor total das promessas não cumpridas no prazo
    Ações hojeAções registradas na data de referência, separando humanas de IA
    ContactabilidadePercentual de ações que resultaram em algum tipo de contato efetivo

    4.3 Gráficos e tabelas

    Gráfico de rosca por faixa de valor no dashboard
    Carteira por faixa de valor (donut) e carteira por faixa de atraso (barras)
    Dashboard em tema escuro
    O mesmo painel no tema escuro
    • Evolução da recuperação — gráfico de área com os pagamentos conciliados dos últimos 6 meses.
    • Carteira por faixa de atraso — barras com o saldo vencido agrupado pelas bandas de dias de atraso.
    • Carteira por régua — distribuição de casos por régua, com atalho "ver réguas".
    • Carteira por faixa de valor — donut com a contagem de casos por banda de valor (V1/V2/V3).
    • Humano × Agente de IA — tabela comparando ações, contatos, promessas e taxa de conversão entre os dois tipos de executor.
    • Recuperação por canal — ações, promessas geradas e conversão por canal de contato.
    • Produtividade por atendente — ranking por valor recuperado, com ações, contatos e promessas de cada um.
    Regra de negócio

    Todos os números do dashboard respeitam o escopo de visão do usuário logado — um Atendente vê apenas seus próprios números; Gestor, Supervisor, Jurídico, Auditor e Administrador veem a carteira inteira.

    Ainda não implementado

    Não existe seletor de período: os indicadores somam toda a base mockada, e a evolução mostra sempre os últimos 6 meses fixos. Um filtro de período (mês corrente, últimos 30 dias, personalizado) é um dos próximos passos da Fase 1.2 — ver seção 22.

    ↑ voltar ao topo da seção

    Cobrança

    5.Fila de cobrança

    /fila· queue.view Tela mais usada no dia a dia operacional

    Lista de trabalho principal do atendente: quem contatar, em que ordem e com qual prioridade.

    Fila de cobrança com filtros, chips e tabela de casos
    Fila de cobrança: busca, filtros rápidos, tabela ordenável e ação de registrar contato direto na linha.

    5.1 Cabeçalho e filtros

    No topo, três totais ao vivo do recorte atual (número de casos, valor total em atraso, número de promessas) e o botão "Atualizar". Abaixo, os filtros:

    • Busca — por nome do cliente, documento ou número do caso.
    • Régua — filtra por uma régua/carteira específica.
    • Situação — filtra por qualquer status de caso (ver tabela na seção 20).
    • Limpar filtros — só aparece quando algum filtro está fora do padrão.

    Os filtros escolhidos ficam salvos no navegador e continuam aplicados na próxima vez que a fila for aberta.

    5.2 Filtros rápidos (chips)

    Cada chip mostra, entre parênteses, quantos casos se encaixam naquele recorte — calculado antes de qualquer filtro rápido ser aplicado, para o número ficar sempre correto:

    ChipO que traz
    Toda a filaTodos os casos visíveis ao usuário (sem recorte adicional)
    Minha filaCasos atribuídos ao usuário logado
    Sem responsávelCasos ainda não atribuídos a ninguém
    Ação vencida ou hojeCasos com próxima ação agendada para hoje ou já vencida
    Com promessaCasos com uma promessa ativa em aberto
    Promessa quebradaCasos com promessa quebrada (histórico ou vigente)
    Sem contatoSem nenhuma ação registrada, ou sem contato efetivo há mais de 15 dias, ou o último resultado foi um dos tipos "sem contato"
    Alta prioridadeCasos com prioridade Alta (definida pela régua)
    IA agendadaCasos com uma execução de agente de IA agendada ou em andamento

    5.3 Colunas da tabela

  • ClienteNome, tipo de pessoa (PF/PJ), documento mascarado e número do caso
  • AgênciaUnidade organizacional do cliente
  • Saldo vencidoSaldo vencido agregado do caso (ordenável)
  • AtrasoIndicador visual de 4 barras representando a severidade do atraso (ordenável)
  • Ops.Quantidade de contratos/operações do cliente
  • RéguaRégua atual e estratégia de tratamento associada
  • PrioridadeAlta / Média / Baixa, definida pela régua (ordenável)
  • ResponsávelUsuário atribuído ao caso, ou vazio se não atribuído
  • Última açãoResultado da ação mais recente, há quantos dias, com marcação "· IA" se foi um agente de IA (ordenável)
  • Próxima açãoTipo e data da próxima ação agendada (ordenável)
  • PromessaBadge com a data da promessa ativa, ou "N quebrada(s)" em destaque vermelho
  • SituaçãoBadge de status do caso
  • CanaisÍcones indicando quais canais estão disponíveis para aquele cliente
  • + AçãoAbre diretamente o modal de registrar ação, sem sair da fila (requer action.register)
  • A tabela é paginada em blocos de 15 linhas. Clicar em qualquer parte da linha (fora de um link) leva para a página do cliente/caso.

    Regra de negócio

    A fila nunca lista parcelas isoladas — cada linha é um cliente/caso, e o valor de saldo vencido já é a soma de todas as dívidas vencidas daquele cliente (ver seção 19.2).

    ↑ voltar ao topo da seção

    Cobrança

    6.Clientes e casos

    /clientes· queue.view

    Uma listagem mais simples que a fila, orientada ao cadastro do cliente em vez de à priorização de trabalho — útil para localizar um cliente diretamente.

    • Busca — por nome ou documento.
    • Filtro — chips PF / PJ / Todos.

    Colunas: Cliente (nome + documento), Tipo, Cidade, Saldo vencido, Atraso, Operações, Situação do caso (ou "sem caso" quando o cliente não tem cobrança ativa) e data de abertura. A lista é ordenada por saldo vencido, do maior para o menor, e não é paginada.

    ↑ voltar ao topo da seção

    Cobrança

    7.Caso de cobrança — visão 360º do cliente

    /clientes/:customerId· Requer caso existente para o cliente

    A tela mais completa do sistema: tudo o que se sabe sobre o cliente e o histórico de cobrança em um único lugar, organizado em abas.

    Visão 360 graus do cliente, com cabeçalho, indicadores e abas
    Cabeçalho do caso com indicadores-chave e as ações disponíveis, seguido pelas abas de detalhamento.

    7.1 Cabeçalho do caso

    Mostra avatar (iniciais), nome, tipo de pessoa, documento mascarado, cidade/UF, régua atual, responsável (ou "sem responsável"), marcação de prioridade, badge de situação do caso e os ícones de canais disponíveis.

    7.2 Indicadores do caso

    Saldo vencido agregadoSoma de todas as parcelas vencidas de todas as operações do cliente
    Saldo a vencerParcelas ainda dentro do prazo
    Maior atrasoMaior número de dias de atraso entre as operações do cliente
    Operações · parcelas em abertoQuantidade de contratos e de parcelas ainda não quitadas
    Recuperado neste casoValor já pago desde a abertura do caso
    Promessas em abertoContagem e soma das promessas vigentes
    Próxima açãoTipo e data agendados, ou "não agendada"

    7.3 Ações disponíveis no topo da página

  • Registrar açãoaction.registerAbre o modal completo de registro de contato — ver seção 8
  • Criar promessaaction.registerAbre o mesmo modal, já com o resultado pré-selecionado como "Promessa de pagamento" — ver nota abaixo
  • Responsávelcase.assignAbre um modal simples para atribuir ou remover o responsável pelo caso
  • Próxima açãoaction.registerAbre um modal para agendar tipo e data/hora da próxima ação, sem precisar registrar um contato agora
  • Regra de negócio

    Uma promessa nunca existe "solta": ela sempre nasce vinculada à ação de cobrança que a originou. Por isso o botão "Criar promessa" não abre um formulário próprio — ele reaproveita o modal de registrar ação, apenas com o resultado já preenchido. Toda promessa tem, assim, uma conversa registrada por trás.

    7.4 Modal "Alterar responsável"

    Lista para escolha: "Sem responsável (volta para a fila geral)" ou qualquer usuário com perfil Atendente/Negociador, Supervisor, Jurídico ou Gestor de Cobrança.

    7.5 Modal "Agendar próxima ação"

    Campos: Tipo de ação (Ligação, Ligação IA, WhatsApp, WhatsApp IA, Presencial, E-mail, Confirmar pagamento) e Data e hora. O botão Agendar só habilita depois de preencher a data. Uma nota no modal lembra: "o caso aparece no filtro 'Ação vencida ou hoje' da fila a partir desta data."

    7.6 As abas

    Visão geral

    As últimas 5 ações (com link para o histórico completo), um bloco de classificação (régua atual, tratamento, agência de relacionamento, quantidade de promessas quebradas) e, se houver, um card com a promessa vigente (valor, data, "vencida há N dias" quando aplicável, condição acordada e situação).

    Dívidas e operações

    Tabela com cada operação/parcela do cliente: número, produto, parcela (n/total), vencimento, dias de atraso (em vermelho quando vencida), valor principal, encargos, saldo e situação (Vencida/A vencer). Uma nota explícita lembra que o saldo vencido agregado do caso é a soma dessas parcelas — nunca o valor de uma operação isolada.

    Histórico

    O componente de timeline completo — ver 7.7 abaixo.

    Promessas

    Tabela com valor prometido, data prometida, valor cumprido, origem (humano/IA/sistema), quem registrou, a condição acordada em texto livre e a situação. Se não houver nenhuma, aparece um estado vazio com atalho para criar uma promessa.

    Pagamentos

    Data, operação, valor, origem, lote de importação e situação da conciliação. Estado vazio explica que pagamentos chegam por importação de planilha e conciliam automaticamente com promessas em aberto.

    Dados do cliente

    Nome, nome fantasia (pessoa jurídica), documento mascarado, cidade/UF, data de cadastro, e a tabela de contatos (tipo, valor, se é o principal, se é válido, e se está bloqueado para contato — com o motivo).

    Automações

    Execuções de agentes de IA vinculadas a este caso: agente, canal, data agendada, nível de autonomia e situação.

    7.7 Histórico / Timeline

    Timeline do cliente mostrando eventos agrupados por dia
    Cada evento é agrupado por dia; o marcador (círculo, robô ou engrenagem) já identifica se foi humano, IA ou sistema.

    A timeline é o histórico cronológico unificado do caso: dívida/contrato, entrada na régua, contato humano, contato de IA por voz ou mensagem, promessa criada/cumprida/quebrada, pagamento importado, mudança de responsável ou de régua, e encerramento — tudo vira um evento na mesma linha do tempo.

    • Os eventos são agrupados por dia, com uma linha separadora sempre que a data muda.
    • O marcador visual diferencia o ator por forma, não só por cor — um círculo com as iniciais para humano, um ícone de robô para IA e um ícone de engrenagem para sistema — evitando que o histórico vire "um mosaico colorido" difícil de escanear rapidamente.
    • Quando a ação tem uma ligação, mensagens de WhatsApp ou observações internas anexadas, aparece um botão para expandir e ver a transcrição da ligação, a conversa completa ou as observações.
    ↑ voltar ao topo da seção

    Cobrança

    8.Registrar ação de cobrança

    Modal, acionado a partir da Fila ou do Caso de Cobrança action.register

    O formulário mais usado do sistema — todo contato humano com o cliente é registrado aqui.

    Modal de registrar ação de cobrança com todos os campos
    Modal "Registrar ação de cobrança" — os blocos condicionais de promessa e próxima ação aparecem conforme o resultado escolhido.

    8.1 Campos do formulário

  • CanalobrigatórioTelefone, WhatsApp, WhatsApp Voice, SMS, E-mail, Presencial, Registro manual ou Outro. Padrão: Telefone.
  • Data e hora do contatoobrigatórioPré-preenchida com a data de referência do sistema.
  • Responsável pela açãoobrigatórioQualquer usuário cadastrado; pré-preenchido com quem está logado.
  • Resultado do contatoobrigatórioLista agrupada em "Com contato", "Sem contato", "Negociação" e "Encaminhamento" — ver taxonomia completa na seção 19.3. Nunca fica fixa no código: vem sempre do cadastro de resultados.
  • Descrição do contatoobrigatórioTexto livre — fica visível na timeline do cliente e como resumo da última ação na fila.
  • ObservaçõescondicionalTexto interno, não visível ao cliente. Torna-se obrigatório para resultados que exigem justificativa (ex.: contestação).
  • Próxima açãocondicionalTipo (Ligação, Ligação IA, WhatsApp, WhatsApp IA, Presencial, E-mail, Confirmar pagamento, Confirmar entrada, Reavaliar situação, Retorno do gestor, Retorno da análise, Atualizar contato) e data/hora. Obrigatório para resultados que exigem acompanhamento.
  • Bloco condicional — Promessa de pagamento

    Aparece automaticamente quando o resultado escolhido exige uma promessa (ex.: "Promessa de pagamento", "Acordo fechado"):

    • Valor prometido — pré-preenchido com o saldo vencido agregado do caso, editável.
    • Data prometida — não pode ser anterior à data de referência.
    • Condição acordada — texto livre, ex.: "entrada de 30% e saldo em 5x".

    Aviso — Tratamento humano obrigatório

    Se o resultado escolhido for Contestação da dívida ou Sem capacidade de pagamento, um aviso reforça a regra de compliance antes de salvar: contestação suspende a cobrança automática até análise (e agentes de IA não podem retomar o contato sozinhos); vulnerabilidade financeira tira o caso da cobrança ativa até a data da próxima reavaliação.

    8.2 Validações

    • Resultado do contato é sempre obrigatório.
    • Descrição precisa de pelo menos 5 caracteres.
    • Observações precisam de pelo menos 5 caracteres quando o resultado exige (ex.: encaminhamentos).
    • Data da próxima ação é obrigatória quando o resultado exige acompanhamento.
    • Valor e data prometidos são obrigatórios sempre que o bloco de promessa está visível.

    8.3 O que acontece ao salvar

    Registrar uma ação não é uma simples gravação — é uma operação com vários efeitos automáticos, todos aplicados juntos:

    1. A ação é criada — com identificador próprio, sempre como um registro novo (nunca sobrescreve um existente).
    2. Um evento entra na timeline do caso, com o canal e o resultado escolhidos.
    3. Se houver promessa, ela é criada já vinculada a esta ação, com situação inicial "Em aberto".
    4. A situação do caso pode mudar automaticamente, de acordo com o resultado escolhido (ex.: "Promessa de pagamento" muda o caso para "Promessa em aberto"; "Contestação da dívida" muda para "Suspenso"). Ver tabela completa na seção 19.3.
    5. Se o resultado for "Encaminhado ao jurídico", o caso é automaticamente reatribuído a um usuário do perfil Jurídico.
    6. A data/tipo da última e da próxima ação do caso são atualizados, refletindo imediatamente na fila.
    7. Um toast de confirmação aparece ("Ação registrada"), e o modal fecha.
    Regra de negócio — imutabilidade

    Uma ação registrada nunca é editada depois de salva. O rodapé do modal reforça isso: "uma correção entra como novo registro apontando para o original." A tela para registrar essa correção ainda não existe nesta fase — ver seção 21.

    ↑ voltar ao topo da seção

    Cobrança

    9.Ações de cobrança

    /acoes· queue.view

    Histórico consolidado de todas as ações registradas na plataforma, humanas e de IA — a mesma informação que alimenta a timeline de cada cliente, aqui em formato de lista para consulta ampla.

    • Filtro por executor — Todos / Humano / Agente de IA / Sistema.
    • Filtro por resultado — qualquer um dos resultados cadastrados.

    Colunas: data e hora, cliente (com link para o caso), executor (com ícone e tipo), canal, resultado (badge colorido pelo grupo do resultado), descrição e — quando é uma ligação — a duração. Lista paginada em blocos de 20.

    Lembrete visível na tela

    "Ações imutáveis: correção entra como novo registro vinculado ao original."

    ↑ voltar ao topo da seção

    Cobrança

    10.Promessas e negociações

    /promessas· queue.view Cancelar: promise.manage

    Todas as promessas de pagamento registradas na plataforma, com seu status calculado em tempo real.

    10.1 Indicadores

    Em aberto (valor + contagem) · Quebradas (valor + contagem) · Recebido de promessas (valor + contagem cumpridas) · Taxa de cumprimento (%).

    10.2 Abas e tabela

    Abas: Todas, Em aberto, Quebradas, Cumpridas (inclui cumpridas totalmente e parcialmente). Colunas: cliente (com número do caso), valor prometido, data prometida (com "vence há N dias" quando em aberto), valor recebido, origem (quem prometeu em nome de quem — humano ou IA), quem registrou, condição acordada e situação.

    10.3 Cancelar promessa

    Disponível apenas para promessas com situação "Em aberto" e para quem tem a permissão de gerenciar promessas. Abre uma confirmação explicando que "a promessa deixa de contar como compromisso do cliente e o cancelamento fica registrado na timeline do caso — nenhum registro é apagado."

    Regra de negócio — promessa quebrada

    Uma promessa em aberto é automaticamente tratada como Quebrada quando a data prometida passa da tolerância configurada (atualmente 3 dias, valor provisório — ver seção 22). Esse cálculo acontece toda vez que a informação é lida (fila, tela de promessas, caso do cliente), não existe um processo agendado rodando em segundo plano nesta fase — em produção isso será um job automático.

    ↑ voltar ao topo da seção

    Cobrança

    11.Pagamentos

    /pagamentos· payment.view

    Todos os pagamentos importados, com o status de conciliação com dívidas e promessas.

    Indicadores: Total recebido · Vinculado a promessas (valor e % do recebido) · Pendentes de conciliação (contagem) · Pagamentos importados (contagem).

    Filtros: busca por cliente/operação, e chips de conciliação (Todos / Conciliado / Pendente / Divergente).

    Colunas: data, cliente, operação, valor, origem, lote de importação, promessa baixada (valor + data, ou "—") e situação de conciliação.

    Nesta fase

    Pagamentos são simulados; a conciliação real com o Core Banking da cooperativa é um item de fase futura (ver seção 21).

    ↑ voltar ao topo da seção

    Inteligência e automação

    12.Réguas de cobrança

    /reguas· queue.view Editar: rule.manage

    Aqui vive a estratégia de classificação da carteira: quais condições colocam um cliente em qual carteira, com qual prioridade e qual tratamento.

    Tela de réguas de cobrança, com cards de condições SE...ENTÃO
    Cada régua é um card com a lógica "SE...ENTÃO" e um painel lateral com casos e saldo vinculados.

    12.1 Como ler um card de régua

    Cada régua aparece como um card independente, com destaque turquesa se está ativa (cinza se inativa): nome, descrição, número de prioridade, badge de situação, e os botões "Editar condições" e "Ativar/Desativar" (para quem tem permissão de gestão).

    O corpo do card lê como uma frase lógica:

    Exemplo de leitura

    SE saldo vencido agregado >= R$ 30.000,01 E saldo vencido agregado <= R$ 100.000,00
    ENTÃO carteira = Cobrança Vencida — Faixa 2 · prioridade do caso = Média · tratamento = Equipe interna · canais = Telefone, WhatsApp

    Ao lado, um painel mostra quantos casos estão hoje nessa régua, a soma do saldo vencido deles e a equipe padrão responsável (ou "Sem equipe interna (tratamento externo)" quando o tratamento é CCS).

    12.2 Editar condições

    O editor abre com o aviso "O motor avalia campo + operador + valor. Nenhuma condição fica fixa no código." Campos:

  • Prioridade da réguaNúmero — quanto maior, mais essa régua "vence" quando o cliente se encaixaria em mais de uma carteira ao mesmo tempo (ver seção 19.2)
  • Prioridade do casoAlta / Média / Baixa — o valor que os casos nesta régua carregam na fila
  • TratamentoCCS — Central de Serviços, Equipe interna, Equipe especializada, IA primeiro humano depois, ou Cobrança judicial
  • Abaixo, a lista de condições, cada uma com três partes — Campo (ver 7 opções na seção 19), Operador (igual a, diferente de, maior que, maior ou igual a, menor que, menor ou igual a, entre, está em, não está em) e Valor (ou "De"/"Até" quando o operador é "entre"). É possível adicionar ou remover condições livremente.

    Somente as faixas de valor 1 e 2 estão confirmadas

    A tela avisa isso de forma fixa no topo: nenhum valor de faixa está gravado no código — apenas as faixas de valor até R$ 30 mil e de R$ 30 mil a R$ 100 mil foram confirmadas pelo negócio. Os prazos dia a dia de cada régua (quando ligar, quando mandar WhatsApp, quando escalar) seguem em aberto e são editáveis nesta tela.

    Nesta fase

    "A alteração vale só para a demonstração: o motor de classificação real entra na Fase 2" — texto que aparece no rodapé do editor.

    12.3 As 7 carteiras/réguas de negócio

    Estas são as carteiras já fechadas na Fase 0 do planejamento (ver detalhamento de regras na seção 19.1):

    Carteira / RéguaCritério de entradaTratamento
    Cobrança Vencida — Faixa 1Saldo vencido agregado até R$ 30.000,00CCS
    Cobrança Vencida — Faixa 2Acima de R$ 30.000,00 até R$ 100.000,00Equipe interna
    Cobrança Vencida — Faixa 3Acima de R$ 100.000,00Equipe interna / especializada
    Cobrança PreventivaParcelas com vencimento nos próximos 45 diasTodos os canais
    PrejuízoCliente classificado na carteira de prejuízoTodos os canais
    Cheque EspecialUtilização ininterruptaTodos os canais
    Cartão VencidoCartão/fatura em situação de vencimentoTodos os canais

    As carteiras não são mutuamente exclusivas: um cliente pode se encaixar em mais de uma ao mesmo tempo. É a prioridade da régua que decide qual carteira prevalece para aquele cliente.

    ↑ voltar ao topo da seção

    Inteligência e automação

    13.Agentes de IA

    /agentes· queue.view Editar: agent.manage

    Cadastro dos agentes de Inteligência Artificial que atuam como executores de ações de cobrança, com identidade própria — a IA é um ator formal do sistema, não um sistema à parte.

    Cards de agentes de IA com autonomia, horário e políticas
    Cada agente mostra seu nível de autonomia, horário permitido, limite diário e — quando aplicável — os limites do Policy Engine.

    13.1 O que cada card mostra

    Ícone (telefone para voz, mensagem para WhatsApp), nome, tipo ("Agente de voz" ou "Agente de mensagem") com provedor e telefonia associados, badge Ativo/Inativo, descrição, nível de autonomia (com indicador visual de 3 níveis), horário permitido, dias da semana, limite diário de contatos, execuções concluídas, réguas atendidas e — se configurado — os limites do Policy Engine.

    13.2 Os 3 níveis de autonomia

    Cada agente é configurado individualmente — um agente pode estar no nível 1 e outro no nível 3 ao mesmo tempo:

    NívelNomeComportamento
    1ComunicaçãoInforma dívida, vencimento, valores e orientações autorizadas — não negocia
    2Negociação AssistidaApresenta apenas condições já pré-autorizadas pela instituição
    3Negociação AutônomaNegocia dentro de limites configurados: desconto máximo, entrada mínima, número máximo de parcelas

    13.3 Editar agente

    O editor abre com o aviso "Nesta fase nada é enviado ao provedor: a configuração fica só no protótipo." Campos: objetivo do agente (texto livre), nível de autonomia, horário permitido (início/fim), limite de contatos por dia, e — se autonomia for nível 2 ou 3 — o bloco "Limites autorizados (Policy Engine)": desconto máximo (%), entrada mínima (%) e parcelas máximas.

    Regra de negócio — Policy Engine

    "O agente nunca calcula condição própria: desconto, entrada e parcelamento vêm destes limites." A IA não inventa taxa, saldo ou desconto — todas as condições financeiras que ela pode oferecer vêm de um motor de regras central, nunca de decisão livre do modelo de linguagem.

    Handoff humano obrigatório — não configurável

    Este bloco aparece sempre no editor, fixo e sem opção de desativar: "Contestação de dívida, alegação de fraude, vulnerabilidade financeira, baixa confiança do agente ou pedido explícito de atendente encerram a conversa e devolvem o caso para a fila humana." Não é uma escolha de configuração — é uma regra de proteção ao cliente.

    ↑ voltar ao topo da seção

    Inteligência e automação

    14.Agenda e execuções

    /execucoes· queue.view

    Enquanto a tela de Agentes mostra "quem" é cada IA, esta tela mostra "o que ela está fazendo" — a agenda de contatos que os agentes vão executar ou já executaram.

    Indicadores: Agendadas · Em execução · Concluídas · Sem contato.

    Filtros por situação: Todas, Agendado, Executando, Concluído, Sem contato, Cancelado.

    Colunas: agente, cliente, canal (voz/WhatsApp), régua, agendado para, resultado, duração, situação, e um botão "Abrir" quando já existe uma ação de cobrança vinculada.

    Ao abrir uma execução, o modal mostra canal, duração, resultado, o resumo da conversa e — quando é ligação — a transcrição completa por interlocutor (Agente IA / Cliente / Atendente), ou — quando é WhatsApp — as mensagens trocadas em formato de conversa.

    ↑ voltar ao topo da seção

    Dados

    15.Importações

    /importacoes· import.manage

    Simula a forma como, no sistema definitivo, clientes, dívidas, parcelas e pagamentos chegarão à plataforma: por planilha Excel.

    Wizard de importação de planilha, com etapas e histórico de lotes
    Assistente de importação de 4 passos e o histórico de lotes já processados.

    15.1 O assistente de 4 passos

    1. Selecionar arquivo — escolha o tipo de planilha (Clientes, Operações e parcelas, ou Pagamentos) e envie o arquivo (.xlsx, .xls ou .csv) por arrastar-e-soltar ou pelo seletor. Formato inválido gera um aviso e bloqueia o envio.
    2. Validando — indicador de progresso enquanto o sistema simula a leitura do arquivo.
    3. Conferir — uma prévia com o total de linhas, quantas são novas, quantas são atualizações, quantas têm inconsistência, uma amostra de linhas e — se houver — a lista detalhada de erros (linha, chave, campo, mensagem). Linhas com erro ficam de fora da importação; as demais são processadas normalmente.
    4. Resumo — confirmação do lote processado, com as contagens finais, e o botão "Importar outra planilha".
    Regra de negócio — reimportação acidental

    Se o mesmo arquivo (pelo seu conteúdo, não só o nome) já tiver sido importado antes com sucesso, a tela de conferência avisa "Arquivo já importado" — sem bloquear o envio, apenas recomendando cancelar. Isso é o começo da regra de idempotência: reenviar a mesma planilha por engano não deve duplicar clientes, dívidas ou pagamentos.

    15.2 Histórico de lotes

    Tabela com: número do lote, arquivo (e sua identificação única), tipo, data de importação, quem importou, total de linhas, novos, atualizados, erros e situação — com a primeira mensagem de erro visível quando o lote falhou completamente.

    ↑ voltar ao topo da seção

    Dados

    16.Equipes, usuários e perfis

    user.manage

    Três telas de gestão administrativa, todas somente leitura nesta fase.

    16.1 Usuários /usuarios

    Tabela com usuário (avatar, nome e e-mail), perfil, unidade, equipes, último acesso e situação (Ativo/Inativo). Uma nota lembra: "Autenticação real, criação e bloqueio de usuário entram na Fase 2 — aqui a tela mostra apenas o cadastro mockado." Agentes de IA têm identidade própria e não aparecem nesta lista de usuários humanos.

    16.2 Equipes /equipes

    Um card por equipe: nome, descrição, badge Ativa/Inativa, unidade, gestor responsável e a lista de integrantes.

    16.3 Perfis e permissões /perfis

    A matriz completa: cada uma das 13 permissões do sistema em linha, cada perfil em coluna, com ✓ marcando o que aquele perfil pode fazer.

    PermissãoO que libera
    Visualizar filaAcessar Fila, Clientes, Ações, Promessas, Réguas, Agentes, Execuções
    Visualizar toda a carteiraVer casos de todos os clientes, não só os atribuídos a si
    Registrar açãoRegistrar contatos e criar promessas
    Gerenciar promessasCancelar promessas em aberto
    Distribuir casosAlterar o responsável por um caso
    Visualizar dashboardAcessar a tela inicial de indicadores
    Administrar réguasEditar condições e ativar/desativar réguas
    Administrar agentes de IAEditar configuração e ativar/desativar agentes
    Importar planilhasAcessar o módulo de Importações
    Visualizar pagamentosAcessar a tela de Pagamentos
    Administrar usuáriosAcessar Equipes, Usuários e Perfis
    Visualizar auditoriaAcessar a trilha de auditoria
    Alterar configuraçõesAcessar Configurações gerais
    ↑ voltar ao topo da seção

    Governança

    17.Auditoria

    /auditoria· audit.view

    Trilha somente leitura de tudo o que acontece na plataforma — exigida pelas normas do Banco Central e pela LGPD.

    Filtros: busca por ator, entidade ou descrição, e seleção do tipo de evento (Criação, Alteração, Acesso, Saída, Distribuição, Troca de responsável, Alteração de régua, Alteração de configuração, Exportação, Importação, Pedido de exclusão).

    Colunas: data e hora, ator (nome e tipo), origem (Agente de IA / Interface / Sistema), evento, entidade afetada (tipo e identificador), descrição e endereço IP. Lista paginada em blocos de 25.

    ↑ voltar ao topo da seção

    Governança

    18.Configurações gerais

    /configuracoes· settings.manage

    Onde ficam expostos os parâmetros que hoje ainda são provisórios, para deixar claro o que já é regra de negócio fechada e o que segue em validação.

    • Faixas de valor — V1, V2, V3, já confirmadas pelo negócio.
    • Faixas de atraso — A vencer, e as bandas de 1 a 15, 16 a 30, 31 a 60, 61 a 90 e acima de 90 dias — todas ainda provisórias.
    • Regras temporais — tolerância da promessa (3 dias, provisório) e janela de "sem contato" (15 dias).
    • Estrutura organizacional — lista hierárquica das unidades cadastradas.
    • Integrações — estado vazio explícito: "Integrações não configuráveis nesta fase" (Net2Phone, ElevenLabs, WhatsApp, Infobip). Nenhum token ou credencial fica no frontend.
    ↑ voltar ao topo da seção

    Referência

    19.Regras de negócio consolidadas

    As regras que governam o sistema, reunidas em um só lugar — a maioria já foi mencionada junto de cada tela; aqui elas aparecem lado a lado para consulta rápida.

    19.1 Saldo vencido agregado

    É a soma de todas as dívidas vencidas do cliente, nunca o valor de uma operação isolada — é um conceito no nível do sistema, não do contrato.

    Exemplo

    Contrato A: R$ 18.000 vencidos
    Contrato B: R$ 17.000 vencidos
    Saldo vencido agregado = R$ 35.000 → entra na Faixa 2, mesmo que nenhum contrato individual ultrapasse R$ 30 mil

    19.2 Réguas — dois eixos e não exclusividade

    As réguas nunca se baseiam só em dias de atraso. Combinam no mínimo dois eixos: faixa de atraso (ex.: 1–15, 16–30, 31–60, 61–90, +90 dias) e faixa de valor (saldo vencido agregado) — ambas cadastráveis, nunca fixas no código. Um motor de condições (campo + operador + valor) decide carteira, prioridade, tratamento, responsável e estratégia. As carteiras não são mutuamente exclusivas; quando um cliente se encaixa em mais de uma, a régua de maior número de prioridade prevalece (convenção ainda não confirmada formalmente pelo negócio — ver seção 22).

    19.3 Taxonomia de resultados de ação e seus efeitos automáticos

    ResultadoGrupoExigeMuda situação do caso para
    Contato realizadoCom contatopróxima ação, observaçõesEm tratamento
    Sem contatoSem contatopróxima ação—
    Telefone não atendeSem contatopróxima ação—
    Número inválidoSem contatoobservações—
    Caixa postal / recadoSem contatopróxima ação—
    Negociação realizadaNegociaçãopróxima ação, observaçõesEm negociação
    Promessa de pagamentoNegociaçãopróxima ação, promessaPromessa em aberto
    Acordo fechadoNegociaçãopróxima ação, promessa, observaçõesAcordo vigente
    Recusa de negociaçãoNegociaçãopróxima ação, observaçõesAguardando cliente
    Solicitação de retornoCom contatopróxima açãoAguardando cliente
    Contestação da dívidaEncaminhamentopróxima ação, observaçõesSuspenso
    Sem capacidade de pagamentoEncaminhamentopróxima ação, observaçõesAguardando cliente
    Encaminhado ao gestorEncaminhamentopróxima ação, observaçõesEm tratamento
    Encaminhado ao jurídicoEncaminhamentoobservaçõesJurídico (+ reatribuição automática)
    OutrosCom contatoobservações—

    Esta taxonomia vem sempre do cadastro de resultados, nunca é uma lista fixa no código — assim o negócio pode adicionar ou renomear resultados sem depender de uma nova versão do sistema.

    19.4 Promessa quebrada

    Uma promessa em aberto passa automaticamente para "Quebrada" quando a data prometida ultrapassa o prazo de tolerância (hoje 3 dias, provisório). O cálculo é feito no momento da leitura da informação — não existe um processo agendado rodando nesta fase; a situação originalmente registrada nunca é sobrescrita, apenas exibida com seu status "efetivo".

    19.5 Escopo de visibilidade por perfil

    PerfilO que vê na fila e no dashboard
    Administrador, Gestor de Cobrança, Supervisor, Jurídico, AuditorToda a carteira
    Agência / CooperativaApenas casos da própria unidade organizacional
    Atendente / NegociadorApenas casos atribuídos a si, mais os casos ainda sem responsável

    19.6 IA como ator formal

    A IA não é um sistema paralelo: é um tipo de ator (HUMAN | AI | SYSTEM) que executa ações de cobrança dentro da mesma entidade central, com o mesmo histórico. Um agente de voz é operado via ElevenLabs, conectado por SIP à operadora de telefonia; um agente de mensagem opera via WhatsApp. Em ambos os casos, a conversa é transcrita e vinculada ao registro da ação — nesta fase, tudo isso é simulado, sem integração real.

    Agente ≠ Campanha: agente é "quem conversa" (identidade, canal, provedor, autonomia); campanha é "quem será contatado, quando, como e por qual agente" — são conceitos separados no desenho do produto, embora a campanha ainda não tenha tela própria nesta fase.

    Regras financeiras vêm sempre de um Policy Engine — a IA nunca inventa taxa, desconto ou saldo. O handoff humano é obrigatório (e não configurável) em: contestação de dívida, alegação de fraude, vulnerabilidade financeira do cliente, IA sem confiança na resposta, ou pedido explícito de falar com um atendente.

    19.7 Imutabilidade e trilha de auditoria

    Nenhuma operação de escrita no sistema apaga um registro. Cancelamentos e correções sempre criam ou alteram um status — nunca excluem. Toda escrita relevante gera automaticamente um evento de auditoria e, quando aplicável, um evento na timeline do caso.

    19.8 Registrar uma ação é uma única operação com vários efeitos

    Ao salvar uma ação de cobrança, até cinco efeitos acontecem juntos: criação da ação, criação da promessa (se houver), evento na timeline, atualização do caso (situação, última/próxima ação, responsável em caso de escalonamento jurídico) e registro de auditoria. Essa é uma decisão deliberada de arquitetura: a regra de negócio nunca fica espalhada na tela — ela mora inteira na camada de repositório, para que no backend real isso vire uma única transação.

    19.9 KPIs em escopo

    Carteira total e vencidaValor recuperadoTaxa de recuperação Promessas realizadas e cumpridasAcordosContatos realizados ContactabilidadeClientes sem contatoProdutividade por atendente Produtividade por agente de IARecuperação por réguaRecuperação por canal Recuperação por faixa de atrasoRecuperação por faixa de valorCusto de recuperação Humano × IAWhatsApp × VozR$ recuperado por R$ gasto Efetividade por faixa de atraso × faixa de valor

    Nem todos esses indicadores já estão implementados no dashboard mockado — a lista representa o escopo funcional fechado na Fase 0, que orienta o que será construído.

    19.10 Conformidade regulatória

    NormaO que exige da plataforma
    Banco CentralÉtica, responsabilidade, transparência, diligência e tratamento justo considerando a vulnerabilidade do cliente
    CDCCliente inadimplente não pode ser exposto a ridículo, constrangimento ou ameaça
    LGPDFinalidade, necessidade, transparência, segurança e responsabilização; medidas técnicas e administrativas desde a concepção (privacy by design)
    AnatelContabilizar volume de chamadas desde o início — relevante à medida que a IA de voz ganhar escala
    ↑ voltar ao topo da seção

    Referência

    20.Dicionário de dados

    O vocabulário exato usado nas telas — os mesmos rótulos em português que aparecem na interface, e o valor técnico por trás de cada um.

    20.1 Situação do caso de cobrança

    Rótulo na telaCódigoBadge
    AbertoOPENneutro
    Em tratamentoIN_PROGRESSinfo
    Aguardando clienteWAITING_CUSTOMERneutro
    Promessa em abertoPROMISE_PENDINGalerta
    Em negociaçãoNEGOTIATIONinfo
    Acordo vigenteAGREEMENT_ACTIVEsucesso
    JurídicoLEGALcrítico
    SuspensoSUSPENDEDalerta
    RegularizadoRESOLVEDsucesso
    EncerradoCLOSEDneutro

    Regularizado (dívida quitada) é intencionalmente diferente de Encerrado (caso fechado administrativamente) — a distinção é proposital, para não confundir "o cliente pagou" com "nós fechamos o processo".

    20.2 Situação da promessa

    RótuloCódigoBadge
    Em abertoOPENalerta
    CumpridaFULFILLEDsucesso
    Parcialmente cumpridaPARTIALLY_FULFILLEDinfo
    QuebradaBROKENcrítico
    CanceladaCANCELLEDneutro

    20.3 Canais de contato

    RótuloCódigo
    TelefonePHONE
    WhatsAppWHATSAPP
    WhatsApp VoiceWHATSAPP_VOICE
    SMSSMS
    E-mailEMAIL
    PresencialIN_PERSON
    Registro manualMANUAL
    SistemaSYSTEM
    OutroOTHER

    20.4 Ator da ação

    RótuloCódigo
    HumanoHUMAN
    Agente de IAAI
    SistemaSYSTEM

    20.5 Prioridade do caso

    Alta HIGH   Média MEDIUM   Baixa LOW

    20.6 Situação da execução de agente de IA

    RótuloCódigoBadge
    AgendadoSCHEDULEDneutro
    ExecutandoRUNNINGinfo
    ConcluídoCOMPLETEDsucesso
    Sem contatoNO_CONTACTalerta
    FalhaFAILEDcrítico
    CanceladoCANCELLEDneutro

    20.7 Situação da importação

    RótuloCódigoBadge
    EnviadoUPLOADEDneutro
    ValidandoVALIDATINGinfo
    ProcessandoPROCESSINGinfo
    ConcluídoCOMPLETEDsucesso
    Concluído com errosCOMPLETED_WITH_ERRORSalerta
    FalhouFAILEDcrítico

    Tipos de planilha: Clientes CUSTOMERS · Operações e parcelas DEBTS · Pagamentos PAYMENTS.

    20.8 Situação da conciliação de pagamento

    Conciliado RECONCILED   Pendente PENDING   Divergente DIVERGENT

    20.9 Motor de condições das réguas

    Campos disponíveis
    RótuloCódigo
    Saldo vencido agregadoOVERDUE_AMOUNT
    Dias de atrasoDAYS_PAST_DUE
    Parcelas em abertoOPEN_INSTALLMENTS
    ProdutoPRODUCT
    Tipo de pessoaPERSON_TYPE
    AgênciaORGANIZATIONAL_UNIT
    Promessas quebradasBROKEN_PROMISES
    Operadores disponíveis
    RótuloCódigo
    igual aEQ
    diferente deNEQ
    maior queGT
    maior ou igual aGTE
    menor queLT
    menor ou igual aLTE
    entreBETWEEN
    está emIN
    não está emNOT_IN

    20.10 Tratamento da régua (estratégia)

    Equipe interna INTERNAL · Externo / CCS EXTERNAL · Agente de IA AI · IA + humano MIXED · Jurídico LEGAL

    20.11 Nível de autonomia da IA

    Nível 1 — Comunicação · Nível 2 — Negociação assistida · Nível 3 — Negociação autônoma 1 | 2 | 3

    20.12 Filtros rápidos da fila

    Toda a fila ALL · Minha fila MINE · Sem responsável UNASSIGNED · Com promessa WITH_PROMISE · Promessa quebrada BROKEN_PROMISE · Sem contato NO_CONTACT · Ação vencida ou hoje DUE_TODAY · Alta prioridade HIGH_PRIORITY · IA agendada AI_SCHEDULED

    20.13 Faixas de atraso e de valor (parâmetros)

    Faixas de atraso — provisórias, ainda não confirmadas pelo negócio
    FaixaIntervalo
    A venceraté 0 dias
    1 a 15 dias1–15
    16 a 30 dias16–30
    31 a 60 dias31–60
    61 a 90 dias61–90
    Acima de 90 dias91+
    Faixas de valor — confirmadas pelo negócio
    FaixaIntervalo
    V1 — Até R$ 30 milaté R$ 30.000,00
    V2 — R$ 30 mil a R$ 100 milR$ 30.000,01 a R$ 100.000,00
    V3 — Acima de R$ 100 mila partir de R$ 100.000,01
    ↑ voltar ao topo da seção

    Referência

    21.O que é real e o que é simulado nesta fase

    A Fase 1.2 é um protótipo funcional frontend com dados mockados. As telas funcionam de verdade (registrar uma ação realmente muda a fila, a timeline e os indicadores), mas nada disso é persistido em um servidor — tudo vive no navegador.

    ✅ O que já funciona de verdade

    • Fluxo completo: Login → Dashboard → Fila → Cliente 360º → Registrar Ação → Timeline → Promessa/Próxima Ação
    • 32 clientes/casos mockados, com cenários variados e consistentes entre telas
    • Toda regra de negócio de cálculo (saldo agregado, promessa quebrada, escopo por perfil, KPIs) roda de fato sobre esses dados
    • Estado persiste no navegador (localStorage) entre sessões, até ser restaurado

    🚫 O que NÃO existe nesta fase

    • Backend, banco de dados (nem SQLite/Prisma/PostgreSQL) ou endpoints reais
    • Autenticação real (login é só escolha de persona)
    • Integração real com ElevenLabs, Net2Phone ou WhatsApp
    • Ligações, mensagens ou importações reais — tudo é simulado
    • CPF/CNPJ ou nomes reais de clientes — tudo é mascarado/fictício
    • Secrets ou tokens no frontend

    21.1 Funcionalidades previstas ainda não construídas

    FuncionalidadePor que ainda não existe
    Seletor de período no dashboardIndicadores hoje somam toda a base mockada — falta o recorte por período
    Correção de ação de cobrançaDepende de definir quem pode corrigir, em qual prazo e com qual justificativa
    Encerramento manual de caso e reaberturaDepende de definir alçada (quais perfis podem encerrar e quais motivos exigem aprovação)
    Exportação da fila para ExcelAinda não confirmado como requisito da Fase 1
    Auditoria de acessibilidade com leitor de telaContraste, foco e navegação por teclado foram construídos, mas não auditados formalmente

    21.2 O que vem depois da Fase 1.2

    FaseEntrega
    1.3 — Validação e consolidação dos fluxosUsar este protótipo para responder as perguntas em aberto com o negócio
    2 — Backend, banco de dados e APIsNode.js + TypeScript, PostgreSQL, filas (Redis/BullMQ), eventos em tempo real, storage de arquivos
    3+ — Telefonia, WhatsApp Voice, Analytics, IA Copilot, IA VoiceIntegrações reais com Net2Phone, ElevenLabs e biblioteca de WhatsApp não-oficial (Zapo)
    ↑ voltar ao topo da seção

    Referência

    22.Perguntas em aberto e decisões registradas

    Nesta plataforma, quando surge uma dúvida de regra de negócio durante a construção, ela não é resolvida "inventando" silenciosamente — é registrada para o negócio validar. Este é o resumo dessas duas listas vivas.

    22.1 Principais perguntas em aberto

    • Prazos detalhados de cada régua (quando ligar, quando enviar WhatsApp, quando escalar) — só as faixas de valor 1 e 2 estão confirmadas.
    • Prazo de tolerância para promessa quebrada — hoje assumido em 3 dias, valor provisório.
    • Janela de "sem contato" da fila — hoje assumida em 15 dias.
    • Promessa parcialmente cumprida: a partir de qual percentual conta como cumprida? Hoje não há corte percentual.
    • Um cliente pode ter mais de um caso de cobrança aberto ao mesmo tempo? O modelo permite, o protótipo assume caso único ativo por cliente.
    • Convenção de prioridade quando um cliente se encaixa em mais de uma régua — "maior número vence" ainda não confirmado formalmente.
    • Correção de ação de cobrança: quem pode corrigir, em qual prazo e exigindo o quê?
    • Encerramento manual de caso: quais perfis podem encerrar e quais motivos exigem aprovação?
    • Exportação da fila é requisito da Fase 1?
    • Existem metas por atendente/equipe? Hoje o dashboard mostra produtividade, mas não meta.
    • Período de referência dos indicadores do dashboard: mês corrente, últimos 30 dias, ou selecionável pelo usuário?

    Lista completa e detalhada em docs/OPEN-QUESTIONS.md.

    22.2 Decisões já tomadas durante o protótipo (destaques)

    DecisãoResumo
    Data de referência congeladaTodos os cálculos usam 09/09/2026 como "hoje", não a data real da máquina
    Promessa vinculada obrigatoriamente a uma açãoNão existe promessa "solta" — o botão "Criar promessa" reaproveita o modal de registrar ação
    Promessa quebrada avaliada em leituraSem job agendado nesta fase; em produção isso vira um processo em fila (BullMQ)
    Escopo de visão da fila por perfilRegra implementada: quem tem "ver toda a carteira" vê tudo; Agência vê só sua unidade; demais veem só o que lhes foi atribuído + sem responsável
    Faixas de atraso e de valor em arquivo de configuraçãoNenhum valor de faixa fica fixo no código-fonte
    Handoff humano sinalizado, não configurávelA interface sempre mostra o aviso; não existe opção de desativar essa proteção
    Escrita de ação como operação únicaRegistrar uma ação dispara todos os efeitos (promessa, timeline, status do caso, auditoria) em uma única operação — no backend real, isso será uma transação

    Lista completa das 14 decisões em docs/PHASE-1.2-DECISIONS.md, e dos impactos identificados no modelo de dados em docs/BACKEND-DATA-MODEL-IMPACTS.md.

    ↑ voltar ao topo da seção

    Referência

    23.Glossário de siglas e termos

    PF / PJPessoa Física / Pessoa Jurídica
    CPF / CNPJDocumentos de identificação de PF/PJ — sempre mascarados no protótipo
    CCSCentral de Serviços — correspondente/parceiro externo que trata a carteira de menor valor (Faixa 1)
    PTPPromise to Pay — termo de mercado para promessa de pagamento
    SIPSession Initiation Protocol — protocolo usado para conectar a telefonia à plataforma de voz por IA
    LGPDLei Geral de Proteção de Dados
    CDCCódigo de Defesa do Consumidor
    AnatelAgência Nacional de Telecomunicações — regula volume/autenticação de chamadas
    RBACRole-Based Access Control — controle de acesso por perfil
    KPIKey Performance Indicator — indicador-chave de desempenho
    Policy EngineMotor de regras que define os limites financeiros que a IA pode oferecer numa negociação
    Saldo vencido agregadoSoma de todas as dívidas vencidas de um cliente, base da priorização da fila
    Régua de cobrançaConjunto de condições que classifica o cliente em uma carteira e define seu tratamento
    Caso de cobrançaO contexto de cobrança de um cliente — reúne suas dívidas, ações e histórico
    Ação de cobrançaRegistro de qualquer interação de cobrança, humana ou de IA — a entidade mais importante do sistema
    HandoffTransferência obrigatória do atendimento de um agente de IA para um humano
    Autonomia (nível 1/2/3)Grau de liberdade de negociação de um agente de IA
    ↑ voltar ao topo da seção

    Referência

    24.Mapa da documentação do projeto

    Este manual descreve o "como usar". Para o "por quê" e para o detalhamento técnico completo, a documentação do projeto está organizada assim:

    ArquivoConteúdo
    CLAUDE.mdMemória técnica e funcional principal do projeto
    docs/BUSINESS-RULES.mdRegras de negócio fechadas na Fase 0
    docs/PHASE-1.2-DECISIONS.mdLog de decisões tomadas durante a construção do protótipo
    docs/BACKEND-DATA-MODEL-IMPACTS.mdO que o frontend revelou que deve mudar no modelo de dados
    docs/OPEN-QUESTIONS.mdPerguntas em aberto para o negócio validar
    docs/specs/01-visao-e-dominio.mdVisão de produto, personas, conceito central
    docs/specs/02-modulos-e-fluxos.mdMapa funcional completo de módulos e telas
    docs/specs/03-modelo-de-dados.mdDicionário de dados completo — 36 tabelas (modelo preliminar)
    docs/specs/04-arquitetura-e-integracoes.mdStack técnica e decisões de telefonia/WhatsApp/SMS
    docs/specs/05-design-system-sicoob.mdCores, tipografia, menu, UX e acessibilidade
    ↑ voltar ao topo da seção