Cada conta vem com quatro objetos padrão. Eles não podem ser excluídos porque o restante do produto é construído em torno deles. Você pode adicionar campos, alterar visualizações e criar tipos de registro sobre eles. Quase nunca você deve substituí-los por uma versão caseira da mesma ideia.

People são as pessoas com quem você conversa. Uma pessoa tem nome, e-mail, telefone, função e um link para uma empresa. Frontline trata o e-mail como identidade principal, para que a mesma pessoa não seja criada duas vezes só porque apareceu em outro canal. People também capta atividade automaticamente. Quando o e-mail ou WhatsApp está conectado, as conversas são anexadas à pessoa. As reuniões podem fazer o mesmo. Com o tempo, o registro contém mais do que detalhes de contato. Ele contém uma linha do tempo, um breve resumo da IA ​​e os fatos que Max aprendeu, como uma preferência ou um risco.

Companies são as organizações às quais essas pessoas pertencem. Uma empresa tem um nome, um site, detalhes firmográficos e um logotipo que Frontline pode buscar para você. O relacionamento importante é aquele com People. Se você criar Sofia Alvarez com o email sofia@mercadolibre.com, Frontline poderá encontrar o Mercado Libre por esse domínio, ou criar a empresa e vinculá-la a ele. Você não precisa construir esse link Playbookmente no caso comum. A linha do tempo da empresa também herda a comunicação das pessoas vinculadas a ela, para que você possa ver a história da conta em um só lugar.

Deals são as oportunidades que você está tentando conquistar. Cada negócio tem um nome, um estágio, um valor e proprietários. O Deals tem como padrão um quadro kanban agrupado por estágio, e é por isso que eles parecem um pipeline na primeira vez que você os abre. Um negócio pertence a uma empresa e pode estar vinculado a várias pessoas. É assim que você mantém o comprador econômico, o campeão e o contato jurídico na mesma oportunidade, sem clonar o negócio.

Tickets são solicitações que precisam de status. Uma questão de faturamento, um bloqueador de implementação, um bug de produto que um cliente está aguardando. O padrão Tickets é um quadro agrupado por status, com estágios como Novo, Por sua conta, No cliente, Em espera e Fechado. Assim como as ofertas, um ticket pertence a uma empresa e pode estar vinculado a várias pessoas. É isso que permite que suporte e vendas olhem para a mesma conta sem manter duas versões da verdade.

Os objetos padrão já estão relacionados. Uma pessoa pertence a uma empresa. Um negócio pertence a uma empresa e pode incluir muitas pessoas. Um ticket funciona da mesma maneira. No registro da empresa, você pode ver as pessoas, os negócios abertos e os tickets abertos. De uma pessoa, você pode ver sua empresa e as ofertas ou ingressos dos quais ela faz parte.

Esse gráfico é o motivo pelo qual você não deve criar um segundo objeto “Contas” ou uma tabela “Contatos” personalizada. As conexões, a atividade e os perfis de IA já estão disponíveis no People e Companies. Um objeto paralelo divide a história. Max atualizará um lado e perderá o outro.

Aqui está um resumo completo de uma semana real. O visto é um Company. Kate Chen é uma Person lá. Há um Deal para uma nova expansão de assento, em andamento. Depois de uma demonstração, Kate fica quieta. Max pode ver que a última interação está envelhecendo e que as mensagens não foram respondidas e, em seguida, revela o risco na conta. Se Kate escrever mais tarde sobre um problema de provisionamento, isso se tornará um Ticket vinculado à mesma empresa e à mesma pessoa. Ninguém copia dados entre ferramentas. Os objetos já compartilham o registro.

Cada objeto, padrão ou personalizado, pode conter mais de uma linha de campos. Você pode salvar visualizações para que um pipeline, uma tabela ou uma lista filtrada esteja a um clique de distância. Você pode registrar notas, chamadas e reuniões. Você pode anexar arquivos e atribuir tarefas. Você pode relacionar um registro a registros de outros objetos. E você pode dividir o objeto em tipos de registro quando um objeto precisar atender a mais de um processo. A próxima lição aborda os tipos de registro. A questão por enquanto é que um objeto é uma entidade viva, não uma guia de planilha.

Os objetos padrão também funcionam em segundo plano e os objetos personalizados não serão copiados para você. People desduplicação por e-mail e telefone. Companies enriquece seu domínio. A última interação permanece atual. A força da conexão em uma empresa é calculada, não digitada. Se você estiver criando um campo chamado “Último e-mail” ou “Saúde da conta”, faça uma pausa. Frontline já pode estar guardando isso para você.

Crie um objeto personalizado quando aquilo que você está rastreando for uma parte de primeira classe do negócio e não for uma pessoa, uma empresa, um negócio ou um ticket. Uma equipe imobiliária pode adicionar propriedades. Uma equipe de logística pode adicionar Remessas. Uma empresa de serviços pode adicionar compromissos. Esses registros precisam de proprietários, campos, visualizações e um cronograma próprio. Eles também devem vincular-se novamente a People e Companies para que a imagem da conta permaneça completa.

Não crie um objeto personalizado para um status, uma tag ou um relatório. Esses são campos. Não crie um para e-mails ou conversas. Essas são atividades. Não crie um porque duas equipes desejam um layout diferente do mesmo contato. Esse é um tipo de registro ou visualização em People.

Se os dados forem uma lista de referência simples, sem ciclo de vida real, uma tabela geralmente é a melhor opção. Cobriremos as mesas mais tarde. Um bom teste é este: você atribuiria um proprietário, escreveria uma nota e voltaria ao registro no próximo mês? Se sim, é um objeto. Se você procurar apenas para preencher outro registro, provavelmente é uma tabela.

As equipes que aproveitam ao máximo a Frontline podem nomear seus objetos de uma só vez. People, Companies, Deals, Tickets e talvez um ou dois objetos personalizados exclusivos da empresa. Esse pequeno conjunto é o que o Max aprende, o que os novos contratados aprendem e como suas automações são executadas.

Se você não tiver certeza de onde pertence uma nova ideia, comece com um campo em um objeto existente. Promova-o a um objeto personalizado somente quando ele tiver dados próprios suficientes para merecer um lar. É muito mais fácil desenvolver um modelo limpo do que mesclar dois objetos posteriormente.

A seguir, veremos os tipos de registro: como um objeto pode suportar mais de um tipo de registro sem quebrar o modelo que você acabou de construir.