30 perguntas a fazer antes de comprar IA de voz

Em resumo: o mesmo teste para todos os fornecedores

As demonstrações de IA de voz não são comparáveis. Cada fornecedor escolhe o seu guião, os seus dados de teste impecáveis e um interlocutor bem-comportado. Muitas vezes ganha a demonstração mais cuidada, mesmo quando não se ajusta às suas chamadas.

A solução tem três partes. Envie as mesmas perguntas por escrito a todos os fornecedores, passe todos pelo mesmo cenário de teste, construído a partir da sua linha, e pontue as respostas com pesos acordados antes da primeira demonstração. Este modelo dá-lhe as três. Parte do princípio de que a decisão de comprar já está tomada. Se não for o caso, comece pelo nosso guia para decidir entre desenvolver e comprar.

Como pontuar cada resposta

Envie as 30 perguntas antes da segunda reunião e peça uma prova com cada resposta: um documento, um registo de exemplo, uma cláusula do contrato ou uma demonstração em direto. Ponha duas pessoas a pontuar em separado, uma de operações e outra de compras ou de informática, e discuta cada pergunta em que as duas pontuações difiram em dois pontos ou mais.

1. Âmbito e cobertura do preço

Dois orçamentos só são comparáveis quando cobrem o mesmo trabalho. Estas perguntas transformam um preço num âmbito concreto.

2. Propriedade dos dados, privacidade e saída

Cada chamada gera gravações, transcrições e campos sobre os seus clientes. Defina quem os controla antes do piloto, e não na renovação. Peça controlos testados, e não apenas declarados. A página de normas de segurança da DRING mostra uma forma de os apresentar.

3. Ligação aos sistemas e registo dos resultados

Um logótipo numa página de integrações diz apenas que a ligação é possível, e não quais os campos que o agente pode ler ou alterar na edição que a sua empresa usa. Peça um mapa de campos e confirme-o no cenário.

4. Passagem para uma pessoa e controlo

A passagem para uma pessoa faz parte do desenho, não é uma falha. Confirme que o seu colega consegue continuar sem que o cliente tenha de começar do zero, e que a sua equipa consegue parar o agente.

5. Testes de qualidade e novas versões

Uma boa primeira demonstração diz pouco sobre a centésima alteração. Pergunte como é que o fornecedor prova que um agente está pronto e que uma alteração não estragou nada. A DRING descreve o seu processo de testes passo a passo. Peça a cada fornecedor que lhe mostre o seu.

6. Telefonia, níveis de serviço e falhas

Uma demonstração no browser deixa de fora a operadora, o áudio telefónico e a central que já tem. Trate a camada de telefonia como uma parte própria da comparação.

Construa um único cenário de teste com as suas chamadas

As perguntas mostram o que um fornecedor diz. O cenário mostra o que o agente faz. Comece por uma amostra de chamadas recentes, por exemplo as últimas 50, e escolha o pedido mais comum e os momentos que costumam correr mal. Crie registos de teste num ambiente de testes do seu CRM ou helpdesk, com os mesmos campos que em produção.

Partilhe o esquema com todos os fornecedores ao mesmo tempo: intenções, sistemas e registos de teste. Guarde para si as falas exatas de quem liga, para que nenhum fornecedor possa afinar o agente para um guião.

Teste numa linha telefónica real

• Ligue para um número real a partir de um telemóvel, e não de um separador do browser, com alguém da sua equipa no papel de cliente.
• Grave a sessão com consentimento e pontue-a a partir da gravação, não de memória.
• Conte quantas vezes quem ligou teve de repetir alguma coisa, e cronometre a pausa antes de cada resposta do agente.
• Depois da primeira ronda, peça uma alteração, por exemplo uma nova regra de política, e volte a correr o cenário.

A forma como o fornecedor testa e põe em produção essa alteração responde à pergunta 23 melhor do que qualquer diapositivo. O cenário dá também a prova para um 3 nas perguntas 12, 17, 18 e 28.

Some as pontuações com os mesmos pesos

Acorde os pesos antes da primeira demonstração, para que ninguém os ajuste ao seu favorito. A distribuição abaixo é um exemplo: passe pontos para as áreas em que uma falha prejudicaria mais a sua operação.

Pontuação da área = (pontos na área / 15) × peso da área. Quinze é o máximo por área: cinco perguntas a 3 pontos cada. Somadas, as seis pontuações de área dão um total de 0 a 100.

Antes de pontuar, assinale três a cinco perguntas eliminatórias, como a 6, a 13 e a 17. Um fornecedor com 0 ou 1 em qualquer pergunta eliminatória fica de fora, seja qual for o total.

Um exemplo prático

As pontuações abaixo foram inventadas para mostrar as contas. O Fornecedor A fez a demonstração mais fluida. O Fornecedor B pareceu mais simples, mas mostrou no cenário o registo dos resultados e o seu processo de testes.

O Fornecedor A teve também 1 na pergunta 13, que é eliminatória, por isso fica de fora seja qual for o total. A demonstração foi forte na conversa e fraca no que vem depois dela: o registo, o percurso em caso de falha e a versão seguinte.

Sinais de alarme nas respostas

• «Integramos com tudo», sem um mapa campo a campo para os seus sistemas.
• Nenhuma resposta a «o que ouve quem liga quando o vosso sistema está em baixo?»
• A passagem para uma pessoa resume-se a reencaminhar a chamada para um número, sem contexto para o seu colega.
• Resultados de testes apresentados como uma única percentagem global, sem método nem dimensão da amostra.
• Alterações ou atualizações de modelo entram em produção sem a sua aprovação ou sem aviso.
• Condições de saída que dizem que os dados «podem ser disponibilizados», sem formato nem prazo.

Um sinal de alarme é motivo para voltar a perguntar por escrito. Vários na mesma área mostram onde é que o trabalho real iria cair sobre a sua equipa.

Como a DRING responde a estas perguntas

Aplique o mesmo modelo à DRING. Algumas respostas já as podemos dar por escrito:

• Pergunta 21: cada agente da DRING passa por 1 000 a 10 000 conversas simuladas, criadas para a sua empresa, antes da primeira chamada real. São geradas a partir do seu processo, dos seus documentos e das suas gravações de chamadas, e não de um conjunto genérico de testes de referência.
• Perguntas 11 e 12: o HubSpot é a implementação de referência documentada para escolher para quem ligar, fazer a chamada e registar o resultado. O Connect liga o Salesforce, o Freshdesk e outros CRM e helpdesks comuns nas mesmas condições, e os objetos, as permissões, os campos personalizados e as ações exatas são confirmados durante a integração inicial. É possível definir campos de análise adicionais, que são devolvidos da mesma forma pela API, pelo CRM, pelo painel e pelos relatórios.
• Pergunta 14: os serviços para iniciar uma chamada, ver o seu estado e consultar o resultado, bem como os webhooks de ciclo de vida e de resultado, fazem parte do padrão para o processo definido no âmbito do projeto.
• Perguntas 1 e 27: o pacote da DRING é recomendado em função da utilização prevista, da capacidade de chamadas em simultâneo, do número de tipos de agente, dos canais, das necessidades de transferência em direto, do nível de apoio e da profundidade da integração. Quanto a idiomas, há 62 disponíveis e 10 em produção hoje; o seu é validado antes do arranque.

Onde a DRING pode pontuar menos à partida: um CRM de nicho ou muito personalizado é avaliado à parte antes de qualquer desenvolvimento fora do padrão entrar num orçamento. Até essa análise estar feita, a pergunta 11 pode ficar em 2. Um idioma fora do conjunto em produção deve contar como não comprovado para a sua linha até o seu cenário ter sido testado nesse idioma.

Guarde a grelha de avaliação depois de assinar

As respostas que valeram um 3 passam a ser os critérios de aceitação do piloto. O cenário de seis momentos passa a ser o primeiro teste de regressão, para que cada alteração posterior seja verificada com as chamadas que decidiram a compra.