D-One — Um arquiteto Salesforce disponível 24h por dia

Isso acontece todo dia na sua empresa.

“O usuário abriu um ticket às 9h. São 16h. O admin ainda não respondeu porque estava em outra demanda. O cliente esperou o dia inteiro.”

“Um erro no fluxo de aprovação bloqueou 12 oportunidades. Ninguém sabe por quê. A consultoria só responde amanhã.”

“O novo funcionário da equipe vai fazer três meses. Ainda pergunta pro admin como funciona o processo de desconto.”

O problema não é falta de Salesforce. É falta de quem responda na hora certa.

O D-One não foi criado numa sala de reunião. Foi criado numa crise.

Um dos nossos clientes contratou um novo funcionário de suporte. A org era complexa, a curva de aprendizado era íngreme, e o backlog de tickets começou a crescer. Em semanas, eram dezenas de chamados sem resposta.

Nós colocamos o D-One em produção.

Em dias, o backlog havia sido zerado. Hoje, nenhum ticket fica sem resposta por mais de 24 horas — e o funcionário que “não conseguia lidar com a org” é um dos mais eficientes da equipe.

O D-One não substitui pessoas. Ele as transforma.

— Murad, CEO da Imaginedone

O que você ganha com o D-One no Slack

Respostas instantâneas sobre a org

Qualquer membro da equipe pergunta o que quiser sobre o Salesforce — o D-One responde, analisa e sugere o próximo passo.

“Por que o fluxo de aprovação falhou para o lead da Acme?”

Diagnóstico completo da org

Score de saúde de 0 a 100, com alertas de governor limits, jobs falhados, cobertura de testes e conflitos de automação.

“@d-one faz um health check completo da org”

Planejamento de demandas

Descreva o que precisa e o D-One analisa a estrutura da org, identifica dependências e entrega um plano técnico completo de implementação.

“@d-one preciso que o bot de WhatsApp reconheça o cliente pelo telefone automaticamente”

Execução de funcionalidades planejadas

Após planejar, o D-One implementa: cria flows, validation rules, campos e faz deploy — tudo com sua aprovação antes de cada ação.

“Aprovado, pode implementar a Etapa 2 do plano”

Operações no Salesforce, com segurança

Cria campos, roda testes, faz deploys em sandbox — tudo pelo Slack, com confirmação obrigatória antes de qualquer ação.

“Cria um campo picklist 'Prioridade' no objeto Case”

Testes com geração de evidências

Planeja e executa testes na org, documenta os resultados com evidências detalhadas para validação e compliance.

“@d-one roda os testes do objeto Case e gera as evidências”

Isso não é simulação. São casos reais.

Veja como o D-One resolve problemas reais de clientes — direto no Slack, sem sair do fluxo de trabalho.

Diagnóstico de Erro

LM

Lucas M. 13:29

@D-One erro estrangeiro, podem ver por favor.

Erro na integração: Erro ao atualizar cadastro conta. Tente novamente. Object reference not set to an instance of an object.
13/03/2026 13:28

D

D-One 13:29

PROBLEMA

A conta Ricardo Ferreira está falhando ao sincronizar com o ERP externo, com o erro:
“Object reference not set to an instance of an object.”

CAUSA RAIZ

O erro é uma NullReferenceException do lado da API do ERP (backend .NET). O Salesforce está enviando os dados corretamente, mas a API do ERP está quebrando ao processar o payload.

A causa é o campo BillingCountry (país) estar vazio na conta. Comparei os 4 clientes estrangeiros da org:

Conta	BillingCountry	Resultado
Ricardo Ferreira	null	NullReferenceException
Cliente B	PORTUGAL	Erro de banco (outro problema)
Cliente C	BRASIL	Sucesso
Cliente D	PORTUGAL	Sucesso

O padrão fica claro: clientes estrangeiros sem BillingCountry causam crash na API do ERP.

CADEIA DE EVENTOS

1. Usuário edita a conta no Salesforce
2. AccountErpSyncTrigger dispara no after update
3. AccountErpSyncService monta o payload com pais = null
4. POST para a API do ERP
5. API tenta processar o campo pais nulo → NullReferenceException
6. Salesforce grava o erro no StatusIntegracao__c

SOLUÇÃO IMEDIATA

Preencher o campo BillingCountry na conta:
1. Abrir a conta no Salesforce
2. Editar o endereço e preencher o campo País com INGLATERRA
3. Salvar — o trigger irá disparar novamente e desta vez deve integrar com sucesso

SOLUÇÃO DEFINITIVA

Alterar a classe AccountErpSyncService para tratar campos nulos antes de enviar ao ERP:

// ANTES:
req.pais = acct.BillingCountry != null
    ? acct.BillingCountry.toUpperCase() : null;

// DEPOIS:
if (acct.BillingCountry != null) {
    req.pais = acct.BillingCountry.toUpperCase();
} else if (isEstrangeiro && acct.PaisPassaporte__c != null) {
    req.pais = acct.PaisPassaporte__c.toUpperCase();
}

Identifiquei ainda outros 7 erros de integração nos últimos 5 dias (banco de dados, CPF duplicado, nome longo demais). Quer que eu investigue algum deles?

Criação de Regra

RT

Rafael T. 10:14

@D-One Crie uma regra de validação no objeto Lead para não deixar converter em Conta enquanto o campo Carteira__c estiver vazio.

D

D-One 10:16

Preciso verificar se o campo Carteira__c existe no objeto Lead na org. Vou consultar a org.

Confirmei as informações necessárias:

Carteira__c existe no Lead (tipo Picklist)
Já existem 5 validation rules no Lead na org
O Lead não está nos metadados locais — vou criar a estrutura

SOLUÇÃO PROPOSTA

Validation Rule: LEAD_CarteiraObrigatoriaConversao

Atributo	Valor
Objeto	Lead
Ativa	Sim
Descrição	Impede a conversão do Lead enquanto o campo Carteira estiver vazio

Fórmula:

AND(
    IsConverted,
    ISPICKVAL(Carteira__c, '')
)

Mensagem de erro:
O campo “Carteira” deve ser preenchido antes de converter o Lead em Conta.

Posso criar o arquivo e fazer o deploy para a org?

DEPLOY REALIZADO COM SUCESSO

Validation Rule criada e deployada com sucesso!
LEAD_CarteiraObrigatoriaConversao está ativa na org desde hoje.

RESUMO

Item	Detalhe
Objeto	Lead
API Name	LEAD_CarteiraObrigatoriaConversao
Status	Ativa
Fórmula	`AND(IsConverted, ISPICKVAL(Carteira__c, ''))`

VALIDATION RULES ATIVAS NO LEAD (6 total)

Regra	Propósito
LEAD_CarteiraObrigatoriaConversao	Bloqueia conversão sem Carteira
LEAD_ValidaCNPJ	Valida formato CNPJ
LEAD_ValidaPrimeiroNome	Valida primeiro nome
Validacao_Endereco_Obrigatorio	Endereço obrigatório
Validacao_Formato_Celular_BR	Formato celular BR
Validacao_Formato_Telefone_BR	Formato telefone BR

A regra já está ativa. Ao tentar converter um Lead com Carteira__c vazio, a conversão será bloqueada com a mensagem de erro.

Planejamento de Feature

AC

Ana C. 13:40

@D-One hoje temos um bot funcionando na org que se chama Bot_Atendimento. Ele faz perguntas iniciais para identificar o cliente, mas muitas pessoas desistem antes de terminar. Precisamos que o bot reconheça automaticamente o cliente pelo número de telefone no WhatsApp e faça a vinculação com o Contato e/ou Caso no Salesforce. O que você sugere?

D

D-One 13:44

Modo: Planejamento de Demandas

Reconhecimento Automático de Cliente pelo Telefone WhatsApp

Excelente demanda! Investiguei a fundo o estado atual do bot, os dados da org e a infraestrutura de Messaging. Abaixo está o diagnóstico completo e o plano técnico para implementação.

1. DIAGNÓSTICO DO ESTADO ATUAL

Como funciona hoje (problema):
O bot Bot_Atendimento segue este fluxo de identificação:

Cliente envia "Oi" no WhatsApp ↓ Bot pergunta: Tipo de atendimento? (Consumidor / Empresas) ↓ Bot pergunta: CPF? ↓ Bot pergunta: Nome? ↓ Bot pergunta: Email? ↓ Bot pergunta: CEP? ↓ Bot pergunta: Endereço completo? ↓ Flow "Bot_Upsert_Contato_Consumidor" busca Contact por CPF__c ↓ Só agora o cliente é identificado e o atendimento começa

São 5-6 perguntas antes de qualquer atendimento — é compreensível que muitos desistam.

Evidências coletadas na org:

Métrica	Valor	Observação
MessagingEndUser (WhatsApp)	21.470	Total de usuários que já entraram em contato
Com ContactId vinculado	1.430 (6,7%)	93% NÃO tem contato vinculado
MessagingSessions com Contact	2.284	Uma fração do total
Contatos com telefone	~30.336	Base de contatos existente

FORMATO DOS DADOS (compatível!)

Fonte	Exemplo	Formato
MessagingEndUser.MessagingPlatformKey	`5511987654321`	Numérico puro, sem formatação
Contact.Phone	`55 11 987654321`	Com espaços (apenas)

Validei na org: O telefone 5511987654321 do MessagingEndUser bate exatamente com 55 11 987654321 do Contact. Basta remover os espaços para fazer o match.

⚠ Ponto de atenção: telefones duplicados
Encontrei contatos diferentes com o mesmo telefone (ex: 55 11 976543210 aparece para “Maria Lima” e “Pedro Santos” — CPFs distintos). Isso precisa ser tratado na lógica.

2. SOLUÇÃO PROPOSTA

Abordagem: Flow Autolaunched no início do bot + alteração do diálogo
A ideia é interceptar a conversa no início, antes das perguntas, e tentar reconhecer o cliente automaticamente:

[NOVO] Flow captura MessagingPlatformKey (telefone do WhatsApp) ↓ [NOVO] Normaliza o número (remove espaços/formatação) ↓ [NOVO] Busca Contact por Phone normalizado ↓ ┌────────────────────────────────────────────┐ │ MATCH ÚNICO encontrado? │ │ │ │ SIM → "Olá, [Nome]! Identificamos você │ │ pelo seu número." │ │ → Confirmou? Pula p/ atendimento │ │ → Não confirmou? Segue fluxo CPF │ │ │ │ MÚLTIPLOS → "Encontramos mais de um │ │ cadastro. Pode informar seu CPF?" │ │ → Segue fluxo CPF (mas SÓ o CPF) │ │ │ │ NENHUM → "Não encontramos seu cadastro. │ │ Vamos fazer um cadastro rápido?" │ │ → Segue fluxo atual completo │ └────────────────────────────────────────────┘ ↓ [NOVO] Vincula Contact ao MessagingEndUser.ContactId [NOVO] Vincula Contact ao MessagingSession.EndUserContactId ↓ Atendimento começa (com dados do cliente já disponíveis)

Justificativa da abordagem:

Flow (não Apex): Segue a preferência do projeto para automações declarativas
Não substitui o CPF: O CPF continua como fallback — é mais confiável que telefone
Backwards-compatible: Clientes novos continuam passando pelo fluxo completo
Vinculação bidirecional: Popula tanto MessagingEndUser.ContactId quanto MessagingSession.EndUserContactId, que hoje estão vazios em 93% dos casos

3. COMPONENTES A CRIAR/MODIFICAR

Componente	Tipo	Ação
`Bot_Identifica_Por_Telefone`	AutoLaunchedFlow	Criar (novo)
`Bot_Atendimento`	Config. Einstein Bot	Modificar diálogo inicial
`Bot_Upsert_Contato_Consumidor`	Flow	Adicionar input opcional
`Bot_Normaliza_Telefone_Contato`	Before-Save Flow	Criar (opcional)

3.1 Novo Flow: `Bot_Identifica_Por_Telefone`

Atributo	Valor
Tipo	AutoLaunchedFlow (invocado pelo Bot)
Complexidade	Média
Objeto principal	Contact, MessagingEndUser

Lógica detalhada:

INPUT:
  - var_MessagingEndUserId (do bot context)
  - var_ConversationId (MessagingSession Id)

STEP 1: Get MessagingEndUser
  → SOQL: MessagingEndUser WHERE Id = var_MessagingEndUserId
  → Captura: MessagingPlatformKey (ex: "5511987654321")

STEP 2: Normalizar telefone
  → Formula: SUBSTITUTE(SUBSTITUTE(MessagingPlatformKey, " ", ""), "+", "")
  → Gerar variação com espaços: "55 11 987654321"
  → Gerar variação sem DDI: "11987654321"

STEP 3: Buscar Contact por telefone
  → SOQL: Contact WHERE Phone = var_PhoneFormatado
  → Armazenar: Collection de Contacts encontrados

STEP 4: Decision — Quantos encontrou?
  → 0 resultados: var_Status = "NaoEncontrado"
  → 1 resultado: var_Status = "Encontrado"
      → var_ContatoId = Contact.Id
      → var_NomeDoContato = Contact.Name
      → var_CPFContato = Contact.CPF__c
  → 2+ resultados: var_Status = "Multiplos"

STEP 5: Se encontrado (único), atualizar vínculos:
  → UPDATE MessagingEndUser SET ContactId = var_ContatoId
  → UPDATE MessagingSession SET EndUserContactId = var_ContatoId

OUTPUT:
  - var_Status ("Encontrado" / "NaoEncontrado" / "Multiplos")
  - var_ContatoId
  - var_NomeDoContato
  - var_ContaId (Account do contato)

3.2 Modificação: Diálogo do Bot `Bot_Atendimento`

Atributo	Valor
Tipo	Configuração do Einstein Bot
Complexidade	Média

Mudanças no diálogo:
1. Novo Dialog inicial: “Identificação Automática”
  • Antes de qualquer pergunta, invoca o flow Bot_Identifica_Por_Telefone
  • Avalia var_Status retornado

2. Se “Encontrado”:
  • Bot diz: “Olá, [Nome]! Identificamos você pelo seu número. Como posso ajudar?”
  • Pula direto para o menu de opções (tipo de atendimento)
  • Passa var_ContatoId para os flows subsequentes

3. Se “Multiplos”:
  • Bot diz: “Encontramos mais de um cadastro neste número. Pode me informar seu CPF?”
  • Coleta apenas o CPF (1 pergunta em vez de 5-6)
  • Usa o flow Bot_ContatoExistente

4. Se “NaoEncontrado”:
  • Bot diz: “Ainda não temos seu cadastro. Vou precisar de algumas informações...”
  • Segue o fluxo atual completo

3.3 Modificação: Flows existentes de Upsert

Flow	Mudança
`Bot_Upsert_Contato_Consumidor`	Adicionar input var_ContatoId opcional — se já identificado, apenas atualizar (não criar)
`Bot_ContatoExistente`	Sem mudança — já funciona por CPF como fallback

4. ANÁLISE DE IMPACTO

Objeto	Risco	Observação
Contact	Baixo	Consulta por Phone (apenas leitura)
MessagingEndUser	Baixo	Update de ContactId — campo hoje vazio em 93% dos registros
MessagingSession	Baixo	Update de EndUserContactId — campo hoje vazio na maioria
Bot Dialog	Médio	Novo dialog inicial, automação existente preservada

CENÁRIOS DE RISCO

Cenário	Probabilidade	Impacto	Mitigação
Cliente troca de número	Baixa	Baixo	Fallback para CPF; contato antigo não é sobrescrito
Alguém usa telefone de outra pessoa	Baixa	Médio	Confirmação pelo nome: “Você é [Nome]?” antes de prosseguir
Performance da busca (30k contatos)	Baixa	Baixo	Phone é campo indexável no Salesforce; query simples e rápida
Contato sem telefone cadastrado	Média	Baixo	Tratado como “NaoEncontrado” — fluxo atual

ORDEM DE IMPLEMENTAÇÃO

Etapa 1 (Pré-requisito): Analisar formato de Phone nos 30k contatos, definir fórmula de normalização
Etapa 2 (Core): Criar flow Bot_Identifica_Por_Telefone, testar em sandbox (match único, múltiplo, sem match)
Etapa 3 (Integração): Configurar novo Dialog inicial no Bot, modificar flow de Upsert, testar E2E
Etapa 4 (Enriquecimento - opcional): Batch para vincular os 21k registros existentes retroativamente
Etapa 5 (Deploy): Homolog → Stage → Produção

ESTIMATIVA DE ESFORÇO

Componente	Esforço
Flow de identificação por telefone	~6h
Alteração do diálogo do Bot (Einstein Bot Builder)	~4h
Modificação dos flows de Upsert	~2h
Testes em sandbox	~4h
Total estimado	~16h (2 dias configuração/QA)

EXPERIÊNCIA DO CLIENTE — ANTES vs DEPOIS

ANTES (hoje)

Cliente recorrente:
• 5-6 perguntas (CPF, nome, email...)
• ~3 min até iniciar atendimento
• Alta taxa de desistência

DEPOIS (proposta)

Cliente recorrente (match único):
• 0 perguntas — reconhecido pelo telefone
• ~5 seg até iniciar atendimento
• Atendimento imediato

⚠ Cautela LGPD: não recomendamos que o bot exiba o nome completo do cliente antes da confirmação (dado que o número de telefone pode ser compartilhado). O bot deve confirmar: “Posso confirmar que você é [Nome Completo]?” antes de prosseguir.

A solução usa Flow (não Apex), é backwards-compatible, e pode vincular 93% dos usuários WhatsApp que hoje não têm contato associado. Quer que eu comece pela Etapa 1?

Para todos na sua equipe. Não só para o admin.

A dor: Vira gargalo de todas as dúvidas da equipe. Cada pergunta sobre a org passa por você. Cada explicação consome tempo que deveria ir para projetos estratégicos.

Com o D-One: A equipe se serve — você foca no que importa. O D-One absorve as perguntas do dia a dia e responde com dados reais, liberando o admin para trabalho de alto valor.

A dor: Precisa de dados do Salesforce para atender clientes, mas não tem licença ou habilidade técnica para navegar a org sozinho.

Com o D-One: Consulta dados de clientes, histórico de casos e status de oportunidades direto no Slack, sem licença Salesforce. Pergunta no Slack, recebe dados em segundos.

A dor: Visibilidade de pipeline, status de projetos e métricas exige acesso ao Salesforce e habilidade técnica para filtrar relatórios.

Com o D-One: Pergunta no Slack, recebe dados estruturados em segundos. Pipeline, métricas de casos, performance de equipe — tudo no Slack, sem abrir o Salesforce.

A dor: Investigar erros exige navegar por múltiplas telas no Salesforce, cruzar logs, consultar metadata. Debug leva horas.

Com o D-One: Diagnóstico e execução em sandbox direto pelo Slack. O D-One cruza dados, investiga root cause e sugere fix — em minutos, não horas.

A dor: Discovery de orgs novas leva dias. Entender objetos, automações, regras de negócio e gerar relatório para o cliente consome projetos inteiros.

Com o D-One: Entende a org em horas, gera documentação profissional automaticamente. O D-One faz o discovery, você faz a estratégia.

“Mas e a segurança da minha org de produção?”

Produção blindada

Em orgs de produção, operações de metadata são completamente bloqueadas por infraestrutura. Não é regra de software — é impossibilidade física.

Confirmação antes de qualquer ação

Toda operação que altera dados exige aprovação explícita. O D-One mostra o que vai fazer e espera você dizer sim.

Auditoria completa

Log detalhado de tudo que foi perguntado e executado. Rastreabilidade total.

Funcionando em menos de 10 minutos.

1

Adicionamos o D-One ao seu canal no Slack

Sem instalação local. Sem deploy. Sem TI.

2

Conecte sua org Salesforce

Um único comando. O D-One faz o resto.

3

Pergunte qualquer coisa

Sua equipe já está no Slack. O Salesforce acabou de chegar lá também.

Quem usa, conta.

Depoimentos reais de quem colocou o D-One em produção.

Construído por quem vive de Salesforce.

O D-One é um produto da Imaginedone — a consultoria Salesforce com 14 anos de mercado, 300+ projetos entregues e 4,9/5 no AppExchange.

16

anos de mercado

300+

projetos entregues

4,9/5

AppExchange

94%

retenção de clientes

Não criamos o D-One para vender software. Criamos porque precisávamos dele. E como funciona para nós, achamos que pode funcionar para você também.

Quer ver o D-One na prática?

Preencha o formulário. Um consultor da Imaginedone entra em contato para entender sua org e mostrar como o D-One pode ajudar.

Nome completo *

E-mail corporativo *

Empresa *

Cargo *

Quantos usuários usam seu Salesforce? *

Sem compromisso. Sem vendedor insistente. Só uma conversa honesta sobre se faz sentido para você.

Um arquiteto Salesforce com profundo conhecimento sobre a sua org — disponível 24h por dia.