Solicitar diagnóstico

Gestão de redes sociais · tecnologia

Gestão de redes sociais para empresa de tecnologia: o post que promete que o sistema nunca falha vira publicidade enganosa antes de virar prova social.

"Nunca trava." "100% seguro." "Zero bugs." "Compatível com tudo." Frases assim cabem numa legenda de duas linhas, mas cada uma afirma uma característica do produto para quem lê o feed antes de decidir testar ou contratar. O art. 37, § 1°, da Lei nº 8.078/1990 (Código de Defesa do Consumidor) diz que é enganosa "qualquer modalidade de informação ou comunicação de caráter publicitário, inteira ou parcialmente falsa, ou, por qualquer outro modo, mesmo por omissão, capaz de induzir em erro o consumidor a respeito da natureza, características, qualidade, quantidade, propriedades, origem, preço e quaisquer outros dados sobre produtos e serviços". Um post sobre o produto entra nessa descrição do mesmo jeito que um comercial de TV — o texto de 1990 não distingue o canal.

Para empresa de tecnologia que vende software, plataforma ou aplicativo — SaaS, software house, startup — e mantém perfil próprio em redes sociais, com equipe interna ou agência, publicando funcionalidade, comparação com concorrente, prova de performance e resposta a dúvida técnica. Contrato de licença de uso e prazo de validade técnica da versão ficam com a página de sites e landing pages do mesmo nicho; decisão automatizada de pontuação de lead e dado de cliente citado em estudo de caso ficam com as páginas de estratégia e de inteligência de marketing. Aqui o recorte é só o que a peça publicada afirma, ou deixa de afirmar, sobre o produto.

Conversar sobre as redes sociais da minha empresaFazer o diagnóstico de redes sociais

A obrigação não é do canal, é da afirmação: toda peça que descreve o produto entra no mesmo regime da publicidade

"Toda informação ou publicidade, suficientemente precisa, veiculada por qualquer forma ou meio de comunicação com relação a produtos e serviços oferecidos ou apresentados, obriga o fornecedor que a fizer veicular ou dela se utilizar": é o que diz o art. 30 do Código de Defesa do Consumidor, e um post, um story ou um anúncio patrocinado é "meio de comunicação" do mesmo jeito que um outdoor. O art. 31, caput, soma o que essa comunicação precisa garantir: "informações corretas, claras, precisas, ostensivas e em língua portuguesa sobre suas características, qualidades, quantidade, composição... entre outros dados". O art. 37, caput, fecha o cerco: "É proibida toda publicidade enganosa ou abusiva." O § 1° descreve a enganosa, inclusive por afirmação parcialmente falsa sobre "características, qualidade... e quaisquer outros dados sobre produtos e serviços" — uma afirmação absoluta ("nunca", "sempre", "100%", "zero") é falseável por definição, porque basta um caso em que o produto falha para que ela deixe de ser inteiramente verdadeira. O § 3° estende a mesma proibição ao silêncio: "a publicidade é enganosa por omissão quando deixar de informar sobre dado essencial do produto ou serviço." Para quem sustenta a afirmação, o art. 36, parágrafo único, já pede que o fornecedor "mantenha, em seu poder, para informação dos legítimos interessados, os dados fáticos, técnicos e científicos que dão sustentação à mensagem" — e o art. 38 completa: "o ônus da prova da veracidade e correção da informação ou comunicação publicitária cabe a quem as patrocina." Nenhum desses artigos, escritos em 1990, fala de rede social, post ou story — fala de publicidade, oferta e apresentação, e uma peça de feed cabe nas três definições.

Quatro pontos em que a afirmação sobre o produto entra na pauta antes de entrar na arte

Valem para o perfil de quem vende software, plataforma ou aplicativo. Contrato de licença e prazo de validade técnica são outro parágrafo, tratado na página irmã de sites e landing pages.

Quando a legenda ou a arte usa afirmação categórica sobre o produto — "nunca trava", "100% seguro", "zero bugs", "funciona em qualquer situação" — sem ressalva de escopo ou de condição de uso

Afirmação absoluta sobre o funcionamento do produto pode ser, ela mesma, a publicidade enganosa que o art. 37 proíbe

O art. 37, caput, diz que "é proibida toda publicidade enganosa ou abusiva", e o § 1° descreve a enganosa como "qualquer modalidade de informação ou comunicação de caráter publicitário, inteira ou parcialmente falsa... capaz de induzir em erro o consumidor a respeito da natureza, características, qualidade... e quaisquer outros dados sobre produtos e serviços". Uma afirmação absoluta é falseável por definição: basta um caso em que o sistema trava, falha ou é comprometido para que ela deixe de ser inteiramente verdadeira.

A pauta ganha um filtro antes da aprovação: todo superlativo categórico sobre o funcionamento do produto precisa ser substituído por uma descrição que reflita o que o time técnico confirma, com a condição em que ela vale, ou ficar de fora da peça. A decisão é tomada onde ainda é barata — na pauta —, não depois de a arte estar pronta.

Quando o post de "compatível com tudo" ou "funciona em qualquer sistema" é publicado ao mesmo tempo em que o time de suporte já registrou uma exceção conhecida — uma versão sem suporte, um plano que não inclui o recurso, uma integração que ainda não existe

Silêncio sobre uma limitação que a empresa já conhece também é publicidade enganosa

O art. 37, § 3°, diz que "a publicidade é enganosa por omissão quando deixar de informar sobre dado essencial do produto ou serviço." A omissão não precisa ser deliberada para alcançar o texto: basta que o dado essencial já exista, registrado internamente, e não apareça na peça que promete abrangência.

Antes de aprovar uma peça de abrangência ou de compatibilidade, a pauta passa por uma checagem com quem já registrou a exceção — suporte, produto, engenharia —, porque é esse time, não quem escreve a legenda, que sabe onde a promessa para.

Quando a peça usa um número, um gráfico ou uma comparação como prova — print de um teste interno, tempo de resposta comparado a outro produto, contagem de algo que o produto faz melhor

Print de performance, comparação com concorrente e número de velocidade pedem lastro guardado antes da publicação, não depois de questionados

O art. 36, parágrafo único, diz que o fornecedor, na publicidade de seus produtos ou serviços, "manterá, em seu poder, para informação dos legítimos interessados, os dados fáticos, técnicos e científicos que dão sustentação à mensagem." O art. 38 completa: "o ônus da prova da veracidade e correção da informação ou comunicação publicitária cabe a quem as patrocina." Quem afirma o número é quem precisa prová-lo — não quem duvida dele.

Antes de a arte ir ao ar, o teste, a métrica ou a comparação que sustenta o número precisa estar documentado e arquivado — com data, metodologia e critério —, porque é esse arquivo, e não a lembrança de quem fez o teste, que responde se a peça for questionada depois.

Quando o carrossel de "o que o produto faz" ou o vídeo de demonstração mistura funcionalidade já em uso com item do roadmap, ainda em teste interno ou disponível só num plano específico

Carrossel de funcionalidades e vídeo demonstrativo são "apresentação" do produto — o que está em desenvolvimento não pode aparecer como já disponível

O art. 31, caput, diz que "a oferta e apresentação de produtos ou serviços devem assegurar informações corretas, claras, precisas... sobre suas características, qualidades, quantidade, composição... entre outros dados". Um carrossel de funcionalidades é apresentação do produto do mesmo jeito que um catálogo, e "características" e "qualidades" descrevem o que o produto faz hoje, não o que ele vai fazer.

Cada funcionalidade que entra numa peça de apresentação carrega, na pauta, um status: disponível para todos os planos, disponível só para parte deles, ou em desenvolvimento — e só a primeira entra sem ressalva na arte e na legenda.

O que a leitura do perfil separa antes da próxima pauta de produto

Alcance e engajamento não dizem quais peças fazem afirmação absoluta sobre o produto, quais omitem exceção conhecida e quais usam número sem lastro guardado. Essa leitura cruza o que está publicado com o que o time técnico confirma.

A primeira passada é pelo acervo recente: quantas peças usam palavra absoluta sobre o funcionamento do produto — "nunca", "sempre", "100%", "zero", "qualquer" —, separadas das peças que descrevem o produto sem esse tipo de afirmação.

A segunda passada é pelos números e comparações: toda peça com métrica, print de teste ou comparação com concorrente entra numa lista própria, com uma coluna para se o lastro documentado existe e está localizável.

  • Peças do acervo com afirmação absoluta sobre o produto, separadas por formato e por período.
  • Peças com número, comparação ou print de performance, cruzadas com a existência de documentação de suporte.
  • Lista de exceções e limitações já registradas por suporte, produto ou engenharia, para checagem contra peças de abrangência.
  • Funcionalidades citadas em carrossel ou vídeo, cruzadas com o status real de cada uma — disponível para todos, disponível parcial ou em desenvolvimento.

Quando a afirmação sobre o produto não é a primeira conversa do perfil

Nestas situações a checagem pode esperar, ou a dúvida pertence a outra frente da empresa.
  • O perfil publica conteúdo institucional, vaga aberta e bastidor de equipe, sem afirmação sobre o que o produto faz ou deixa de fazer.
  • A dúvida é sobre o contrato de licença de uso, o prazo de validade técnica da versão ou o rodapé do site — outro serviço, tema da página de sites e landing pages do mesmo nicho.
  • A dúvida é sobre decisão automatizada de pontuação de lead ou dado de cliente citado em estudo de caso — LGPD, tema das páginas de estratégia e de inteligência de marketing do mesmo nicho.
  • A peça é resposta a comentário ou mensagem de suporte a um cliente identificado — atendimento pontual, não publicidade dirigida ao público.
  • Ninguém dentro da empresa levantou ainda a lista de exceções e limitações conhecidas — esse levantamento interno vem antes de qualquer campo novo no checklist de aprovação.

Mesmo com a pauta nova resolvida, vale revisar os destaques fixados e o material de campanha antiga: uma afirmação absoluta publicada há um ano continua no ar, e continua sendo a primeira peça que alguém lê antes de decidir testar o produto.

Do levantamento de exceções ao checklist de aprovação: a ordem em que o projeto resolve a afirmação sobre o produto

O trabalho começa por uma conversa com quem já sabe onde o produto falha, não pela próxima arte. Sem essa lista em mãos, o campo novo do checklist não tem contra o que checar.

Na primeira rodada, a empresa levanta junto ao suporte, ao produto e à engenharia a lista de exceções, limitações e incompatibilidades já conhecidas — a base da checagem de omissão do art. 37, § 3°.

Depois vem o checklist de aprovação: toda peça com afirmação absoluta sobre o funcionamento, toda peça de abrangência ou compatibilidade e toda peça com número ou comparação passam por um campo próprio antes de ir ao ar, com o lastro documentado anexado quando existir.

Por último, o acervo: peças antigas com afirmação absoluta ou número sem lastro documentado entram numa lista com decisão da própria empresa — manter com o lastro anexado, reeditar a legenda ou retirar do ar.

  • Levantamento de exceções, limitações e incompatibilidades conhecidas, junto a suporte, produto e engenharia.
  • Campo no checklist de aprovação para afirmação absoluta, peça de abrangência e peça com número ou comparação.
  • Modelo de arquivo para o lastro técnico — teste, metodologia, data — por trás de cada número usado em peça.
  • Status de cada funcionalidade citada em carrossel ou vídeo, revisado antes da publicação.
  • Revisão do acervo e dos destaques fixados, com decisão da empresa sobre cada peça antiga identificada.

O que empresa de tecnologia e quem toca o perfil perguntam sobre afirmação de produto em rede social

Um post no Instagram é mesmo tratado como publicidade pela lei do consumidor?

O art. 30 do Código de Defesa do Consumidor diz que "toda informação ou publicidade, suficientemente precisa, veiculada por qualquer forma ou meio de comunicação com relação a produtos e serviços oferecidos ou apresentados, obriga o fornecedor que a fizer veicular ou dela se utilizar". O texto não lista canal — fala de "qualquer forma ou meio de comunicação" —, e um post que descreve o produto está dentro dessa descrição.

Isso quer dizer que não posso destacar os pontos fortes do produto?

Não. O que o art. 37 proíbe é a publicidade enganosa ou abusiva — informação falsa, parcialmente falsa ou capaz de induzir a erro sobre característica, qualidade ou outro dado do produto. Descrever um ponto forte real, com a condição em que ele vale, não é o que o artigo alcança; a afirmação absoluta e sem ressalva, quando existe exceção já conhecida pela empresa, é.

Se alguém questionar um número usado numa peça, quem precisa provar que ele é verdadeiro?

A empresa que publicou. O art. 38 diz que "o ônus da prova da veracidade e correção da informação ou comunicação publicitária cabe a quem as patrocina" — e o art. 36, parágrafo único, já pede que o fornecedor mantenha em seu poder "os dados fáticos, técnicos e científicos que dão sustentação à mensagem". É o que torna a documentação arquivada antes da publicação mais segura do que reconstruir o teste depois.

"Compatível com tudo" é uma frase arriscada mesmo se for verdade na maioria dos casos?

Depende de a empresa já conhecer alguma exceção. O art. 37, § 3°, diz que "a publicidade é enganosa por omissão quando deixar de informar sobre dado essencial do produto ou serviço." Se o time de suporte já sabe de uma versão, um plano ou uma integração que a frase não cobre, o silêncio sobre isso é o que o parágrafo trata como omissão.

Podemos anunciar uma funcionalidade que está quase pronta, ainda no roadmap?

O art. 31, caput, pede que a apresentação do produto assegure "informações corretas, claras, precisas... sobre suas características, qualidades... entre outros dados". Uma funcionalidade em desenvolvimento ainda não é uma característica do produto — a peça pode falar dela, desde que diga que está em desenvolvimento, em vez de apresentá-la como já disponível.

Isso vale só para quem vende por assinatura, ou para qualquer empresa de tecnologia?

O art. 30 fala de "produtos e serviços oferecidos ou apresentados", sem distinguir modelo de venda. Software licenciado, assinatura mensal, plataforma ou aplicativo — qualquer peça que descreve o que o produto faz, independente de como ele é vendido, entra na mesma leitura.

Para continuar

Antes da próxima pauta de produto, vale levantar o que já se sabe sobre onde ele falha.

A conversa parte do acervo publicado — afirmação absoluta, peça de abrangência, número sem lastro — e da lista de exceções que suporte, produto e engenharia já conhecem.

Conversar sobre as redes sociais da minha empresaFazer o diagnóstico de redes sociais

Nenhuma proposta é enviada antes da conversa.