🧠 Método IAN · antes da IA, existe a direção

Salão no Controle OS

O projeto inteiro numa olhada: no centro o salão, ao redor os Superpoderes (cada um comandado por um Guardião), e envolvendo tudo a Mentoria — que ensina você e a equipe a usar o sistema. Mais abaixo, uma prévia de como fica com tudo integrado.

01 🧠 Método IAN · a direção

02 🎓 Mentoria · ensina a usar

03 🛠️ Sistema · executa e mede

🎓 MENTORIA envolve tudo

te ensina a usar o sistema

🧠Salão no Controletudo conversa e vira número no painel

🎓

A Mentoria envolve tudo

Ela ensina e acompanha você e a equipe a usar cada Superpoder — do primeiro dia ao domínio de cada Guardião. Inclui onboarding, trilha de implantação (90 dias), suporte e reunião de indicadores. Sozinho, o sistema é ferramenta; com a mentoria, vira resultado.

🖥️ Assim fica com tudo integrado

Uma prévia do seu painel: os Superpoderes trabalham juntos e viram números num lugar só. Cada cliente entra por uma ponta e o sistema acompanha até o caixa — e depois traz de volta.

Painel do Salão · IA Fabiana tudo integrado

Jornada da cliente — do anúncio ao retorno

Guardiões em ação agora

Números ilustrativos, só para você visualizar o produto funcionando.

⚡ Os 9 Superpoderes — o que cada um faz e o que tem dentro

Cada Superpoder é uma área do salão que o sistema resolve. Passa o olho em "dentro" pra ver os módulos, o Guardião responsável e o indicador que ele move.

🦸 O elenco dos Guardiões

Cada Guardião é um especialista de IA com um superpoder próprio — e conhece o SEU salão (serviços, preços, tom de voz, equipe).

🌉 A Ponte-mãe — Identidade Única do Cliente (roteiro técnico)

O primeiro passo pra sair do mapa e construir de verdade: fazer a mesma cliente ser reconhecida entre o CRM e o Recupera. É o alicerce — sem ele, nenhuma outra ponte se sustenta.

🎯 Objetivo: hoje a mesma Ana Paula é 11987654321 no CRM, 5511987654321 no Recupera e nada no Paga Aí. A ponte-mãe dá a ela um ID interno que nunca muda e usa o telefone no padrão 55DDD9XXXXXXXX (E.164) como o crachá que a encontra em qualquer app. Escopo: só a cliente final — CRM · Recupera · Paga Aí. O PublikaFácil fica de fora (é módulo do profissional).

Telefone canônico (E.164)

lib compartilhada · nos 2 apps

Uma única função de normalização, igual no CRM e no Recupera. Guardar sempre o formato com 55 + o "final" pra casamento tolerante.

# entra qualquer coisa → sai padrão normalize("(11) 98765-4321") → phone_e164 = "5511987654321" → phone_tail = "87654321" // 8 últimos

tira tudo que não é dígito
tem 10–11 díg. (DDD+nº)? prefixa 55
celular sem o 9º dígito → insere o 9
guarda phone_tail (8 díg.) p/ casar apesar de variações

ID interno do cliente

cadastro-mãe = CRM (LeadFlow)

Cada pessoa ganha um customer_id (UUID) que nunca muda. O telefone é um atributo — trocou de número, o ID continua.

customers { customer_id // UUID, imutável = o RG phone_e164 // 5511... phone_tail // 87654321 name, email?, cpf?, birthdate? merged_from[] // duplicatas fundidas }

Email e CPF entram só como secundários (bater pagamento / histórico antigo sem telefone).

Serviço de resolução

API no CRM · o "porteiro" da identidade

Todo app pergunta ao CRM "quem é essa pessoa?" e recebe o customer_id. Nunca mais casar só por nome.

POST /api/identity/resolve { phone, email?, name?, birthdate? } → { customer_id, matched_by, confidence } // ordem de casamento: phone_e164 → phone_tail → email → nome+nascim. // nada casou? cria novo customer_id POST /api/identity/merge { keep_id, merge_id }

Contrato CRM ↔ Recupera

a costura que faltava

O Recupera para de casar por nome e passa a usar o customer_id. Cada evento volta pro card do cliente no CRM.

// Recupera, ao mexer na agenda: POST /api/customers/{id}/events { type: "appointment"|"attended"|"noshow", service, datetime, value } // CRM, ao criar lead → devolve id+phone // os 2 falam pelo customer_id, não pelo nome

🪜 Ordem de execução

Função de normalização compartilhada base
a mesma lib de telefone nos dois apps — a peça mais simples e a mais importante.

Colunas novas nos 2 bancos
customer_id, phone_e164, phone_tail no CRM (SQLite) e no Recupera (Postgres).

Serviço resolve / merge no CRM
o porteiro da identidade — o único lugar que decide "quem é quem".

Recupera passa a consultar o CRM
troca o casamento-por-nome pela chamada /identity/resolve.

Backfill (uma vez só)
normaliza todos os telefones existentes, gera os tail, roda dedupe e atribui customer_id. Conflitos vão pra revisão manual.

⚠️ Riscos & como tratar

👨‍👩‍👧Telefone de família (2 pessoas, 1 número): 1 telefone = 1 cliente principal; casos raros resolvidos por email/nome, com marcação manual.

🔄Cliente trocou de número: atualiza o phone_e164 no mesmo customer_id — o histórico inteiro fica preservado.

👥Nomes iguais (Maria Silva): nunca casar só por nome — sempre exigir um 2º fator (telefone, email ou nascimento).

✅ Resultado: depois dessa ponte, a Ana Paula é uma só em todo o sistema. O CRM sabe que o lead virou agendamento; o Recupera sabe o histórico real; o Paga Aí passa a amarrar a receita à pessoa. As outras pontes viram fáceis — todas falam o mesmo customer_id.