A demonstração que fazemos começa com as suas perguntas, não com a nossa tela.

Em resumo

Uma demonstração orientada por perguntas é a sessão em que o cliente define primeiro o caso real — a submissão, o ramo, o critério de risco da casa — e o fornecedor só então mostra o produto rodando sobre esse caso, em vez de percorrer um roteiro fixo de telas.

• 1Caso real primeiroA sessão começa com uma submissão da sua operação, não com a nossa apresentação de produto.
• 2Decisão com trilhaO que importa na tela é o caminho do dado até o preço, auditável pelo subscritor.
• 3Camada, não trocaA WIR integra via API por cima dos sistemas atuais; não substitui o core legado.
• 4Semanas, não anosO piloto é desenhado em ciclos de semanas de operação, não em anos de implantação.

A demonstração começa pelo seu caso.

As perguntas que abrem a sessão.

Quatro perguntas organizam o início. i. Por onde entra a submissão hoje — e-mail, PDF anexado, planilha compartilhada? ii. Quantas mãos tocam esse dado antes de virar preço? iii. Quais critérios de risco da casa estão escritos e quais vivem na cabeça de duas ou três pessoas? iv. O que precisaria acontecer para você considerar o piloto um sucesso, em número?

A quarta é a mais importante e a menos feita no mercado. Sem critério de sucesso declarado no início, qualquer demonstração termina com elogio e nenhuma decisão. Com critério declarado, a sessão vira um teste: ou a camada melhora o indicador que você escolheu, ou não melhora, e você descobre isso em uma hora em vez de descobrir em um ano de projeto.

Essas perguntas não são um questionário de descoberta comercial disfarçado. São a entrada do trabalho técnico: definem o que precisa ser extraído do documento, o que precisa ser validado contra apetite e o que precisa ficar registrado para auditoria. É o mesmo percurso que descrevemos em automatizar a cotação de seguros, só que aplicado ao seu ramo, com o seu vocabulário.

Por que a tela sozinha não decide.

Uma demonstração genérica falha por um motivo estrutural: ela mostra o caminho feliz, com um documento limpo que o fornecedor escolheu. Nenhuma seguradora, corretora, MGA ou operadora de saúde opera no caminho feliz. Opera com anexo girado, campo em branco, endosso fora de padrão e um subscritor que precisa justificar a recusa para o resseguro.

O que colocamos na tela depois.

Com o caso definido, a ordem se inverte: você já sabe o que quer ver e nós mostramos o percurso completo, do e-mail de entrada à decisão. A extração do documento aparece com o campo de origem destacado; a validação contra apetite aparece com a regra que disparou; o encaminhamento ao subscritor certo aparece com o motivo do encaminhamento. Quando usamos um caso-exemplo em vez do seu, ele é marcado como exemplo ilustrativo.

Também mostramos o que a camada não faz. Ela não migra, não troca e não aposenta o seu core. Integra-se via API, soma-se ao que já está rodando e pode ser desligada sem deixar a operação sem chão. Essa ressalva vale mais numa demonstração do que qualquer promessa de desempenho, porque é ela que define o risco do projeto.

Para times de subscrição, a conversa costuma descambar — no bom sentido — para o conceito de copiloto de subscrição e para a disciplina de automação da entrada de submissões. São os dois pontos em que o ganho costuma aparecer primeiro: menos transcrição, mais avaliação de risco.

O que você leva da sessão.

Três coisas saem registradas. i. O desenho do fluxo atual, do jeito que você o descreveu, com os pontos de espera marcados. ii. O que a camada resolveria nesse fluxo e o que continuaria humano, nomeado. iii. O critério de sucesso que você declarou, convertido em indicador mensurável antes do piloto.

Nenhum desses itens depende da nossa tela. Dependem das suas perguntas. É por isso que a sessão funciona mesmo quando a conclusão é que ainda não é a hora: você sai com o mapa do próprio gargalo, que vale por si.

Se algum número de mercado entrar na conversa, ele entra com a fonte declarada e fica no rodapé. Numa demonstração, o protagonista é o seu caso: o seu volume de submissões e o seu tempo de cotação.

Da pergunta à decisão, em segundos.

A WIR coloca uma camada de IA sobre a operação de seguros. Ela conecta distribuição, subscrição e inteligência operacional ao crescimento da operação, sempre por cima dos sistemas atuais, via API. Nada é migrado e nada é aposentado: o que já existe continua de pé e ganha uma camada de decisão em cima. O piloto é desenhado em ciclos de semanas de operação, não em anos de implantação — e o que cada operação obtém nesse prazo depende do caso que ela traz.

As quatro perguntas de abertura se repetem porque descrevem um gargalo conhecido do setor: submissão que entra por e-mail, dado transcrito à mão e decisão que depende de critério não escrito. A hipótese que testamos no piloto é simples, e é por isso que ela vira indicador antes de virar discurso: se a cotação sai em segundos em vez de dias, a operação tem mais chance de responder a mais submissões com a mesma equipe. Quem mede isso no seu caso é você, com o critério que declarou na primeira hora.

Se você quer testar isso com uma submissão da sua casa, comece pela página da WIR Innovation e traga o caso que mais trava a sua fila. A tela entra depois.

FAQ

Preciso enviar dados reais para a demonstração?

Não é obrigatório, mas é o que torna a sessão útil. Quanto mais próximo o caso estiver da sua fila de entrada — com anexo torto, campo em branco e endosso fora de padrão —, mais honesto é o resultado. Quando usamos um caso nosso, ele vai marcado como exemplo ilustrativo.

A WIR troca ou migra o meu core?

Não. A camada se integra aos seus sistemas via API e não os substitui. Ela soma-se ao que já está rodando e pode ser desligada sem parar a operação. Trocar o core é o outro caminho — anos de implantação e orçamento crescente.

Quem deveria participar da sessão?

Quem sente o gargalo e quem decide sobre ele. Na prática, um subscritor ou alguém da operação que conheça o fluxo real de submissões, mais o responsável por tecnologia, para tratar a integração via API desde o primeiro dia em vez de deixá-la para depois.

Serve para corretora pequena ou só para seguradora grande?

Serve para os dois perfis. O porte muda o escopo do piloto, não o método: seguradoras, MGAs, agências, corretoras e operadoras de saúde começam do mesmo jeito — um caso real da fila de entrada, um critério de sucesso declarado e a camada rodando por cima dos sistemas atuais, via API.

O que acontece depois da demonstração?

Você sai com o fluxo atual mapeado, com a separação entre o que a camada resolve e o que segue humano, e com o critério de sucesso convertido em indicador antes do piloto. A partir daí, o piloto é desenhado em ciclos de semanas de operação, não em anos de projeto.