Pular para o conteúdo
Histórico de chats
Novo chat
Imagens
ATUALIZADO
Confira planos e preços
Configurações
Ajuda

Receba respostas personalizadas para você

Entre para receber respostas com base em chats salvos, além de criar imagens e carregar arquivos.

Entrar
ChatGPT
Entrar
Cadastre-se gratuitamente

Esta é uma cópia de um chat compartilhado do ChatGPT. Isso não será adicionado à memória.

Denunciar conversa
ontem 12:27
Pensou por 2m 51s

Sim. E pela pesquisa, dá para transformar isso em uma plataforma de cobrança bastante completa, sem começar grande demais.

Antes do plano, há duas conclusões importantes.

A primeira é que você descreveu, na prática, 5 carteiras de cobrança, não 3: Vencida, Preventiva, Prejuízo, Cheque Especial e Cartão Vencido. Dentro de Vencida existem ainda três faixas operacionais.

A segunda é mais importante: eu não colocaria WaCalls como tecnologia principal de WhatsApp em produção numa instituição financeira sem antes comparar com a API oficial de chamadas do WhatsApp. A Meta lançou oficialmente a WhatsApp Business Calling API em julho de 2025; ela permite chamadas recebidas e iniciadas pela empresa, além de integração de voz por SIP/WebRTC. Para chamadas iniciadas pela empresa, existe um fluxo formal de permissão do cliente. 
WhatsApp for Business
+1

1. Como eu enxergo o produto

Eu o trataria não simplesmente como um "discador", mas como uma Plataforma de Gestão e Inteligência de Recuperação de Crédito.

O núcleo seria:

Carteira → Régua → Cliente → Caso de cobrança → Tentativas de contato → Negociação/Promessa → Resultado → Acompanhamento.

O sistema precisa responder rapidamente perguntas como:

Quem devo contatar hoje?
Quem já foi contatado?
Quem prometeu pagar?
Quem não cumpriu a promessa?
Quem ninguém conseguiu localizar?
Quanto da carteira já foi trabalhado?
Qual funcionário está conseguindo mais contatos efetivos?
Qual canal funciona melhor?
Onde a IA está performando melhor que os humanos?

Esse conceito aparece nos produtos mais maduros que analisei. Plataformas como Credgenics trabalham com segmentação, prioridade, PTP (Promise to Pay), disposições de chamada, análise de contactabilidade, horários, canais e acompanhamento em tempo real. 
Credgenics
+1

2. As réguas de cobrança

Eu modelaria suas regras assim:

Carteira	Critério	Tratamento
Cobrança Vencida — Faixa 1	saldo vencido agregado até R$ 30 mil	CCS
Cobrança Vencida — Faixa 2	acima de R$ 30 mil até R$ 100 mil	Equipe interna
Cobrança Vencida — Faixa 3	acima de R$ 100 mil	Equipe interna / especializada
Cobrança Preventiva	parcelas com vencimento nos próximos 45 dias	Todos
Prejuízo	cliente classificado na carteira de prejuízo	Todos
Cheque Especial	utilização ininterrupta	Todos
Cartão Vencido	cartão/fatura em situação de vencimento	Todos

Um detalhe importante: na Cobrança Vencida, eu calcularia a faixa pelo saldo vencido agregado do cliente, e não por contrato individual.

Exemplo:

Cliente tem:

Contrato A → R$ 18 mil vencidos
Contrato B → R$ 17 mil vencidos

Total vencido = R$ 35 mil.

Portanto entraria na Faixa 2.

Isso deve ser feito automaticamente pelo motor de regras.

3. Os valores das réguas não devem ficar no código

Você já antecipou corretamente isso.

Teremos algo como:

Administração → Réguas de Cobrança
Regra	Valor inicial	Valor final	Responsável
Vencida Faixa 1	R$ 0	R$ 30.000	CCS
Vencida Faixa 2	R$ 30.000,01	R$ 100.000	Interna
Vencida Faixa 3	R$ 100.000,01	Sem limite	Interna
Preventiva	D-45	D-1	Interna

Assim, amanhã você poderia mudar R$30 mil para R$40 mil sem alterar uma linha de código.

O mesmo vale para os 45 dias da preventiva.

4. Um conceito que eu acrescentaria: "Caso de cobrança"

Eu evitaria trabalhar somente com cliente.

Teríamos:

Cliente
↓
Contratos/Exposições
↓
Caso de cobrança

Isso é importante porque o mesmo cliente pode aparecer hoje na preventiva e daqui a alguns meses na vencida, ou posteriormente na carteira de prejuízo.

O histórico não pode desaparecer quando ele muda de régua.

Exemplo:

João da Silva

Caso #4281

Carteira atual:
Cobrança Vencida > R$30k até R$100k

Saldo vencido:
R$ 68.450

Contratos:
3

Dias em atraso:
22

Último contato:
07/09/2026

Resultado:
Promessa de pagamento

Promessa:
10/09/2026 — R$ 15.000

5. O frontend

A tela inicial poderia ter grandes cards:

Card	Indicadores
🔴 Cobrança Vencida	clientes / R$ vencido
🟡 Cobrança Preventiva	clientes / R$ a vencer
⚫ Prejuízo	clientes / exposição
🟠 Cheque Especial	clientes / exposição
🔵 Cartão Vencido	clientes / exposição

E dentro de Cobrança Vencida:

┌─────────────────────────┐
│ Até R$ 30 mil           │
│ 1.287 clientes          │
│ R$ 11,4 milhões         │
│ Responsável: CCS        │
└─────────────────────────┘

┌─────────────────────────┐
│ R$ 30 mil — R$ 100 mil │
│ 392 clientes            │
│ R$ 22,7 milhões         │
└─────────────────────────┘

┌─────────────────────────┐
│ Acima de R$ 100 mil     │
│ 84 clientes             │
│ R$ 31,6 milhões         │
└─────────────────────────┘


Ao clicar em qualquer card, abre a fila de cobrança.

6. Tela da fila de cobrança

Essa provavelmente será a tela mais utilizada pelos 10 funcionários.

Eu imagino algo assim:

Cliente	Saldo	Atraso	Último contato	Status	Ações
João Silva	R$ 48 mil	22 dias	ontem	PTP	☎️ 📱 👤
Maria Souza	R$ 71 mil	13 dias	nunca	Novo	☎️ 📱 👤
Empresa XYZ	R$ 96 mil	41 dias	3 dias	Sem contato	☎️ 📱 👤

Os ícones poderiam ser:

☎️ net2phone
📱 WhatsApp Calling
🤖 IA

E isso precisa obedecer à configuração administrativa.

7. Configuração dos discadores

Sua ideia está correta.

Teríamos:

Administração → Telefonia
Discadores disponíveis

[✓] net2phone
[✓] WhatsApp

Discador padrão:
[ net2phone ▼ ]


Se somente net2phone estiver habilitado:

☎ Ligar


Se ambos estiverem:

☎ net2phone
📱 WhatsApp


E posteriormente:

🤖 Ligação por IA

8. net2phone — encontrei exatamente o que precisamos

A integração parece bastante favorável.

A documentação oficial atual da net2phone possui API, webhooks e Click-to-Call.

Inclusive existe endpoint documentado para iniciar uma chamada a partir de uma aplicação externa:

POST /api/calls/

E os webhooks retornam eventos de chamadas, permitindo registrar chamadas concluídas, perdidas, não atendidas, duração etc. 
net2phone.helpjuice.com

Portanto o fluxo pode ser:

Funcionário
     ↓
botão ☎
     ↓
Nossa API
     ↓
net2phone API
     ↓
Ligação
     ↓
webhook net2phone
     ↓
Nossa plataforma
     ↓
Histórico da cobrança


Isso é exatamente o tipo de integração que eu usaria.

9. WaCalls — resposta à sua principal dúvida

Pesquisei o código/dependências do projeto.

Sim. O WaCalls já possui a biblioteca WhatsApp integrada.

Ele utiliza:

whatsmeow

diretamente no projeto Go. O go.mod inclui explicitamente go.mau.fi/whatsmeow. 
GitHub

Além disso, o próprio WaCalls já possui:

Recurso	WaCalls
QR Code	✅
conexão WhatsApp	✅
múltiplas sessões	✅
persistência das sessões	✅
ligação WhatsApp	✅
receber ligação	✅
WebRTC no navegador	✅
API HTTP	✅
eventos SSE	✅
whatsmeow	✅

O próprio projeto diz que permite parear múltiplas contas WhatsApp, cada uma com seu QR e status independente. 
GitHub

Portanto:

não precisamos instalar Evolution API ou Z-API para o WaCalls funcionar.

10. Como ficariam as conexões WhatsApp

A sua plataforma poderia ter:

Administração → Conexões → WhatsApp
Cobrança 01
🟢 Conectado
+55 31 XXXXX-XXXX

Cobrança 02
🟢 Conectado
+55 31 XXXXX-XXXX

Cobrança 03
🔴 Desconectado

[Reconectar]
[Gerar QR]
[Desconectar]


Por trás:

Frontend
       ↓
Backend da Plataforma
       ↓
WaCalls API
       ↓
whatsmeow
       ↓
WhatsApp


O usuário nunca acessaria diretamente o WaCalls.

11. Mas encontrei um problema sério no WaCalls

O próprio autor declara:

a API não possui autenticação.

Qualquer pessoa que alcançar a API consegue criar sessões, realizar chamadas e consultar histórico.

Além disso, o SQLite utilizado pelo projeto armazena credenciais das sessões WhatsApp. 
GitHub

Para uma instituição financeira isso é inaceitável em produção.

Por isso eu faria:

Internet/LAN
      ↓
Nossa aplicação
      ↓
Autenticação + RBAC
      ↓
API Gateway interno
      ↓
WaCalls


WaCalls ficaria em rede Docker privada, sem porta pública acessível pelos computadores dos funcionários.

12. Mas existe hoje uma alternativa melhor que o WaCalls

Esse foi um dos achados mais relevantes da pesquisa.

Hoje existe oficialmente:

WhatsApp Business Calling API.

A própria Meta anunciou o recurso em julho de 2025. Ela permite receber e realizar chamadas diretamente pelo WhatsApp Business Platform. 
WhatsApp for Business

E existem implementações que suportam:

SIP ou WebRTC. 
360dialog Docs

Portanto agora temos duas alternativas:

	WaCalls	Meta Calling API
Oficial	❌	✅
QR/dispositivo	✅	❌
WhatsApp Business API	❌	✅
WhatsApp Calling	✅	✅
SIP/WebRTC	WebRTC próprio	✅
Multiusuário	✅	✅
Segurança corporativa	precisamos construir	superior
Estabilidade contratual	risco	maior
Adequado a instituição financeira	⚠️	✅ preferível

E existe uma diferença muito importante: em chamadas iniciadas pela empresa, a API oficial exige que o cliente tenha concedido permissão para ser chamado pelo WhatsApp. 
WhatsApp Serpro
+1

Minha recomendação

Para um banco/cooperativa/instituição financeira:

Produção: estudar primeiro WhatsApp Business Calling API oficial.

PoC/laboratório: WaCalls.

Eu não faria o core da operação institucional ficar dependente de um protocolo WhatsApp Web reversamente implementado se existe agora uma opção oficial.

13. Arquitetura que recomendo

Não criaria dez microserviços.

Para apenas 10 operadores, eu utilizaria um monólito modular, deixando telefonia e IA desacopladas.

                    ┌────────────────────┐
                    │      FRONTEND      │
                    │   React / Web App  │
                    └─────────┬──────────┘
                              │
                    ┌─────────▼──────────┐
                    │      CORE API      │
                    │                    │
                    │ Clientes           │
                    │ Carteiras          │
                    │ Réguas             │
                    │ Casos              │
                    │ Contatos           │
                    │ PTP                │
                    │ Importações        │
                    │ Relatórios         │
                    │ Permissões         │
                    └──────┬───┬────────┘
                           │   │
            ┌──────────────┘   └───────────────┐
            ▼                                  ▼
      PostgreSQL                         Job Queue
                                             │
                     ┌───────────────────────┼──────────────────┐
                     ▼                       ▼                  ▼

                net2phone              WhatsApp           IA Voice
                Adapter               Adapter             Orchestrator
                     │                       │                  │
               net2phone            Meta Calling       STT → LLM → TTS
                                         ou
                                      WaCalls

14. Eu criaria uma interface única de telefonia

Esse é um ponto arquitetural importante.

O Core não deve saber como net2phone nem WhatsApp funcionam.

Criamos:

CallProvider


com operações conceituais como:

startCall()
endCall()
getCallStatus()
getHistory()
handleEvent()


Depois:

Net2PhoneProvider
MetaWhatsAppCallingProvider
WaCallsProvider


Assim amanhã você pode remover WaCalls e colocar Meta sem reconstruir a plataforma inteira.

15. CCS merece um módulo específico

Não faria simplesmente um botão "importar Excel".

Teríamos:

CCS → Importações

O Excel entra primeiro numa área de staging.

O sistema:

arquivo Excel
     ↓
validação
     ↓
preview
     ↓
duplicidades
     ↓
erros
     ↓
vinculação CPF/CNPJ
     ↓
vinculação contrato
     ↓
importação


Cada importação gera um lote:

Lote CCS #2026-09-08-01

Registros recebidos: 1.328
Importados: 1.301
Duplicados: 19
Com erro: 8

[Ver erros]
[Ver contatos]


E todo contato efetuado pela CCS entra no mesmo histórico do cliente usado pelos funcionários internos.

Isso é crucial.

16. Evitar cobrança duplicada

Imagine:

CCS liga às 9h.

Um funcionário interno abre o cliente às 9h15 e liga novamente.

É péssimo operacionalmente e para o cliente.

Por isso o sistema precisa ter um controle de contactabilidade.

Exemplo:

⚠ Cliente contatado há 27 minutos pela CCS.

Resultado:
Falou com cliente

Próximo contato permitido:
10/09/2026


O supervisor poderia ignorar o bloqueio, mas precisaria informar uma justificativa.

17. O resultado de toda ligação deve ser estruturado

Essa é outra prática recorrente em plataformas maduras.

Após encerrar:

Isso é chamado frequentemente de Disposition/Sub-disposition em plataformas de cobrança. Sistemas especializados permitem configurar essas classificações e inclusive criar PTP diretamente durante a ligação. 
Credgenics

18. Promise to Pay — PTP

Essa deveria ser uma entidade de primeira classe no sistema.

Exemplo:

No dia 11:

ou:

🔴 Promessa quebrada

Cliente com promessa quebrada pode subir automaticamente na prioridade da fila.

19. Um detalhe fundamental: precisamos saber se ele pagou

Isso exigirá uma alimentação de dados da instituição.

Não necessariamente precisamos fazer integração online com o Core Banking já no MVP.

Podemos começar com:

Arquivo diário da carteira
       ↓
Importação
       ↓
Sistema compara D-1 × D
       ↓
Saldo alterou?
Contrato liquidou?
Parcela foi paga?

Mais tarde:

Core Banking
     ↓ API/SFTP/ETL
Plataforma

Sem essa informação, conseguiremos registrar promessa de pagamento, mas não teremos como afirmar automaticamente que a promessa foi cumprida.

20. Benchmarking: o que vale copiar

Na pesquisa aparecem padrões bastante consistentes.

Credgenics trabalha com segmentação por risco, controles de frequência, horários, DND, masking de dados, PTP, dashboards, priorização por probabilidade de pagamento e escolha de canal/horário. 
Credgenics
+1

PAIR Finance combina dados e comportamento para escolher canal, horário, solução, frequência e tonalidade, em vez de usar a mesma régua para todos. 
PAIR Finance

TrueAccord aposta em abordagem digital-first e autoatendimento para aumentar a resolução sem depender exclusivamente de telefonia. 
TrueAccord

Genesys usa controles como número máximo de tentativas, horários permitidos, listas de contatos, prioridade, regras, Caller ID e vários modos de discagem. 
Genesys Cloud Resource Center
+1

Daí eu tiraria uma regra importante para nosso projeto:

não construir apenas uma agenda de telefonemas. Construir um motor de estratégia de cobrança.

21. Onde entra a IA

Eu dividiria a IA em três níveis.

Nível 1 — Copiloto

Primeiro eu implantaria IA ajudando os 10 funcionários.

Durante/depois da ligação:

Ligação
 ↓
Transcrição
 ↓
IA
 ↓
Resumo
 ↓
Sentimento
 ↓
Motivo da inadimplência
 ↓
PTP detectada
 ↓
Próxima ação sugerida

O funcionário não precisaria escrever tudo.

22. Nível 2 — Priorização

A IA começa a responder:

Para quem devo ligar primeiro?

Inicialmente, nem usaria ML.

Faria um score explicável:

Prioridade =
dias atraso
+ valor exposição
+ tempo sem contato
+ PTP quebrada
+ histórico de contactabilidade
+ carteira

Depois de acumularmos dados reais, podemos treinar modelos para:

Probability to Contact

e:

Probability to Pay.

Esse é justamente um dos usos de ML presentes em plataformas modernas de cobrança. 
PAIR Finance
+1

23. Nível 3 — Agente de cobrança por voz

A arquitetura seria aproximadamente:

             Cliente
                ↑↓
             Telefonia
                ↑↓
         ┌──────────────┐
         │ Voice Gateway│
         └──────┬───────┘
                │ áudio
                ▼
              STT
                ↓
               LLM
                ↓
               TTS
                ↓
              áudio

Mas o LLM não deveria possuir autonomia financeira irrestrita.

A conversa é da IA.

As regras financeiras são do sistema.

Por exemplo:

IA:
"Posso oferecer parcelamento?"

       ↓

Policy Engine

Cliente X
Carteira Y

Máximo:
12 parcelas

Desconto máximo:
8%

Entrada mínima:
20%

A IA recebe somente as opções permitidas.

Ela jamais inventa uma taxa, saldo ou desconto.

24. Eu começaria IA na cobrança preventiva

Isso reduz muito o risco.

Exemplo:

"Olá, estou entrando em contato pela instituição X. Sou o assistente virtual de relacionamento. Identificamos uma parcela com vencimento nos próximos dias..."

A cobrança preventiva é muito mais previsível que:

Prejuízo
↓
contestação
↓
renegociação
↓
questões jurídicas
↓
vulnerabilidade financeira

Depois que o sistema estiver estável, expandimos.

PAIR Finance, por exemplo, usa IA para classificar demandas e encaminhar casos mais complexos para humanos, justamente em vez de tentar automatizar tudo indiscriminadamente. 
PAIR Finance

25. Handoff humano obrigatório

Precisamos ter gatilhos como:

Cliente contesta dívida
            ↓
       HUMANO

Cliente informa fraude
            ↓
       HUMANO

Cliente demonstra vulnerabilidade
            ↓
       HUMANO

IA não possui confiança
            ↓
       HUMANO

Cliente pede atendente
            ↓
       HUMANO

Ou seja:

AI first, human always available.

26. Compliance não pode ser uma etapa posterior

Estamos falando de instituição financeira + cobrança + IA + dados financeiros.

O Banco Central determina que instituições observem ética, responsabilidade, transparência e diligência e dispensem tratamento justo e equitativo considerando inclusive vulnerabilidades do cliente. 
Banco Central do Brasil

O CDC também estabelece que, na cobrança de dívidas, o inadimplente não pode ser exposto a ridículo, constrangimento ou ameaça. 
Palácio do Planalto

E a LGPD traz princípios como finalidade, necessidade, transparência, segurança e responsabilização, além de exigir medidas técnicas e administrativas desde a concepção do serviço. 
Palácio do Planalto
+1

Portanto eu criaria Compliance by Design, não tentaria colocar depois.

27. Teremos um "Policy Engine de contatos"

Isso é importante principalmente quando a IA começar a escalar.

Ele controlaria automaticamente:

Horário permitido
Quantidade máxima de tentativas
Intervalo entre tentativas
Dias permitidos
Número inválido
Cliente já contatado
PTP vigente
Cliente em disputa
Cliente bloqueado
Canal permitido
Permissão WhatsApp Calling

E ninguém — nem operador humano nem IA — pula essas regras sem permissão.

28. A regra de telefonia da Anatel também mudou

Esse é outro motivo para não codificar regras regulatórias diretamente no sistema.

A página oficial da Anatel, atualizada em 28 de agosto de 2026, informa que o uso do 0303 foi tornado facultativo pelo Acórdão nº 201/2025. 
Serviços e Informações do Brasil

Ao mesmo tempo, a Anatel passou a exigir autenticação de chamadas para os chamados grandes chamadores, atualmente definidos como usuários com mais de 500 mil chamadas mensais por prestadora, usando mecanismos de autenticação de chamadas. 
Serviços e Informações do Brasil
+1

Para dez operadores humanos provavelmente isso ficará longe, mas com agentes de IA o volume pode mudar radicalmente.

Então a plataforma deveria contabilizar chamadas mensais desde o primeiro dia.

29. Segurança

Para esse projeto eu considero obrigatório:

Controle	Implementação
RBAC	✅
MFA/SSO	✅
segregação operador/supervisor/admin	✅
trilha de auditoria	✅
criptografia	✅
masking CPF/telefone	✅
secrets fora do código	✅
expiração de sessão	✅
logs de acesso	✅
retenção configurável	✅
gravação protegida	✅
histórico imutável de contatos	✅
auditoria das ações da IA	✅

Inclusive a LGPD exige medidas de segurança adequadas contra acesso ou tratamento indevido. 
Palácio do Planalto

30. Menu que eu proporia para o sistema
Dashboard

Carteiras
   ├── Cobrança Vencida
   ├── Preventiva
   ├── Prejuízo
   ├── Cheque Especial
   └── Cartão Vencido

Minha Fila

Clientes

Promessas
   ├── A vencer
   ├── Cumpridas
   └── Quebradas

Contatos
   ├── Ligações
   ├── Agendamentos
   └── Histórico

CCS
   ├── Importações
   ├── Resultados
   └── Pendências

IA
   ├── Agentes
   ├── Campanhas
   ├── Conversas
   └── Avaliação

Relatórios

Administração
   ├── Usuários
   ├── Equipes
   ├── Réguas
   ├── Disposições
   ├── Telefonia
   ├── Conexões WhatsApp
   ├── IA
   ├── Política de contatos
   ├── Importações
   └── Auditoria
31. Modelo de dados inicial

Eu partiria aproximadamente destas entidades:

users
teams

customers
customer_phones

contracts
installments

collection_cases
collection_portfolios
collection_rules

case_assignments

contact_attempts
call_sessions
call_events
call_dispositions

promises_to_pay
followups

import_batches
import_rows
ccs_interactions

dialer_providers
whatsapp_connections

ai_agents
ai_calls
ai_transcripts
ai_actions

policy_rules

audit_events

Isso nos dá uma base bastante robusta sem exagerar.

32. Plano de desenvolvimento

Eu não começaria codificando ainda. Dividiria o projeto em dez fases:

Fase	Objetivo	Resultado
0	Definição funcional	PRD + regras de negócio
1	UX/UI	frontend mockado
2	Fundação	autenticação, usuários, RBAC, banco
3	Carteiras	clientes, contratos, casos e réguas
4	Operação	fila, contatos, PTP, follow-up
5	CCS	importação e acompanhamento Excel
6	Telefonia	net2phone
7	WhatsApp Voice	Meta Calling ou WaCalls
8	Analytics	dashboards e KPIs
9	IA Copilot	transcrição, resumo, classificação
10	IA Voice	agente autônomo controlado

Eu colocaria IA Voice somente depois do core operacional estar produzindo dados reais.

33. Antes da Fase 1, faria três PoCs técnicas

Aqui eu abriria exceção e faria prova de conceito antes do sistema.

PoC A — net2phone

Validar:

API
click-to-call
webhook
caller ID
status
duração
gravação
SIP disponível
acesso a RTP

A API Click-to-Call já está documentada oficialmente; precisamos validar o que especificamente está habilitado na conta da instituição. 
net2phone.helpjuice.com

PoC B — WhatsApp oficial

Validar:

WhatsApp Business Calling API
SIP
WebRTC
permissão para chamadas
WABA
número institucional
PoC C — WaCalls

Validar:

Docker
10 operadores
2-3 sessões
ligações simultâneas
áudio
reconexão
QR
eventos
estabilidade
rede corporativa

Assim a decisão não será baseada em opinião.

Será baseada em teste.

34. Minha recomendação tecnológica inicial

Para o Core:

Frontend
React + TypeScript

Backend
Node.js + TypeScript
Fastify ou NestJS

Banco
PostgreSQL

Fila
Redis + BullMQ

Eventos frontend
SSE/WebSocket

Storage
S3/MinIO

Containers
Docker

Telefonia:

net2phone
        ↓
Net2Phone Adapter

Meta WhatsApp Calling
        ↓
WhatsApp Adapter

WaCalls
        ↓
serviço Go isolado

Isso mantém o sistema tecnologicamente simples para dez operadores, mas preparado para crescer.

35. O grande diferencial que eu colocaria

Eu não faria a página simplesmente dizer:

"Você tem 427 clientes para ligar."

Eu faria:

HOJE

🔥 PRIORIDADE ALTA
34 clientes
R$ 4,8 milhões

⚠ PTP QUEBRADAS
17 clientes
R$ 1,2 milhão

📞 RETORNOS AGENDADOS
21 clientes

🆕 SEM NENHUM CONTATO
48 clientes

🤖 INDICADOS PARA IA
63 clientes

💰 MAIOR POTENCIAL DE RECUPERAÇÃO
26 clientes

Aí deixamos de ter um simples software de registro e passamos a ter uma plataforma que efetivamente coordena a estratégia de cobrança.

Minha proposta para iniciarmos

A ordem que eu considero correta é:

PRD e regras de negócio → arquitetura → modelo de dados → mapa completo das telas → frontend mockado → PoCs net2phone/WhatsApp → backend → IA.

E eu faria uma mudança importante na ideia original: WaCalls permaneceria como Provider possível, mas nossa arquitetura já nasceria preparada para a WhatsApp Business Calling API oficial. O fato de essa API oficial existir hoje muda bastante a decisão tecnológica que eu tomaria para uma instituição financeira. 
WhatsApp for Business

O próximo passo ideal é montarmos a Fase 0 — Especificação Funcional, detalhando tela por tela, regra por regra, papéis dos 10 funcionários, ciclo completo de cada uma das cinco carteiras, campos dos clientes, estados possíveis de um caso, importação CCS, PTP, agenda e KPIs. A partir dela podemos construir o frontend mockado sem ainda gastar esforço com backend.

Fontes
ontem 18:05

Vou fazer mais algumas ponderações: sua ideia de transformar em uma Plataforma de Gestão e Inteligência de Recuperação de Crédito e fantastica... Preciso de falar que neste item 6. Tela da fila de cobrança , para cada cliente, deverá ter uma nova ação que é de cadastrar a ação do registro da cobrança. ou seja, o atendente vai ligar, tratar com o cliente sobre a cobrança e o desenrolar deste contato deverá ser registrado através o preenchimento de um formulário num modal. Um detalhe importante: os agentes de IA eles funcionarão por VOZ ou por mensagem. Os agentes de voz, nós vamos usar os agentes da eleven labs, então temos que ter uma conexão API com a elevel labs para consumir estes agentes e estes agentes usarão a rede SIP da net2fone para falar com os clientes. Toda a tratativa da conversa por voz, será transcrita e será salva na ação do regsitro de cobrança do cliente. Os agentes que entrarão em contato via mensagem whatsapp, estas conversas também serão registradas na ação do registro de cobrança. Acredito que teremos que ter uma área de configuração deste agentes para colocar a data, horário e quais reguas de cobrança eles irão atuar. OU mesmo criar uma régua de cobrança de clientes de forma personalizada, ou seja, eu marco os clientes que o agente irá cobrar de forma personalizada caso eu não o coloque numa régua padrão. Não pretendo usar whatsapp api oficial. Vou usar não oficial. Estou pensando em implementar contatos via SMS, já temos contrato com a INFOBIP. Neste caso poderíamos fazer alguma integração API com a 'https://www.infobip.com/' para disparo de SMS. Seria interessante saber se o SMS foi aberto pelo usuario ou se ele leu o SMS. Para disparo de mensagens whatsapp, estou pensando usar a lib 'https://zapo.to/en/introduction' tem o github 'https://github.com/vinikjkkj/zapo'. Não sei se aquela lib de conexao para ligação eu conseguiria enviar mensagens, você poderia verificar isso, pois caso positivo, eu não precisaria realizar duas conexões de um mesmo dispositivo para mensagens e para ligação. Para envio das mensagens whatsapp, eu vou precisar saber se o cliente leu a mensagem. Se ele interagir com ela, uma IA poderá ser acionada, caso este contato esteja configurado lá na central de IAs como um contato a ser atendido por esta IA, seja ela IA de texto ou IA de voz. Para as mensagens de whatsapp, terei várias conexões de whatsapp pois assim, eu evitarei rete limit da meta. Para cada contato de cliente existente, eu vou definir a qual conexão whatsapp ele estará definido. Para estas conexões whatsapp, eu vou precisar de um health para verificar a saúde de cada conexão para eu tentar me blindar de banimento. OU seja, cada conexão teria um rate de health de conexão para avaliar a conexao e eu tomar precaução caso uma conexão esteja com rate baixo de health.

Mostrar mais
Pensou por 55s

Perfeito. Essas novas ponderações mudam a plataforma de um sistema de gestão de carteira para algo mais próximo de uma Central Omnichannel de Recuperação de Crédito com operação humana e autônoma por IA.

E há uma descoberta técnica especialmente importante: é bastante possível evitarmos duas conexões WhatsApp para o mesmo número.

1. O “Registro de Cobrança” deve virar uma entidade central

Concordo totalmente com a nova ação na fila.

Eu mudaria a tela que propus anteriormente para algo assim:

Cliente	Exposição	Atraso	Última ação	Status	Ações
João Silva	R$ 48 mil	22 dias	ontem	Promessa	☎️ 📱 💬 📝
Maria Souza	R$ 71 mil	13 dias	nunca	Novo	☎️ 📱 💬 📝

Onde:

☎️ ligação net2phone
📱 ligação WhatsApp
💬 mensagem WhatsApp/SMS
📝 registrar ação de cobrança

Ao clicar em Registrar ação, abriríamos o modal.

Registro da ação
Cliente
João da Silva

Data/hora
08/09/2026 14:32

Canal
[ Ligação telefônica ▼ ]

Realizado por
[ Marcelo ▼ ]

Resultado
[ Cliente localizado ▼ ]

Motivo / classificação
[ Promessa de pagamento ▼ ]

Descrição da tratativa
┌──────────────────────────────────────┐
│ Cliente informou que receberá...    │
└──────────────────────────────────────┘

Houve promessa de pagamento?
[✓] Sim

Valor
R$ __________

Data prometida
__/__/____

Próxima ação
[ Retornar ao cliente ▼ ]

Data do retorno
__/__/____ __:__

[Cancelar]             [Registrar]

Mas existe uma característica importante:

esse mesmo Registro de Cobrança será utilizado por humanos e pelas IAs.

2. Humano e IA alimentam o mesmo histórico

Isso simplifica muito o produto.

Teremos algo conceitualmente assim:

CLIENTE
   │
   └── CASO DE COBRANÇA
            │
            ├── Registro #1
            │   Humano
            │   Ligação net2phone
            │
            ├── Registro #2
            │   IA
            │   WhatsApp
            │
            ├── Registro #3
            │   IA
            │   Ligação ElevenLabs
            │
            └── Registro #4
                CCS
                Importação Excel

Não importa de onde o contato veio.

Tudo termina em:

Registro de Cobrança.

Eu chamaria tecnicamente essa entidade de algo como:

collection_interaction

ou:

collection_action
3. Registro humano × registro automático da IA

O humano preencherá o modal.

A IA fará isso automaticamente.

Por exemplo, uma ligação do agente ElevenLabs terminou.

A plataforma recebe:

Duração: 04:18
Cliente localizado: SIM

Resumo:
Cliente informou dificuldade financeira temporária
e afirmou que efetuará pagamento parcial.

Resultado:
PROMESSA_DE_PAGAMENTO

Valor:
R$ 5.000

Data:
12/09/2026

Automaticamente nasce:

Registro de Cobrança #92871

Origem:
IA

Canal:
Ligação telefônica

Agente:
Agente Preventivo 01

Resultado:
Promessa de pagamento

Resumo:
...

Transcrição:
[Visualizar]

Áudio:
[Ouvir]

Próxima ação:
Verificar pagamento em 13/09/2026

Isso é tecnicamente muito viável com ElevenLabs.

A ElevenLabs possui post-call webhooks que entregam depois da chamada a transcrição completa, metadados e resultados das análises da conversa. Há inclusive recursos para extrair dados estruturados do diálogo. 
ElevenLabs
+1

Portanto, essa integração que você imaginou casa muito bem com o nosso modelo.

4. Eu faria uma pequena separação por segurança

Não colocaria a transcrição gigantesca diretamente dentro do registro principal.

Teríamos:

collection_action
    │
    ├── resumo
    ├── resultado
    ├── promessa
    ├── próxima ação
    │
    └── communication_session_id
                        │
                        ▼
              communication_session
                    ├── transcript
                    ├── recording
                    ├── provider
                    ├── duração
                    └── metadata

Na interface o usuário verá tudo como se fosse um único registro.

Mas tecnicamente separamos.

Isso facilita retenção, auditoria, segurança e armazenamento.

5. ElevenLabs + net2phone: sua arquitetura faz sentido

A pesquisa confirmou isso.

A ElevenLabs hoje suporta SIP Trunking externo para os seus agentes, tanto para chamadas recebidas quanto realizadas. O SIP pode trabalhar com autenticação Digest ou ACL, e a documentação prevê G.711/G.722 e RTP/SRTP. 
ElevenLabs

E existe API específica de chamada outbound:

ElevenLabs Agent
       ↓
ElevenLabs SIP
       ↓
net2phone SIP Trunk
       ↓
PSTN
       ↓
Cliente

A net2phone, por sua vez, oferece oficialmente SIP Trunking e documenta integração com PABXs como Asterisk/FreePBX, Cisco, Avaya etc. 
Net2Phone
+1

Portanto, conceitualmente a arquitetura é compatível.

Mas eu colocaria isso obrigatoriamente numa PoC porque precisamos verificar exatamente o produto net2phone que sua instituição contratou e parâmetros como autenticação, codecs, TLS, SRTP, Caller ID e chamadas simultâneas.

Se houver alguma incompatibilidade, temos ainda uma solução:

ElevenLabs
     ↓
SIP
     ↓
Asterisk / FreeSWITCH / SBC
     ↓
net2phone
     ↓
Cliente

Mas só acrescentaria essa camada se realmente for necessária.

6. A Central de IA precisa existir

Aqui eu mudaria bastante meu desenho anterior.

Teríamos:

IA → Agentes

Exemplo:

Agente:
Ana Preventiva

Tipo:
● Voz
○ Texto

Provider:
ElevenLabs

ElevenLabs Agent ID:
agent_xxxxx

Status:
Ativo

Carteiras permitidas:
✓ Preventiva
✓ Cartão
□ Vencida
□ Prejuízo
□ Cheque Especial

Mas eu não colocaria agenda dentro do cadastro do agente.

Existe uma razão arquitetural importante.

O agente é uma coisa.

A campanha de cobrança é outra.

7. Agente ≠ Campanha

O agente representa:

"Quem conversa."

A campanha representa:

"Quem deverá ser contatado, quando, como e por qual agente."

Então teríamos:

IA → Agentes

e:

IA → Campanhas

Exemplo:

CAMPANHA

Nome
Preventiva D-10

Agente
Ana Preventiva

Canal
Ligação telefônica

Carteira
Cobrança Preventiva

Filtro
Vencimento entre D-10 e D-5

Execução
Segunda a sexta

Horário
09:00 - 17:00

Máximo simultâneo
3 ligações

Status
ATIVA

Isso é muito mais flexível.

8. E sua ideia de cobrança personalizada entra perfeitamente aqui

Teremos dois tipos de público:

Público dinâmico

Baseado nas réguas.

Cobrança Vencida
AND
saldo_vencido > 30000
AND
saldo_vencido <= 100000

Ou:

Preventiva
AND
vencimento <= D+10
Público selecionado

Você simplesmente seleciona clientes.

Na fila:

☑ João Silva
☑ Maria Costa
☑ Empresa ABC
☐ Antônio Lima

[Adicionar à campanha IA]

Depois:

Campanha:
Cobrança Especial Setembro

Clientes:
128

Agente:
Agente Voz 03

Canal:
Ligação

Iniciar:
09/09/2026

Horário:
10h às 16h

Excelente recurso.

9. Eu acrescentaria ainda um terceiro tipo: segmento inteligente

Por exemplo:

Clientes da carteira Vencida
acima de R$ 100 mil
nunca contatados
sem promessa vigente
com telefone válido.

A interface permitiria montar regras:

Carteira = Vencida

E

Saldo vencido > R$ 100.000

E

Último contato > 7 dias

E

Promessa vigente = Não

Esse público se atualizaria automaticamente.

Eu chamaria isso de:

Segmentos

ou:

Listas Inteligentes.

10. A descoberta mais interessante: talvez não precisemos WaCalls + Zapo

Isso mudou desde nossa primeira análise.

A versão atual da Zapo é muito mais completa do que apenas mensageria.

O projeto atualmente fornece:

zapo-js
   ├── mensagens
   ├── mídia
   ├── sessões
   ├── contatos
   ├── storage
   └── @zapo-js/voip
            └── ligações

A documentação do projeto mostra suporte a múltiplas sessões e o plugin @zapo-js/voip; há inclusive um exemplo em que a mesma WaClient recebe uma mensagem e inicia uma ligação. 
GitHub
+1

A versão mais recente listada atualmente é a 1.7.1, publicada em 11 de agosto de 2026. O VoIP entrou oficialmente no projeto a partir da versão 1.3.0. 
GitHub

Isso é MUITO interessante para nosso projeto.

11. Opção A — Zapo para tudo

Poderíamos ter:

WhatsApp Gateway

      Zapo

        │
   ┌────┴─────┐
   │          │
Messages     VoIP
   │          │
   └────┬─────┘
        │
 WhatsApp Session

Ou seja:

1 QR Code.
1 dispositivo vinculado.
1 sessão.
Mensagem + ligação.

Essa hoje é a alternativa que eu investigaria primeiro.

12. Opção B — continuar usando WaCalls

Também é possível.

O WaCalls usa whatsmeow internamente para manter a sessão WhatsApp. 
GitHub
+1

E o whatsmeow, por sua vez, possui nativamente:

envio de mensagens, recebimento de mensagens e recibos de entrega/leitura. 
GitHub
+2
GitHub
+2

Então tecnicamente poderíamos fazer:

WaCalls
   │
whatsmeow
   │
   ├── VoIP
   └── Messages   ← acrescentaríamos

O problema é que o WaCalls atualmente está orientado a chamadas; precisaríamos ampliar sua API.

Por isso agora minha preferência inicial seria:

PoC 1 — Zapo unificada

Se funcionar bem:

Zapo será nosso WhatsApp Gateway.

Não precisamos de WaCalls.

Se o VoIP da Zapo se mostrar menos estável:

PoC 2 — WaCalls + ampliação do whatsmeow

Ainda assim tentaríamos usar uma única sessão.

13. Eu evitaria duas bibliotecas acessando simultaneamente a mesma sessão

Não faria:

Número WhatsApp
       │
       ├── Zapo
       │
       └── WaCalls

ao mesmo tempo com o mesmo estado de autenticação.

Isso aumenta muito a complexidade de sincronização e pode causar conflitos de sessão.

O ideal é:

1 número
   ↓
1 WhatsApp Gateway
   ↓
mensagem + ligação
14. E poderemos saber se a mensagem WhatsApp foi lida?

Sim, com ressalvas.

O protocolo utilizado pelo whatsmeow possui eventos explícitos:

Delivered
Read
Played

e a própria documentação descreve que um evento Receipt pode informar quando mensagem enviada foi entregue ou lida. 
GitHub
+1

Portanto nosso histórico poderá ser:

14:02 ✓ Enviada

14:02 ✓✓ Entregue

14:07 🔵 Lida

14:09 💬 Cliente respondeu

Mas não devemos considerar ausência de Read como prova de que a pessoa não leu, porque configurações de privacidade e comportamento dos dispositivos afetam read receipts. Há inclusive relatos desse comportamento no ecossistema whatsmeow. 
GitHub

15. A resposta do cliente pode acionar automaticamente a IA

Exatamente.

Esse fluxo seria muito interessante:

Campanha
   ↓
Mensagem WhatsApp
   ↓
Cliente recebe
   ↓
Cliente responde
   ↓
Webhook/evento
   ↓
Conversation Router
   ↓
Este contato possui IA?
       │
   ┌───┴────┐
  NÃO      SIM
   │         │
Fila       Qual IA?
humana       │
       ┌─────┴─────┐
       ↓           ↓
    Texto         Voz
       ↓           ↓
     LLM       ElevenLabs

Isso nos leva a outra entidade fundamental:

Conversation Router

Ele decidirá quem atende uma nova interação.

16. Exemplo

Maria recebeu:

"Olá Maria, identificamos uma pendência em seu contrato. Podemos conversar sobre as possibilidades de regularização?"

Maria responde:

"Sim. Quero saber o valor."

O sistema consulta:

customer_id: 8827

ai_enabled: true

inbound_handler:
agente_cobranca_texto_02

Então imediatamente:

WhatsApp
    ↓
Zapo
    ↓
Conversation Router
    ↓
Agente IA
    ↓
Resposta

E tudo vai sendo salvo na mesma conversa.

Ao finalizar:

Conversation
     ↓
Resumo IA
     ↓
Registro de Cobrança
17. SMS via Infobip encaixa muito bem

Eu acrescentaria:

CommunicationProvider

├── Net2PhoneProvider
├── ElevenLabsProvider
├── WhatsAppProvider
└── InfobipSmsProvider

A Infobip disponibiliza API e webhooks para SMS, incluindo delivery reports em tempo real. Portanto conseguimos saber, por exemplo:

SMS
Enviado
   ↓
Aceito
   ↓
Entregue no aparelho

Infobip
+1

18. Mas há uma diferença importante: SMS não informa leitura

Aqui precisamos tomar cuidado.

SMS tradicional não possui recibo real de leitura.

A própria Infobip diferencia isso explicitamente: eventos SEEN estão disponíveis para WhatsApp, RCS, Viber etc., mas não para SMS tradicional. 
Infobip
+1

Então:

Evento SMS	Conseguimos?
Enviado	✅
Entregue no aparelho	✅
Falhou	✅
Usuário leu	❌
Usuário respondeu, se SMS bidirecional	✅
Usuário clicou num link rastreado	✅

A Infobip suporta URL shortening com click tracking para SMS, inclusive enviando o clique por webhook. 
Infobip

Então poderíamos fazer algo interessante.

19. SMS com ação rastreável

Em vez de:

Entre em contato conosco para regularizar sua pendência.

Poderíamos enviar:

Consulte as opções disponíveis: suaempresa.com/x7Yp9

Então:

SMS enviado
    ↓
Entregue
    ↓
Cliente clicou
    ↓
CLICK recebido
    ↓
Registro de cobrança atualizado

Não significa literalmente "leu o SMS".

Mas significa:

houve interação confirmada.

Isso é muito mais útil operacionalmente.

20. No futuro poderíamos estudar RCS

Já que vocês possuem Infobip, existe algo particularmente interessante.

RCS permite:

Delivered
Seen
Response
Buttons
Rich content

A Infobip oferece efetivamente eventos SEEN em RCS. 
Infobip
+1

Então poderíamos ter futuramente:

WhatsApp
SMS
RCS
Ligação

na mesma plataforma.

Mas deixaria RCS fora do MVP.

21. Sobre várias conexões WhatsApp

Faz sentido a plataforma suportar vários números institucionais e permitir associar cada cliente a uma conexão.

Algo assim:

Administração → WhatsApp → Conexões
Conexão	Número	Clientes	Estado	Saúde
Cobrança 01	31 xxxx	1.847	🟢	96
Cobrança 02	31 xxxx	1.661	🟢	91
Prejuízo	31 xxxx	892	🟡	73
Preventiva	31 xxxx	1.973	🔴	22

E em cada cliente:

Canal WhatsApp preferencial

[ Cobrança 02 ▼ ]

Isso eu considero excelente.

22. Mas mudaria o conceito de “health contra banimento”

Podemos e devemos construir um Connection Health Score, mas eu não o desenharia para rotacionar contas com o objetivo de contornar limites ou mecanismos de bloqueio do WhatsApp.

Além de ser operacionalmente arriscado, isso faria o sistema depender de comportamento de evasão da plataforma.

O health seria voltado à confiabilidade operacional.

Por exemplo:

Connection Health

Estado da sessão
Última atividade
Tempo conectado
Reconexões nas últimas 24h
Falhas de envio
Mensagens não entregues
Latência
Erros de protocolo
QR solicitado novamente
Sessão desconectada
Receipts recebidos
Último heartbeat

Se deteriorar:

Health 93
🟢 Saudável

Health 71
🟡 Atenção

Health 42
🟠 Degradada

Health 18
🔴 Crítica

E aí o sistema poderia pausar novos envios daquela conexão e exigir avaliação, em vez de simplesmente transferir o volume para outra conta para contornar uma restrição.

23. Outro conceito: Channel Assignment

Cada cliente pode possuir:

Cliente
João Silva

Telefone:
+55...

WhatsApp Connection:
Cobrança 02

SMS Sender:
Instituição

Agente texto:
Pedro Cobrança

Agente voz:
Ana Cobrança

Mas não deixaria isso completamente fixo.

Teríamos:

preferred_whatsapp_connection

e o roteador avaliaria se a conexão está operacional antes do contato.

24. A Central de IA que agora imagino

Eu ampliaria bastante:

IA
├── Dashboard
├── Agentes
├── Campanhas
├── Segmentos
├── Conversas
├── Ligações
├── Agenda
├── Avaliações
└── Configurações
Agentes

Define quem é a IA.

Campanhas

Define o trabalho da IA.

Segmentos

Define quem será contatado.

Agenda

Define quando ocorrerá.

Conversas

Mostra WhatsApp/SMS.

Ligações

Mostra ElevenLabs.

Avaliações

Permite ao supervisor verificar a qualidade.

25. O cadastro de um agente ficaria mais ou menos assim
IDENTIFICAÇÃO

Nome
Agente Cobrança Preventiva

Tipo
[ Voz ]

Provider
[ ElevenLabs ]

Agent ID
[........................]


COMPORTAMENTO

Instruções
[................................]

Restrições
[................................]

Base de conhecimento
[................................]


REGRAS

Pode negociar?
SIM / NÃO

Pode gerar PTP?
SIM / NÃO

Pode oferecer acordo?
SIM / NÃO

Escalonar para humano quando:
[...]


CANAIS

✓ Ligação net2phone
□ WhatsApp texto
□ WhatsApp voz
□ SMS
26. E a campanha
Campanha: Preventiva Setembro

Agente:
Ana

Público:
Cobrança Preventiva

Filtro:
Vencimento em até 10 dias

Canal:
Ligação

Fallback:
1. WhatsApp
2. SMS

Dias:
SEG TER QUA QUI SEX

Janela:
09:00 → 17:00

Tentativas:
máximo configurado

Intervalo:
configurado

Se cliente responder:
Agente Ana

Se solicitar humano:
Fila Equipe Cobrança

Aqui começamos a ter realmente uma orquestração de cobrança.

27. Ficaria ainda mais interessante com fallback de canal

Por exemplo:

09:00
Ligação IA
     ↓
Não atendeu

13:00
WhatsApp
     ↓
Não entregue

D+1
SMS
     ↓
Entregue

D+3
Fila humana

O Policy Engine controla essa sequência.

Não o LLM.

28. Arquitetura revisada

Com tudo que você acrescentou, eu redesenharia assim:

                         FRONTEND
                            │
                            ▼
                    ┌───────────────┐
                    │   CORE API    │
                    └───────┬───────┘
                            │
       ┌────────────────────┼─────────────────────┐
       │                    │                     │
       ▼                    ▼                     ▼
 COLLECTION CORE       AI ORCHESTRATOR      COMMUNICATION HUB
       │                    │                     │
 Clientes              Agentes                   │
 Contratos             Campanhas        ┌────────┼────────┐
 Carteiras             Segmentos        │        │        │
 Réguas                Scheduler        ▼        ▼        ▼
 Casos                 Router       Telefonia WhatsApp   SMS
 Ações                 Policies         │        │        │
 PTP                                   │        │        │
 Follow-up                              │        │        │
       │                          net2phone      Zapo   Infobip
       │                               │
       │                         ElevenLabs
       │                               │
       └─────────── REGISTRO DE COBRANÇA ────────┘

Esse desenho está ficando bastante consistente.

29. O ponto que eu mais gostei nessa arquitetura

Tudo termina em uma única linha do tempo.

Imagine abrir João Silva:

JOÃO SILVA

08/09 09:20
🤖 WhatsApp
Mensagem enviada

08/09 09:24
👁 Mensagem lida

08/09 09:31
💬 Cliente respondeu
"Quero negociar"

08/09 09:32
🤖 IA assumiu atendimento

08/09 09:44
🤝 Promessa de pagamento
R$ 8.000 — 12/09

12/09
⚠ Promessa não identificada como paga

13/09 10:13
☎ Agente ElevenLabs
Ligação — 04m32s

13/09 10:18
📝 Registro automático
Cliente solicitou retorno em 15/09

15/09 14:10
👤 Carlos
Ligação manual net2phone

15/09 14:17
✅ Acordo realizado

Isso é exatamente o tipo de visão que eu buscaria para essa plataforma.

30. E agora eu alteraria o nosso plano de desenvolvimento

Com suas novas definições, eu ainda não começaria o código.

Nossa Fase 0 precisa agora produzir um documento bem mais completo:

Fase	Entrega
0.1	Domínio da Recuperação de Crédito
0.2	Modelo das cinco carteiras e réguas
0.3	Registro de Cobrança e PTP
0.4	Jornada do operador humano
0.5	Central de IA
0.6	Campanhas, segmentos e scheduler
0.7	Arquitetura omnichannel
0.8	PoC net2phone + ElevenLabs
0.9	PoC Zapo mensagem + VoIP na mesma sessão
0.10	PoC Infobip SMS/webhooks
0.11	Segurança, auditoria e compliance
0.12	Modelo de dados
0.13	Sitemap completo
0.14	Wireframes das principais telas
1	Frontend mockado
2	Core backend
3	Integrações
4	IA
Minha principal mudança de recomendação

Depois do que encontrei hoje, eu não escolheria ainda WaCalls nem Zapo.

Eu faria primeiro a PoC:

Uma sessão Zapo → enviar mensagem → detectar entrega/leitura → receber resposta → realizar ligação → receber ligação → várias chamadas simultâneas → reconectar sem perder sessão.

Se isso passar de forma consistente, eu escolheria Zapo como nosso WhatsApp Gateway único, porque eliminaria duas conexões e duas tecnologias para o mesmo número. 
GitHub
+2
GitHub
+2

E deixaria a arquitetura com interfaces abstratas, para que trocar Zapo futuramente não obrigue a reconstruir a plataforma.

O próximo trabalho que considero mais valioso é fecharmos a especificação funcional da Fase 0 inteira — principalmente Registro de Cobrança, Central de IA, Campanhas, Segmentos, WhatsApp Connections e a jornada completa de cada uma das cinco carteiras — antes de desenharmos sequer a primeira tabela do banco. Isso evitará que decisões técnicas acabem determinando regras de negócio que deveriam ser definidas pela operação.

Fontes
ChatGPT é uma IA e pode cometer erros.
