Questionário de Elicitação, ModularCRM

Por que importa: por decisão de 2026-07-15, o lembrete de agendamento deixa de ser mandado pelo sistema por conta própria e passa a ser uma automação que a empresa monta, com o texto que ela quiser (requisito RF-AUTO-002 do DRS, card AUD-52 do Roadmap). Para as empresas que já existem a resposta já está fechada e não é esta pergunta: elas ganham a automação equivalente já provisionada e ativa, reproduzindo o texto e os canais atuais, porque perder o lembrete em silêncio seria defeito. Para a subconta nova não existe um comportamento de hoje a preservar, e as duas respostas se defendem. Nascer com a automação pronta e ativa mantém o padrão atual, a empresa que não mexer em nada continua mandando lembrete e descobre a automação quando quiser mudar o texto, mas aí ela não montou o lembrete, ele apareceu pronto, o que é menos fiel à ideia de que o lembrete é dela. Nascer sem automação nenhuma é mais fiel à decisão, e o custo é que a subconta que não montar nada nunca manda lembrete, e ninguém reclama de um lembrete que nunca existiu, então a falta passa despercebida. RESPONDIDA em 2026-07-15: nasce sem nada, a empresa monta. Nas palavras de quem decidiu, a subconta nova nasce limpa, quem quiser lembrete monta a automação, é mais honesto (nada roda que o cliente não pediu) e a tela não vem cheia de coisa pronta, mas quem não souber que existe fica sem. A regra passou a valer no RF-AUTO-002 do DRS, que registra os dois casos (empresa que já existe ganha a automação provisionada e ativa; subconta nova nasce sem nenhuma) e a consequência aceita. Esta pergunta está fechada e não bloqueia mais o card AUD-52 do Roadmap.

Por que importa: o RF-CONV-014 diz que os links rastreáveis servem "para usar em mensagens", sem separar a mensagem que a automação manda da mensagem que o operador digita à mão no Inbox. O caminho da automação é o que o {AUD-51} do [Roadmap de Implementação](/mds/modularcrm-roadmap) entrega: é ela que insere o link já com o id de envio daquele contato, e é por isso que o clique tem dono, aparece no histórico do contato e dispara a automação. O operador que copiar o endereço curto e colar à mão numa conversa manda um link sem dono: ele redireciona e conta o clique, e não atribui contato nem dispara nada. As duas respostas se defendem. Aceitar como está mantém o Inbox simples e deixa o rastreio ligado a quem monta automação, e o custo é que o operador não tem como saber que o link que ele colou não vai disparar: ele acha que disparou, e ninguém avisa o contrário. Fazer o Inbox expandir as variáveis resolve isso, e aí o nome do contato tem que ir junto por coerência, porque hoje o Inbox não expande variável nenhuma, nem o nome: entregar a expansão só para o link seria arbitrário. Os cards estão abertos no Roadmap, o {AUD-64} (o Inbox expandir as variáveis, que depende desta resposta) e o {AUD-61} (a variável do nome chegar vazia na maioria dos gatilhos, que é defeito e independe desta resposta). Enquanto a pergunta não for respondida, o RF-CONV-014 vale como está escrito, e o disparo é o do caminho da automação.

Por que importa: o {AUD-90} do [Roadmap de Implementação](/mds/modularcrm-roadmap) removeu do código uma credencial escrita por extenso, e essa credencial estava morta (o serviço externo a recusa), então não havia o que trocar. A credencial viva, a que a operação de fato usa, é outra e continua válida. Se ela um dia foi parar no histórico de versões do código ou em registros de execução, trocá-la deixa de ser opcional, porque histórico e registro não se apagam e quem os leu fica com a chave. Isso não foi medido, e afirmar qualquer coisa sem medir seria inventar. A pergunta não trava nenhum card: ela decide se nasce uma tarefa de rotação da credencial viva. Enquanto não for medida e respondida, o estado é desconhecido, e o desconhecido aqui é registrado, não presumido resolvido.