A decisão de implementar o agente de IA havia partido de uma visão estratégica da liderança, mas a viabilidade de escalar o produto dependia de uma aposta que ainda precisava ser provada, que era possível abstrair a configuração técnica da IA em um fluxo simples o suficiente para que usuários sem nenhum perfil técnico o completassem de forma autônoma.

Minha hipótese era que a barreira não estava na complexidade da tecnologia em si, mas na tradução entre a camada lógica de engenharia e a linguagem natural. Se mapeássemos e delimitássemos as variáveis de prompt certas e as transformássemos em escolhas aderentes aos perfis dos usuários, eles conseguiriam configurar a IA como se estivesse tomando decisões de negócio, não decisões técnicas.

• Colaboração direta com Engenharia e stakeholders para mapear quais parâmetros de prompt impactavam o comportamento, a personalidade e as regras de negócio da IA, identificando quais variáveis seriam configuráveis pelo usuário e quais seriam fixadas para preservar a qualidade do produto.
• Análise competitiva de ferramentas do setor direto e indireto.
• Workshops com profissionais envolvidos no fluxo manual de configuração para mapeamento de Espectros e Jobs-to-be-Done.
• Shadowing em reuniões do time de CS com clientes que já utilizavam o agente homologado, levantando percepções, dores e atritos do processo atual.
• Benchmarking de interfaces No-Code como referência de abstração de complexidades técnicas.

1. Jargões técnicos são bloqueadores de adoção.
   Todos deveriam ser completamente substituídos por linguagem natural.
2. Nem toda variável de prompt deve virar input de usuário.
   Parte central do trabalho foi decidir, junto à Engenharia, quais configurações seriam expostas ao gestor e quais seriam fixadas como regras de negócio. Essa curadoria foi mais importante que o design da interface em si.
3. O fluxo manual apontou alguns pontos que deveriam ser configuráveis.
   Ao observar o processo manual via shadowing e workshops, ficou claro quais quesitos tinham mais interesse de configuração pelos usuários. O discovery não foi só sobre UX, foi sobre engenharia reversa do processo existente.
4. A integração com o estoque era a principal incerteza do gestor.
   Nos workshops, a pergunta mais recorrente dos clientes era "mas ela já integra o estoque diretamente?", revelando que, o usuário precisava de uma prova de que a IA já conhecia o negócio dele.
5. O gestor não quer controle total, quer controle percebido.
   Ficou evidente que o gestor não precisava customizar tudo, mas precisava sentir que tinha escolha na personalização do produto.
6. O maior medo do gestor eram as alucinações da IA.
   Além da dúvida sobre o estoque, os workshops revelaram que o principal temor dos usuários era a IA "inventar" informações sobre veículos ou condições da revenda. Medo que era naturalmente contornado pelo contato humano do time de CS com os usuários.

A direção central do projeto foi tratar a configuração não como um formulário técnico, mas como uma camada de tradução entre engenharia e negócio. Em vez de expor parâmetros de prompt ou terminologia técnica, o fluxo foi estruturado inteiramente em torno de decisões de negócio.

O shadowing e os workshops revelaram que o processo manual funcionava não pela qualidade técnica da configuração, mas pela presença humana do CS mediando cada etapa. Remover essa mediação significava que o design precisaria construir confiança ativamente, não só facilitar o uso.

• Simplicidade vs. Flexibilidade.
  Cards pré-definidos reduzem a barreira de entrada, mas limitam gestores com necessidades específicas.
• Abstração vs. Transparência.
  Abstrair a lógica de prompt facilita o uso, mas cria uma caixa-preta para o usuário.
• Velocidade de setup vs Riqueza de configuração.
  A meta de < 5 minutos para completar o setup estabelecida, impôs um limite natural na quantidade de variáveis configuráveis. Algumas decisões de comportamento da IA ficaram fora do escopo.

O produto foi estruturado como um Wizard de configuração de 4 etapas, projetado para guiar o gestor do zero até uma IA ativa. A sequência das etapas não foi arbitrária, cada passo foi ordenado para construir confiança progressivamente antes de exigir qualquer decisão do usuário.

1. Conexão
   Sincronização automática do estoque e seleção dos canais de atendimento que a IA irá se envolver.
2. Personalidade
   Seleção de dados de personalidade da IA, nome, informações sobre a revenda e perfil de comunicação via cards visuais, cada um acompanhado de exemplos reais de frases. A complexidade dos prompts por trás de cada input permanece invisível ao usuário.
3. Regras e Transbordo
   Definição de horários de atendimento, regras de transbordo e escolha de vendedores que a IA irá passar o atendimento.
4. Checkout Review
   Resumo consolidado de todas as configurações cadastradas, dando uma visão geral macro de todos dados inseridos e possibilitando uma edição micro de cada input.

O modelo foi construído sobre quatro princípios:

1. Progressive Disclosure
   Cada etapa revela apenas o necessário para aquele momento.
2. Zero Jargão
   Nenhum termo técnico aparece em nenhuma tela.
3. Templates pré-definidos
   Para reduzir a fricção nos momentos de input e priorizar a conclusão do fluxo, cada etapa foi projetada com modelos prontos que o gestor pode usar ou adaptar.
4. Exemplos contextuais
   Para aumentar a confiança do gestor na capacidade da IA, quando possível foi exibido exemplos reais de como a IA se comportaria.

O checkout foi posicionado como o fechamento do fluxo. A tela onde o usuário revisa todas informações cadastradas e confirmar a publicação.

Boas-vindas → Sincronização de estoque + Escolha de canais → Escolha de nome + Preenchimento do sobre a revenda + Seleção de personalidade via cards → Definição de horários + Regras de transbordo + Rodízio de leads → Checkout com resumo → Confirmação e publicação.

• Cada etapa do Wizard só avança após a ação central ser concluída, sem possibilidade de pular etapas.
• O usuário pode voltar etapas anteriores sem perder configurações já salvas.
• O usuário pode editar informações na tela de checkout.

• Antes de expor o fluxo a usuários externos, o protótipo foi revisado com o time de CS, que tinha o maior repertório sobre as dúvidas e comportamentos reais dos gestores.
• 8 usuários da plataforma realizaram tarefas reais no protótipo.

Sinais monitorados: tempo de conclusão por etapa, % de conclusão do fluxo sem necessidade de suporte externo, confiança dos usuários perante ao comportamento da IA, hesitação nos botões de decisão, questionamento sobre mais campos a serem configurados e tentativas de editar ou questionar os campos.

1. Feedback de sincronização de estoque redesenhado
   A sincronização automática ocorria rápido demais e o feedback visual era fraco, usuários não percebiam que a integração havia acontecido. O tempo de sincronização foi aumentado e o feedback visual reforçado para tornar o momento mais perceptível e de maior valor.
2. Templates do campo "sobre a revenda" tornados mais visuais
   Os templates passaram algumas vezes despercebidos, a versão iterada aumentou a clareza sobre as opções.
3. Campo "sobre a revenda" redefinido como opcional
   4 de 8 usuários optaram por não preencher o campo mesmo com templates disponíveis. Como o campo não influenciava diretamente na qualidade que a IA entregava, mas sim com a personalização dela, a decisão foi torná-lo opcional, mantendo uma indicação ao final do fluxo sinalizando que o campo estava em aberto, preservando a autonomia do usuário.
4. Botão "Publicar" ganhou estado intermediário de confirmação
   Em casos de campos opcionais não preenchidos, o botão passou a exibir um estado secundário, trazendo mais visibilidade para mensagens explicando como o preenchimento completo poderia melhorar a personalidade da IA.
5. Playground adicionado na tela de Checkout
   Mesmo com exemplos contextuais, foi identificada hesitação dos usuários na confiança com a IA antes da publicação. Um Playground foi adicionado como resposta direta na tela de checkout, permitindo que o usuário interagisse com a IA e validasse as configurações antes de confirmar.
6. Mais exemplos dos cards de personalidade e adições no writing
   Usuários pediam mais referências antes de escolher um perfil, novos exemplos contextuais e novo writing foram adicionados para tornar as diferenças entre os cards mais evidentes e a escolha mais segura.

• Autonomia do gestor no setup: de 0% para 100% das etapas realizáveis sem suporte técnico.
• Taxa de conclusão do fluxo autônomo: 91%.
• 100% dos usuários interagiram com o Playground antes de publicar.
• Tempo de configuração por cliente de < 5 minutos autônomos.
• Necessidade de intervenção interna para ativação: de 100% para 0%.

• O fluxo removeu a dependência de time internos a cada nova configuração, devolvendo capacidade técnica para as entregas principais do produto e eliminando o tarefas em sprints fechadas.
• A plataforma passou a ter condições de ativar novos clientes no módulo de IA sem crescimento. proporcional de time interno, viabilizando a expansão comercial do produto.
• Redução de 2-4 horas de engenharia alocadas para ativações manuais.

• Após o reforço do feedback visual, usuários demonstraram reação positiva ao ver o estoque integrado, funcionando como o gatilho que aumentava o comprometimento com a conclusão do setup
• A principal aposta do projeto foi confirmada, a camada de tradução entre engenharia e negócio foi suficiente para viabilizar a configuração sem nenhuma intervenção de suporte.
• Adicionado a partir da identificação de hesitação nos testes, o playground confirmou seu papel como principal mecanismo de confiança, usuários interagiram ativamente com a IA antes de confirmar a publicação.
• A presença de modelos pré-definidos nos campos diminuiu o tempo de preenchimento e eliminou dúvidas sobre o que inserir

• A decisão mais crítica do projeto não foi visual, foi sentar com a Engenharia e decidir quais variáveis de prompt viriam configuráveis e quais seriam fixadas por regra. A interface final é só a ponta visível desse processo.
• O shadowing e os workshops com o time de CS revelaram um enorme valor na definição de informações configuráveis.
• No processo manual, o CS absorvia a ansiedade do gestor a cada etapa. Remover essa mediação sem substituí-la por outra forma de confiança teria gerado abandono, o Playground foi a resposta direta a esse risco.
• Os gestores não precisavam customizar tudo, precisavam sentir que tomavam decisões. Cards pré-definidos com exemplos contextuais satisfizeram essa necessidade sem expor a complexidade real por trás de cada opção.

• O gestor ativa a IA e perde visibilidade sobre o que acontece depois. Uma camada de monitoramento fecharia o ciclo de confiança pós-ativação e permitiria iterações contínuas no comportamento da IA.
  O fluxo foi validado com uma amostra pequena de usuários. Com mais clientes ativos, uma análise de onde os usuários hesitam ou onde abrem chamados permitiria refinar logicas da interface e fluxo com mais evidências de campo.