Spark: intake conversacional com IA para inovação enterprise

One-liner: Substituí formulários fragmentados no Service Desk por uma conversa que classifica o pedido, exige contexto de verdade e só envia pra análise quando dá pra o time técnico trabalhar.

Meu papel

A ideia nasceu com a gerente da área: um agente dentro do Claude/Gemini pra ajudar no intake. Rápido ficou claro o limite desse caminho (escopo enterprise, integrações, governança de processo, experiência contínua).

Eu peguei o projeto e elevei pro que existe hoje: produto próprio, em produção.

O que eu fiz:

• Discovery e JTBD com áreas solicitantes e quem prioriza/executa
• Reuniões de entendimento de fluxos, mapeamento do processo atual e desenho do fluxo ideal
• Alinhamento e mudança de procedimentos com plataformas já existentes (board de iniciativas, Service Desk)
• Definição do agente (roteamento, anamneses, regras de completude, linguagem)
• Criação da skill de capacidade do produto (o que o Spark faz / não faz) e da regra de mantê-la atualizada a cada feature
• Construção e ship em produção (UI, agente, integrações, FAQ)
• Validação de protótipo e iteração até o lançamento

Problema

Qualquer colaborador pode propor melhoria, ideia de inovação ou pedido de tecnologia. Na prática, isso vivia em formulários distintos no Service Desk, cada um com seus campos.

Resumo: processo media presença de campo. Não media qualidade de contexto.

Solução

Spark: um canal conversacional único. A pessoa descreve o pedido em linguagem natural (ou escolhe um atalho). O agente entende a natureza da demanda, coleta o que falta e encaminha pro destino certo.

Quatro caminhos, uma experiência

Diferença crítica vs. formulário

O agente foi treinado pra evitar preenchimento raso. Se falta impacto por área, o porquê, sistema afetado ou benefício esperado, ele pergunta. Pode pausar a conversa e não enviar pra análise até o solicitante ter o mínimo necessário (status “sua vez”).

Decisões de produto

1. Roteamento por temática, não por quem abriu. Melhoria de RH proposta por Finanças vai pra Gente & Gestão. Reduz demanda na fila errada.
2. Completude antes do handoff. Sistema antigo perguntava se o campo estava preenchido. Spark pergunta se a informação serve pra alguém trabalhar.
3. Melhoria pequena na conversa; calibração humana depois. O solicitante não estima hora de desenvolvimento. Líder de vertical decide esforço e fila.
4. Triagem do líder antes do fórum de priorização. Nem tudo sobe pra reunião de portfólio. Protege caminho rápido sem perder o que precisa de olho estratégico.
5. Demanda nasce onde a operação vive. Se o time trabalha no Service Desk, o Spark abre o chamado lá (via API). Solicitante não sai da conversa. Evita “demanda fantasma” no board.
6. Clareza de capacidade como skill do agente. Criei uma skill (capacity-check) com o que o Spark pode e não pode fazer. Se o usuário traz dúvida de uso ou um pedido fora de escopo, o agente lê essa skill e redireciona na própria conversa, sem precisar abrir FAQ, chamado ou pedir ajuda humana. Regra de desenvolvimento: toda feature nova no Spark atualiza essa skill no mesmo ciclo, pra o produto não “prometer” o que não existe.

Processo

Arquitetura (visão rápida)

Escolhas técnicas relevantes:

• Voz única no chat (usuário fala com o Spark)
• Skills versionadas em markdown (comportamento do agente como código)
• Skill de capacidade do produto carregada em toda conversa (manual vivo do que o app faz / não faz)
• Servidor decide o roteamento (modelo não escolhe caminhos mutuamente exclusivos)
• Extrator estruturado separado da conversa

Resultado

Produto novo (lançamento recente). Mesmo assim, já há sinal de adoção e de pipeline:

13 iniciativas registradas em 3 dias é o número que mais importa neste estágio: o canal não só gera tráfego, gera entrada qualificada no pipeline.

Impacto qualitativo já observável:

• Demanda chega ao líder com mais contexto (menos “campo preenchido por formalidade”)
• Menos ida e volta de e-mail pedindo detalhe
• Um ponto de entrada no lugar de vários formulários
• Acompanhamento em Minhas iniciativas, com opção de reabrir a conversa
• Dúvida de escopo resolvida na conversa (via skill de capacidade), sem escalar pra FAQ/humano por padrão

Roadmap (próximo)

O intake conversacional é a base. O produto ainda tem espaço pra escalar o que hoje depende de capacidade humana das áreas de inovação e melhoria contínua:

Esses papéis ainda não estão no ar. A skill de capacidade do produto deixa isso explícito pro agente: não promete o que o roadmap ainda não entregou.

Aprendizados

1. Campo preenchido ≠ informação útil. Conversa bem desenhada mede qualidade; formulário mede presença.
2. IA no intake coleta e estrutura. Não decide capacidade operacional. Esforço e impacto multi-área ficam com humano. Já a capacidade do produto (o que o app faz) precisa estar explícita pro agente.
3. Produto conversacional sem mapa de limites alucina escopo. Skill de capacidade + regra de update por feature evita o agente inventar menu ou prometer JTBD que ainda não existe.
4. Integração segue a operação. Forçar tudo no board cria demanda fantasma.
5. Agente genérico ≠ produto. Claude/Gemini ajudam a explorar; escopo enterprise pediu produto próprio, processo e integração.
6. Abstração interna não vaza. Nomes de processo ficam no backend. Na conversa, língua de quem solicita.