---
title: A ficha e a conversa de demonstração
description: Os campos obrigatórios da ficha editorial e da conversa de demonstração de uma solução, e por que o sistema recusa a publicação sem eles.
---

# A ficha e a conversa de demonstração

Toda solução do catálogo mostra, na sua página, uma **ficha** (o que ela faz, o que não faz, e como
funciona por dentro) e uma **conversa de demonstração** (um exemplo real de atendimento). As duas
fazem parte da versão publicada — não é possível publicar sem elas, e as regras abaixo são o que o
sistema verifica antes de deixar publicar.

## Por que o limite é obrigatório

A parte mais importante da ficha não é o que a solução faz — é o que ela **não** faz. Num produto
jurídico, prometer mais do que a solução entrega queima a confiança do cliente na primeira semana de
uso. Por isso o **limite** e a lista de "**o que não faz**" têm o mesmo peso que
"o que faz" na ficha: o sistema recusa a publicação se qualquer um dos dois ficar vazio.

A ideia é vender a capacidade e a limitação juntas, na mesma tela, para que quem instala a solução
saiba exatamente onde ela para.

## Campos da ficha

| Campo | O que é |
|---|---|
| **Capacidades** | Lista fechada de até 7 capacidades que a solução usa (responde sozinho, organiza o caso, lembra você, cobra o cliente, consulta seus sistemas, passa pra você, direciona para a área) |
| **Limite** | Uma frase curta e obrigatória: o principal limite da solução, exibido em destaque |
| **O que faz** | Lista de frases descrevendo as capacidades em linguagem de produto |
| **O que não faz** | Lista de frases descrevendo restrições — é a mesma lista que ancora as recusas da conversa (ver abaixo) |
| **Ficha técnica** | Onde funciona (ex.: WhatsApp), o que é necessário para instalar, quanto tempo leva, número de etapas do funil, número de lembretes, número de campos novos criados |
| **Nomes das etapas** | Os nomes das etapas do funil que a solução cria (pode ficar vazio se a solução não usa funil) |
| **Lembretes** | Quando cada lembrete dispara, a mensagem e em qual etapa (pode ficar vazio) |
| **Linhas técnicas** | Tabela "o que você vê" × "o que é criado por trás", para quem quer entender o que a instalação vai gerar |
| **Termos de busca** | Sinônimos que ajudam a solução a aparecer numa busca por sintoma no catálogo |
| **Selo** | Texto opcional de destaque, como "Mais instalada" |

Capacidades, limite, o que faz e o que não faz **não podem ficar vazios**. Os demais campos de lista
são obrigatórios no sentido de que precisam existir (mesmo que como lista vazia) — só não podem ser
omitidos.

## A conversa de demonstração

A conversa de demonstração é uma simulação de atendimento real, com falas do cliente e da assistente,
que aparece na página da solução para quem está decidindo se instala. Ela tem: nome e iniciais de um
contato fictício, uma sequência de falas (`beats`), um resultado (o que ficou pronto ao final) e,
opcionalmente, uma trilha de "por trás dos panos" mostrando o que o sistema fez em cada momento.

Toda conversa precisa ter **pelo menos uma fala da assistente marcada como recusa** — o momento em
que ela diz que aquela análise específica é do advogado responsável, não dela. É esse beat que prova,
na prática, o limite declarado na ficha.

## De onde vem cada fala

Toda fala da assistente na conversa declara explicitamente sua procedência, porque as duas coisas têm
uma diferença de confiabilidade que precisa ficar visível para quem lê:

- **Escrita no fluxo**: o texto é exatamente o mesmo que está escrito num nó do fluxo de
  atendimento real. O sistema confere isso **literalmente** — se o texto da fala não bater, palavra
  por palavra (ignorando espaços em excesso), com nenhum texto de nó do fluxo, a publicação é
  recusada. É uma fala que sempre vai aparecer exatamente assim para o cliente.
- **Gerada pela assistente**: o texto é um exemplo do que a assistente **poderia** dizer,
  mas ela escreve a resposta de verdade na hora, de acordo com o caso. Toda fala desse tipo aparece na
  interface com o aviso: *"As falas da assistente são exemplos: ela escreve na hora, conforme o
  caso."* Isso evita que alguém leia a demonstração como um roteiro fixo.

## Por que a recusa precisa citar um limite

Quando o beat de recusa é do tipo "gerada pela assistente", ele não pode ser um texto qualquer que o
curador imaginou — ele precisa **citar exatamente** um dos itens já declarados em "o que não faz" da
ficha. No editor, esse campo é uma lista de seleção, não uma caixa de
texto livre: você escolhe entre os limites que já escreveu, nunca digita um novo ali.

Isso existe para que a recusa mostrada na demonstração seja sempre uma consequência do limite
declarado, e não uma invenção paralela de quem está montando a conversa.

## O teto de 22 segundos

A soma de todas as pausas e tempos de digitação simulados da conversa não pode passar de
**22 segundos**. A demonstração é para dar uma ideia rápida de como a solução conversa — não é uma
simulação de atendimento completo. Se a conversa passar do teto, a publicação é recusada informando a
duração calculada e o limite.

## Saiba mais

- [Publicar uma solução](/guia/marketplace/publicar-uma-solucao) — o passo a passo completo e o que
  fazer quando a publicação é recusada
- [O que é uma solução](/guia/marketplace/o-que-e) — de onde vem o conteúdo que aparece no catálogo