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.
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:
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.
| Perfil | Escopo de visão | Uso típico |
|---|---|---|
| Administrador | Configuração total do sistema | TI / configuração geral |
| Gestor de Cobrança | Toda a carteira | Estratégia, réguas, agentes de IA, indicadores |
| Supervisor | Suas equipes | Acompanha equipe, distribui casos, monitora IA |
| Atendente / Negociador | Sua fila (casos atribuídos a si + sem responsável) | Trabalho operacional diário na fila |
| Jurídico | Casos escalonados (visão de toda a carteira) | Casos encaminhados para tratamento judicial |
| Agência / Cooperativa | Sua agência/unidade | Atendimento local na própria agência |
| Auditor | Todo o histórico permitido, somente leitura | Conformidade, LGPD, Banco Central |
| Agente de IA | Identidade própria nas ações — não é um usuário humano convencional | Executa 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ção2.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}".
- 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").
- Confirme a entrada — o botão muda para "Entrar como {primeiro nome}" e fica habilitado somente após a seleção.
- Você cai no Dashboard — a tela inicial após o login é sempre o Dashboard.
| Nome | Perfil | Unidade |
|---|---|---|
| Marcelo Aguiar | Administrador | Unidade 1 |
| Renata Salgado | Gestor de Cobrança | Unidade 1 |
| Fábio Toledo | Supervisor | Unidade 1 |
| Juliana Prado | Atendente / Negociador | Unidade 2 |
| Anderson Vilela | Atendente / Negociador | Unidade 2 |
| Camila Bastos | Atendente / Negociador | Unidade 3 |
| Tiago Meireles | Atendente / Negociador | Unidade 4 |
| Cristiane Rocha | Jurídico | Unidade 1 |
| Paulo Henrique Sá | Agência / Cooperativa | Unidade 5 |
| Débora Nunes | Auditor | Unidade 1 |
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.
- 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:
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:
| Tipo | Formato | Exemplo |
|---|---|---|
| Moeda | R$ 0.000,00 | R$ 30.000,00 |
| Data | dd/mm/aaaa | 09/09/2026 |
| Data e hora | dd/mm/aaaa hh:mm | 09/09/2026 14:30 |
| Decimal | vírgula | 12,5% |
| CPF/CNPJ | sempre mascarado nos mocks | ***.456.789-** |
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.
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.
| Grupo | Item | Rota | Permissão necessária |
|---|---|---|---|
| Visão geral | Dashboard | / | dashboard.view |
| Cobrança | Fila de cobrança | /fila | queue.view |
| Clientes e casos | /clientes | queue.view | |
| Ações de cobrança | /acoes | queue.view | |
| Promessas e negociações | /promessas | queue.view | |
| Inteligência e automação | Réguas de cobrança | /reguas | queue.view (editar: rule.manage) |
| Agentes de IA | /agentes | queue.view (editar: agent.manage) | |
| Agenda e execuções | /execucoes | queue.view | |
| Dados | Importações | /importacoes | import.manage |
| Pagamentos | /pagamentos | payment.view | |
| Gestão | Equipes | /equipes | user.manage |
| Usuários | /usuarios | user.manage | |
| Perfis e permissões | /perfis | user.manage | |
| Governança | Auditoria | /auditoria | audit.view |
| Configurações | Configurações gerais | /configuracoes | settings.manage |
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.
4.Dashboard
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).
4.1 Indicadores (linha 1 — visão geral)
| Indicador | O que mostra |
|---|---|
| Saldo vencido da carteira | Soma do saldo vencido agregado de todos os casos visíveis, com o número de casos ativos |
| Recuperado no período | Valor recebido, com a taxa de recuperação (recuperado ÷ (vencido + recuperado)) |
| Clientes em cobrança | Quantidade de clientes com caso ativo, destacando quantos estão sem contato recente |
| Saldo a vencer | Base da carteira preventiva — parcelas ainda não vencidas |
4.2 Indicadores (linha 2 — operacionais)
| Indicador | O que mostra |
|---|---|
| Promessas em aberto | Contagem e valor total das promessas ainda vigentes |
| Promessas quebradas | Contagem e valor total das promessas não cumpridas no prazo |
| Ações hoje | Ações registradas na data de referência, separando humanas de IA |
| Contactabilidade | Percentual de ações que resultaram em algum tipo de contato efetivo |
4.3 Gráficos e tabelas
- 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.
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.
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.
5.Fila de cobrança
Lista de trabalho principal do atendente: quem contatar, em que ordem e com qual prioridade.
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:
| Chip | O que traz |
|---|---|
| Toda a fila | Todos os casos visíveis ao usuário (sem recorte adicional) |
| Minha fila | Casos atribuídos ao usuário logado |
| Sem responsável | Casos ainda não atribuídos a ninguém |
| Ação vencida ou hoje | Casos com próxima ação agendada para hoje ou já vencida |
| Com promessa | Casos com uma promessa ativa em aberto |
| Promessa quebrada | Casos com promessa quebrada (histórico ou vigente) |
| Sem contato | Sem nenhuma ação registrada, ou sem contato efetivo há mais de 15 dias, ou o último resultado foi um dos tipos "sem contato" |
| Alta prioridade | Casos com prioridade Alta (definida pela régua) |
| IA agendada | Casos com uma execução de agente de IA agendada ou em andamento |
5.3 Colunas da tabela
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.
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).
6.Clientes e casos
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ção7.Caso de cobrança — visão 360º do 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.
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 agregado | Soma de todas as parcelas vencidas de todas as operações do cliente |
| Saldo a vencer | Parcelas ainda dentro do prazo |
| Maior atraso | Maior número de dias de atraso entre as operações do cliente |
| Operações · parcelas em aberto | Quantidade de contratos e de parcelas ainda não quitadas |
| Recuperado neste caso | Valor já pago desde a abertura do caso |
| Promessas em aberto | Contagem e soma das promessas vigentes |
| Próxima ação | Tipo e data agendados, ou "não agendada" |
7.3 Ações disponíveis no topo da página
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
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.
8.Registrar ação de cobrança
O formulário mais usado do sistema — todo contato humano com o cliente é registrado aqui.
8.1 Campos do formulário
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:
- A ação é criada — com identificador próprio, sempre como um registro novo (nunca sobrescreve um existente).
- Um evento entra na timeline do caso, com o canal e o resultado escolhidos.
- Se houver promessa, ela é criada já vinculada a esta ação, com situação inicial "Em aberto".
- 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.
- Se o resultado for "Encaminhado ao jurídico", o caso é automaticamente reatribuído a um usuário do perfil Jurídico.
- A data/tipo da última e da próxima ação do caso são atualizados, refletindo imediatamente na fila.
- Um toast de confirmação aparece ("Ação registrada"), e o modal fecha.
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.
9.Ações de cobrança
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.
"Ações imutáveis: correção entra como novo registro vinculado ao original."
10.Promessas e negociações
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."
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.
11.Pagamentos
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.
Pagamentos são simulados; a conciliação real com o Core Banking da cooperativa é um item de fase futura (ver seção 21).
12.Réguas de cobrança
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.
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:
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:
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.
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.
"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égua | Critério de entrada | Tratamento |
|---|---|---|
| Cobrança Vencida — Faixa 1 | Saldo vencido agregado até R$ 30.000,00 | CCS |
| Cobrança Vencida — Faixa 2 | Acima de R$ 30.000,00 até R$ 100.000,00 | Equipe interna |
| Cobrança Vencida — Faixa 3 | Acima de R$ 100.000,00 | Equipe interna / especializada |
| Cobrança Preventiva | Parcelas com vencimento nos próximos 45 dias | Todos os canais |
| Prejuízo | Cliente classificado na carteira de prejuízo | Todos os canais |
| Cheque Especial | Utilização ininterrupta | Todos os canais |
| Cartão Vencido | Cartão/fatura em situação de vencimento | Todos 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ção13.Agentes de IA
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.
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ível | Nome | Comportamento |
|---|---|---|
| 1 | Comunicação | Informa dívida, vencimento, valores e orientações autorizadas — não negocia |
| 2 | Negociação Assistida | Apresenta apenas condições já pré-autorizadas pela instituição |
| 3 | Negociação Autônoma | Negocia 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.
"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.
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.
14.Agenda e execuções
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ção15.Importações
Simula a forma como, no sistema definitivo, clientes, dívidas, parcelas e pagamentos chegarão à plataforma: por planilha Excel.
15.1 O assistente de 4 passos
- Selecionar arquivo — escolha o tipo de planilha (Clientes, Operações e parcelas, ou Pagamentos) e envie o arquivo (
.xlsx,.xlsou.csv) por arrastar-e-soltar ou pelo seletor. Formato inválido gera um aviso e bloqueia o envio. - Validando — indicador de progresso enquanto o sistema simula a leitura do arquivo.
- 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.
- Resumo — confirmação do lote processado, com as contagens finais, e o botão "Importar outra planilha".
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ção16.Equipes, usuários e perfis
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ão | O que libera |
|---|---|
| Visualizar fila | Acessar Fila, Clientes, Ações, Promessas, Réguas, Agentes, Execuções |
| Visualizar toda a carteira | Ver casos de todos os clientes, não só os atribuídos a si |
| Registrar ação | Registrar contatos e criar promessas |
| Gerenciar promessas | Cancelar promessas em aberto |
| Distribuir casos | Alterar o responsável por um caso |
| Visualizar dashboard | Acessar a tela inicial de indicadores |
| Administrar réguas | Editar condições e ativar/desativar réguas |
| Administrar agentes de IA | Editar configuração e ativar/desativar agentes |
| Importar planilhas | Acessar o módulo de Importações |
| Visualizar pagamentos | Acessar a tela de Pagamentos |
| Administrar usuários | Acessar Equipes, Usuários e Perfis |
| Visualizar auditoria | Acessar a trilha de auditoria |
| Alterar configurações | Acessar Configurações gerais |
17.Auditoria
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ção18.Configurações gerais
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.
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.
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
| Resultado | Grupo | Exige | Muda situação do caso para |
|---|---|---|---|
| Contato realizado | Com contato | próxima ação, observações | Em tratamento |
| Sem contato | Sem contato | próxima ação | — |
| Telefone não atende | Sem contato | próxima ação | — |
| Número inválido | Sem contato | observações | — |
| Caixa postal / recado | Sem contato | próxima ação | — |
| Negociação realizada | Negociação | próxima ação, observações | Em negociação |
| Promessa de pagamento | Negociação | próxima ação, promessa | Promessa em aberto |
| Acordo fechado | Negociação | próxima ação, promessa, observações | Acordo vigente |
| Recusa de negociação | Negociação | próxima ação, observações | Aguardando cliente |
| Solicitação de retorno | Com contato | próxima ação | Aguardando cliente |
| Contestação da dívida | Encaminhamento | próxima ação, observações | Suspenso |
| Sem capacidade de pagamento | Encaminhamento | próxima ação, observações | Aguardando cliente |
| Encaminhado ao gestor | Encaminhamento | próxima ação, observações | Em tratamento |
| Encaminhado ao jurídico | Encaminhamento | observações | Jurídico (+ reatribuição automática) |
| Outros | Com contato | observaçõ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
| Perfil | O que vê na fila e no dashboard |
|---|---|
| Administrador, Gestor de Cobrança, Supervisor, Jurídico, Auditor | Toda a carteira |
| Agência / Cooperativa | Apenas casos da própria unidade organizacional |
| Atendente / Negociador | Apenas 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
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
| Norma | O que exige da plataforma |
|---|---|
| Banco Central | Ética, responsabilidade, transparência, diligência e tratamento justo considerando a vulnerabilidade do cliente |
| CDC | Cliente inadimplente não pode ser exposto a ridículo, constrangimento ou ameaça |
| LGPD | Finalidade, necessidade, transparência, segurança e responsabilização; medidas técnicas e administrativas desde a concepção (privacy by design) |
| Anatel | Contabilizar volume de chamadas desde o início — relevante à medida que a IA de voz ganhar escala |
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 tela | Código | Badge |
|---|---|---|
| Aberto | OPEN | neutro |
| Em tratamento | IN_PROGRESS | info |
| Aguardando cliente | WAITING_CUSTOMER | neutro |
| Promessa em aberto | PROMISE_PENDING | alerta |
| Em negociação | NEGOTIATION | info |
| Acordo vigente | AGREEMENT_ACTIVE | sucesso |
| Jurídico | LEGAL | crítico |
| Suspenso | SUSPENDED | alerta |
| Regularizado | RESOLVED | sucesso |
| Encerrado | CLOSED | neutro |
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ótulo | Código | Badge |
|---|---|---|
| Em aberto | OPEN | alerta |
| Cumprida | FULFILLED | sucesso |
| Parcialmente cumprida | PARTIALLY_FULFILLED | info |
| Quebrada | BROKEN | crítico |
| Cancelada | CANCELLED | neutro |
20.3 Canais de contato
| Rótulo | Código |
|---|---|
| Telefone | PHONE |
WHATSAPP | |
| WhatsApp Voice | WHATSAPP_VOICE |
| SMS | SMS |
EMAIL | |
| Presencial | IN_PERSON |
| Registro manual | MANUAL |
| Sistema | SYSTEM |
| Outro | OTHER |
20.4 Ator da ação
| Rótulo | Código |
|---|---|
| Humano | HUMAN |
| Agente de IA | AI |
| Sistema | SYSTEM |
20.5 Prioridade do caso
Alta HIGH Média MEDIUM Baixa LOW
20.6 Situação da execução de agente de IA
| Rótulo | Código | Badge |
|---|---|---|
| Agendado | SCHEDULED | neutro |
| Executando | RUNNING | info |
| Concluído | COMPLETED | sucesso |
| Sem contato | NO_CONTACT | alerta |
| Falha | FAILED | crítico |
| Cancelado | CANCELLED | neutro |
20.7 Situação da importação
| Rótulo | Código | Badge |
|---|---|---|
| Enviado | UPLOADED | neutro |
| Validando | VALIDATING | info |
| Processando | PROCESSING | info |
| Concluído | COMPLETED | sucesso |
| Concluído com erros | COMPLETED_WITH_ERRORS | alerta |
| Falhou | FAILED | crí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
| Rótulo | Código |
|---|---|
| Saldo vencido agregado | OVERDUE_AMOUNT |
| Dias de atraso | DAYS_PAST_DUE |
| Parcelas em aberto | OPEN_INSTALLMENTS |
| Produto | PRODUCT |
| Tipo de pessoa | PERSON_TYPE |
| Agência | ORGANIZATIONAL_UNIT |
| Promessas quebradas | BROKEN_PROMISES |
| Rótulo | Código |
|---|---|
| igual a | EQ |
| diferente de | NEQ |
| maior que | GT |
| maior ou igual a | GTE |
| menor que | LT |
| menor ou igual a | LTE |
| entre | BETWEEN |
| está em | IN |
| não está em | NOT_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)
| Faixa | Intervalo |
|---|---|
| A vencer | até 0 dias |
| 1 a 15 dias | 1–15 |
| 16 a 30 dias | 16–30 |
| 31 a 60 dias | 31–60 |
| 61 a 90 dias | 61–90 |
| Acima de 90 dias | 91+ |
| Faixa | Intervalo |
|---|---|
| V1 — Até R$ 30 mil | até R$ 30.000,00 |
| V2 — R$ 30 mil a R$ 100 mil | R$ 30.000,01 a R$ 100.000,00 |
| V3 — Acima de R$ 100 mil | a partir de R$ 100.000,01 |
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
| Funcionalidade | Por que ainda não existe |
|---|---|
| Seletor de período no dashboard | Indicadores hoje somam toda a base mockada — falta o recorte por período |
| Correção de ação de cobrança | Depende de definir quem pode corrigir, em qual prazo e com qual justificativa |
| Encerramento manual de caso e reabertura | Depende de definir alçada (quais perfis podem encerrar e quais motivos exigem aprovação) |
| Exportação da fila para Excel | Ainda não confirmado como requisito da Fase 1 |
| Auditoria de acessibilidade com leitor de tela | Contraste, foco e navegação por teclado foram construídos, mas não auditados formalmente |
21.2 O que vem depois da Fase 1.2
| Fase | Entrega |
|---|---|
| 1.3 — Validação e consolidação dos fluxos | Usar este protótipo para responder as perguntas em aberto com o negócio |
| 2 — Backend, banco de dados e APIs | Node.js + TypeScript, PostgreSQL, filas (Redis/BullMQ), eventos em tempo real, storage de arquivos |
| 3+ — Telefonia, WhatsApp Voice, Analytics, IA Copilot, IA Voice | Integrações reais com Net2Phone, ElevenLabs e biblioteca de WhatsApp não-oficial (Zapo) |
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ão | Resumo |
|---|---|
| Data de referência congelada | Todos os cálculos usam 09/09/2026 como "hoje", não a data real da máquina |
| Promessa vinculada obrigatoriamente a uma ação | Não existe promessa "solta" — o botão "Criar promessa" reaproveita o modal de registrar ação |
| Promessa quebrada avaliada em leitura | Sem job agendado nesta fase; em produção isso vira um processo em fila (BullMQ) |
| Escopo de visão da fila por perfil | Regra 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ção | Nenhum valor de faixa fica fixo no código-fonte |
| Handoff humano sinalizado, não configurável | A interface sempre mostra o aviso; não existe opção de desativar essa proteção |
| Escrita de ação como operação única | Registrar 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.
23.Glossário de siglas e termos
| PF / PJ | Pessoa Física / Pessoa Jurídica |
| CPF / CNPJ | Documentos de identificação de PF/PJ — sempre mascarados no protótipo |
| CCS | Central de Serviços — correspondente/parceiro externo que trata a carteira de menor valor (Faixa 1) |
| PTP | Promise to Pay — termo de mercado para promessa de pagamento |
| SIP | Session Initiation Protocol — protocolo usado para conectar a telefonia à plataforma de voz por IA |
| LGPD | Lei Geral de Proteção de Dados |
| CDC | Código de Defesa do Consumidor |
| Anatel | Agência Nacional de Telecomunicações — regula volume/autenticação de chamadas |
| RBAC | Role-Based Access Control — controle de acesso por perfil |
| KPI | Key Performance Indicator — indicador-chave de desempenho |
| Policy Engine | Motor de regras que define os limites financeiros que a IA pode oferecer numa negociação |
| Saldo vencido agregado | Soma de todas as dívidas vencidas de um cliente, base da priorização da fila |
| Régua de cobrança | Conjunto de condições que classifica o cliente em uma carteira e define seu tratamento |
| Caso de cobrança | O contexto de cobrança de um cliente — reúne suas dívidas, ações e histórico |
| Ação de cobrança | Registro de qualquer interação de cobrança, humana ou de IA — a entidade mais importante do sistema |
| Handoff | Transferê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 |
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:
| Arquivo | Conteúdo |
|---|---|
CLAUDE.md | Memória técnica e funcional principal do projeto |
docs/BUSINESS-RULES.md | Regras de negócio fechadas na Fase 0 |
docs/PHASE-1.2-DECISIONS.md | Log de decisões tomadas durante a construção do protótipo |
docs/BACKEND-DATA-MODEL-IMPACTS.md | O que o frontend revelou que deve mudar no modelo de dados |
docs/OPEN-QUESTIONS.md | Perguntas em aberto para o negócio validar |
docs/specs/01-visao-e-dominio.md | Visão de produto, personas, conceito central |
docs/specs/02-modulos-e-fluxos.md | Mapa funcional completo de módulos e telas |
docs/specs/03-modelo-de-dados.md | Dicionário de dados completo — 36 tabelas (modelo preliminar) |
docs/specs/04-arquitetura-e-integracoes.md | Stack técnica e decisões de telefonia/WhatsApp/SMS |
docs/specs/05-design-system-sicoob.md | Cores, tipografia, menu, UX e acessibilidade |