Pular para o conteúdo

ADR 0004 — Quem atende o visitante do site é a Taly, por voz no browser

Status: canônico · Escopo: Quem fala com o visitante de tactflow.io, por qual transporte, e o que esse agente pode prometer · Atualizado em: 2026-08-11

Registra por que o agente que atende o visitante do site é a Taly — a assistente da própria marca — e não uma encenação de empresa cliente, e por que ela atende no browser e não por um número de telefone publicado na página. Existe porque as três opções foram propostas ao repensar o funil /talk em 11/08/2026, e duas delas contrariavam decisões que já estavam no código sem estarem registradas como decisão.

O hero do site tem um CTA só, “Talk to it”, e nada fala: não existe cliente Vapi Web no site, o VoiceDriver é comentário, e POST /talk/voice-session responde 501. O que foi para o ar é o formulário da Taly sem a Taly.

O desenho já apontava para ela, em quatro lugares independentes:

  • o passo intro do funil é ela se apresentando (Hi — I'm Taly.) e não coleta nada de propósito;
  • a máquina de funnel.ts existe para “um funil só, dois drivers” — clique e voz chamando os mesmos métodos;
  • POST /talk/voice-session está no contrato com a forma de uma sessão Vapi Web ({ assistant, publicKey }), não de uma ligação;
  • o glossário separa as duas figuras: Taly é o agente do site, que qualifica o visitante e vende a Tactflow, e é diferente do agente do telefone, que agenda serviço para o cliente do nosso cliente.

E a Tactflow já é tenant dela mesma: config/tenants/tactflow.json traz unit, timezone, greeting e contact capture; config/verticals/tactflow.json traz a offering setup-call de 30 minutos, o disclosureLevel: brand_assistant e o limite explícito “answers questions about the product; it does not quote pricing”.

Ao repensar a experiência, duas alternativas foram propostas antes desta: publicar um número de telefone no hero como demo primário, e fazer o visitante conversar com uma empresa fictícia (Arlington HVAC) para sentir o produto do lado do cliente. As duas foram recusadas.

Quem atende o visitante do site é a Taly, assistente da marca, por voz no browser.

  • Persona: a Taly atende como Tactflow. Ela não encena ser cliente de serviço, e nenhuma empresa fictícia atende o visitante.
  • Transporte: Vapi Web, na página. Não há número de telefone publicado como demo primário.
  • O que ela faz: conduz o funil, responde dúvidas sobre como o produto funciona, pede contato e agenda a setup-call na agenda da Tactflow.
  • O que ela não faz: não fala preço — preço só nas calls humanas, como já manda a regra 2 do funnel.ts e a config do vertical.
  • Contato é sempre digitado, mesmo com voz: o STT erra exatamente nos caracteres que precisam estar exatos. Ela pede, a tela abre o campo.
  • Todo passo continua concluível clicando. A voz é caminho, não requisito — quem nega o microfone termina o funil.

Fica mais fácil: a sessão do browser é a identidade, então acompanhar a conversa na tela e gravar o lead saem quase de graça — um telefone fora da aba exigiria casar a ligação por caller ID. Cada conversa produz pipeline real (uma call agendada na nossa agenda) em vez de um artefato descartável numa agenda de demonstração. E a mensagem fica sendo dogfooding verificável: o que atende o telefone da Tactflow é o que a Tactflow vende.

Fica mais difícil: a falha cai na nossa marca. Uma resposta errada da Taly com um prospect não tem o amortecedor do “é só um demo” — o que exige base de conhecimento com limite declarado, e não boa vontade de prompt. Além disso o publicKey é chave pública de verdade, usável de qualquer origem, então teto de minutos por sessão, por IP e por dia passa a ser parte do trabalho, não hardening posterior.

Passa a ser proibido: fazer a Taly encenar cliente de negócio de serviço; fazer a Taly cotar preço; e prometer, por voz, capacidade que o produto não tem — cancelar por voz, por exemplo, não existe.

O que isto não resolve: o visitante não vê o produto fazendo o trabalho dele (atender, fazer intake, agendar o job). A Taly transfere a crença por analogia — “me atendeu bem, deve atender meu cliente” — e isso não é a mesma coisa que ouvir a própria linha ser atendida. O caminho para resolver está registrado como plano futuro e depende de superfície visual na página, não de mais voz.

AlternativaPor que perdeu
Número de telefone no hero como demo primárioProva o canal real e entrega o áudio que o cliente do lead de fato ouve (PSTN em 8kHz μ-law), o que a voz no browser não faz — mas cobra caro por isso. No desktop exige trocar de aparelho, e o demo não acontece. O telefone fica fora da aba, então acompanhar a conversa na tela exigiria casar por caller ID, que era a única infra nova de verdade da proposta. E o contrato já estava escrito para Web. Não está morta: virou plano futuro, como segundo passo de quem já está convencido.
Role-play de empresa fictícia atendendo o visitanteContraria a distinção que o glossário já registrava — Taly vende a Tactflow, o agente do telefone agenda para o cliente do nosso cliente —, exige avisar na tela que a empresa não existe, e produz um agendamento descartável numa agenda de demonstração em vez de uma call na nossa. E erra o momento: quem está na landing está avaliando fornecedor, não contratando serviço de HVAC.
A Taly oferecer o número do demo durante a conversaSeria o que um bom SDR faz, mas ela teria que soletrar o número por voz, e não existe nada na interface que mostre esse número na tela. É o espelho da regra de entrada: o STT erra o caractere que precisa estar exato, e o TTS tem o mesmo problema com dígito. Adiada por falta de superfície visual, não por discordância.
Manter a calculadora como prova central da páginaEla é honesta e continua no funil, mas devolve ao lead a aritmética que ele mesmo inventou — é a prova mais fraca disponível para um produto cuja mágica é atender o telefone. Muda de papel: dimensiona a dor de quem já se convenceu, em vez de tentar convencer sozinha.