Integre o Mindful Platform ao Flex

Este guia de implementação serve de orientação para fazer a integração entre o Flex e a plataforma Mindful. Com essa integração, você pode respeitar o tempo de seus clientes e dar a eles o controle, permitindo que eles escolham quando receberão uma chamada. Seja em dois minutos ou duas horas, seus clientes vão gostar de gastar menos tempo ficando em espera.

O Mindful oferece dois tipos de retorno de chamada, Customer-First ou Agent-First. Essas opções de experiência de retorno de chamada são selecionáveis por fila. Um retorno de chamada Customer-First chama os clientes de volta primeiro e garante que eles estejam prontos para o retorno de chamada. Se eles não estiverem prontos, o Mindful lida com desconexões ou correio de voz e tentará contatá‐los novamente (se configurado). Se estiverem prontos, o retorno de chamada conectará o cliente a um agente. O retorno de chamada Agent-First chama o agente primeiro e, uma vez conectado, o cliente é chamado.

Informações sobre retornos de chamada

Quando suas filas estiverem cheias e seus agentes lotados, novas chamadas inbound terão tempos de espera mais longos. Isso pode levar a chamadas abandonadas, experiência insatisfatória do cliente, aumento dos custos de serviço (à medida que você lida com tentativas repetidas por um cliente) e menos oportunidades de ajudar e se envolver com seus clientes.

Uma das melhores maneiras de reduzir o tempo de espera é dar aos chamadores uma opção de ignorá‐la completamente. Com o Mindful, você pode oferecer aos clientes a opção de ligar de volta em um horário mais conveniente. Isso funciona muito bem para contact centers que têm picos e vales em seu volume de contato; você pega o volume de contato que chega durante seu horário de pico de volume e lida com ele quando sua equipe não está tão ocupada.

Configuração da conectividade com o Mindful

Aqui está uma visão geral de alto nível da conectividade com o Mindful:

Você precisará configurar um domínio SIP e um tronco SIP que serão usados para transferir chamadas para o Minfdul, bem como um número de telefone dedicado, que será usado para os Retornos de chamada.

Siga estas etapas para estabelecer a conectividade com o Mindful:

1. Provisionar números de telefone na Twilio

No console da Twilio, vá para Active Phone Numbers (Números de telefone ativos)

Essa solução conta com dois números de telefone, um para chamadas recebidas de seus clientes e outro para chamadas recebidas do Mindful. Esses números serão roteados para fluxos separados do Studio, que serão configurados posteriormente neste documento. Não se esqueça de atualizar o roteamento desses números de telefone depois de concluir os fluxos do Studio.

2. Configurar uma lista de controle de acesso de IP

1. No console da Twilio, vá para IP / CIDR Access Control List (Lista de controle de acesso de IP/CIDR)

2. Crie uma nova ACL com os seguintes endereços:

54.165.17.177/32 - VHT SIP Proxy
54.145.183.157/32 - VHT SIP Proxy
54.87.8.161/32 - VHT RTP Proxy
3.223.253.119/32 - VHT RTP Proxy

3. Criar um domínio SIP

1. No console da Twilio, vá para Programmable SIP Domains (Domínios SIP programáveis)

2. Crie um novo domínio SIP

Dica: Use a Lista de controle de acesso de IP definida na etapa 1

Neste exemplo, as chamadas recebidas para esse domínio SIP são roteadas para um fluxo do Studio, que é configurado posteriormente neste documento. Você também pode usar outras opções, como uma função que retorna TwiML.

4. Provisionar um novo destino de chamada

1. Em Mindful, vá para Destinos de chamada, Adicionar novo CT ou clique aqui

2. Altere o Tipo de telefonia para SIP

3. Para o número de telefone do call center, digite o número de telefone que você usa para retornar chamadas a partir do Mindful.

4. Para o CID de retorno de chamada, insira os números de telefone da Twilio para os quais os chamadores estão ligando. Isso será usado como o ID do chamador ao retornar o retorno de chamada

5. Vá para a guia Metadados

6. Adicione um item de metadados chamado x-user-to-user com as seguintes configurações:

5. No Mindful, provisione um novo número de telefone

1. Vá para Phone Numbers (Números de telefone)

2. Provisione um novo número de telefone e atribua‐o ao destino da chamada configurado na etapa 4

Cenário 1: Ofereça um retorno de chamada antes que o chamador entre em uma fila de tarefas

Antes de enviar uma chamada recebida para uma fila de tarefas do TaskRouter, chamaremos uma função que usará a API Statistics do TaskRouter para determinar o tempo de espera estimado. Se isso estiver acima de um limite, ofereceremos ao chamador a opção de um retorno de chamada em vez de enviar a chamada para uma fila.

A API Statistics do TaskRouter não fornece um tempo de espera estimado verdadeiro, mas há várias maneiras de calculá‐lo. Neste exemplo, vamos manter isso simples e usar o valor AvgTaskAcceptanceTime que está disponível no TaskRouter para os cinco minutos anteriores.

No diagrama acima, o tempo de espera estimado é obtido usando o widget Run Function do Studio (no diagrama chamado de check_average_wait_time) e invocando uma Função com o seguinte código:

/**
 * Função para ler as estatísticas de avgTaskAcceptanceTime das estatísticas cumulativas do TaskRouter.
 * https://www.twilio.com/docs/taskrouter/api/taskqueue-statistics#taskqueue-cumulative-statistics
 *
 * Retorna o objeto JSON com os seguintes campos:
 * - avgTaskAcceptanceTime - número de segundos
 *
 *
 * Variáveis esperadas do contexto:
 * - Queue_Estimated_Wait_Time - valor inicial de 0, usado pelo script para armazenar em cache o valor do tempo médio de aceitação da tarefa
 * - Queue_Estimated_Wait_Time_Last_Updated - valor inicial de 0, usado pelo script para armazenar em cache o timestamp da última atualização de
 * - Queue_Update_Interval - intervalo de atualização de tempo médio em milissegundos, valor inicial de 60000
 * - Workspace_SID
 * - Task_Queue_SID
 * - Service_SID
 * - Environment_SID
 * - VAR_QEWTLU_SID - SID da variável Queue_Estimated_Wait_Time_Last_Updated
 * - VAR_QEWT_SID - SID da variável Queue_Estimated_Wait_Time
 *
 * As seguintes chamadas twilio-cli são úteis para configurar variáveis de ambiente para este script:
 *
 * twilio api:taskrouter:v1:workspaces:list
 *
 * twilio api:taskrouter:v1:workspaces:task-queues:list \
 *     --workspace-sid WSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 *
 * twilio api:serverless:v1:services:list
 *
 * twilio api:serverless:v1:services:environments:list \
 *     --service-sid ZSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 *
 * twilio api:serverless:v1:services:environments:variables:list \
 *     --service-sid ZSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
 *     --environment-sid ZEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 */

exports.handler = function (context, event, callback) {

    const response = new Twilio.Response();
    response.appendHeader('Access-Control-Allow-Origin', '*');
    response.appendHeader('Access-Control-Allow-Methods', 'OPTIONS POST');
    response.appendHeader('Content-Type', 'application/json');
    response.appendHeader('Access-Control-Allow-Headers', 'Content-Type');

    get_wait_time(context, event, callback).then(value => {
        response.setBody({
                             'avgTaskAcceptanceTime': value
                         });
        return callback(null, response);
    })

}

async function get_wait_time(context, event, callback) {
    const client = context.getTwilioClient();

    let current_timestamp = new Date().getTime();

    if ((current_timestamp - context.Queue_Estimated_Wait_Time_Last_Updated) > context.Queue_Update_Interval) {

        let average_task_acceptance_time = await get_queue_cumulative_statistics(client, context.Workspace_SID, context.Task_Queue_SID, 'avgTaskAcceptanceTime');

        context.Queue_Estimated_Wait_Time = parseInt(average_task_acceptance_time);

        await client.serverless.services(context.Service_SID)
            .environments(context.Environment_SID)
            .variables(context.VAR_QEWT_SID)
            .update({
                        key: 'Queue_Estimated_Wait_Time',
                        value: average_task_acceptance_time
                    });
        await client.serverless.services(context.Service_SID)
            .environments(context.Environment_SID)
            .variables(context.VAR_QEWTLU_SID)
            .update({
                        key: 'Queue_Estimated_Wait_Time_Last_Updated',
                        value: current_timestamp
                    });

    }

    return context.Queue_Estimated_Wait_Time;
}

async function get_queue_cumulative_statistics(twilio_client, workspace_sid, task_queue_sid, stat_name) {
    return twilio_client.taskrouter.workspaces(workspace_sid)
        .taskQueues(task_queue_sid)
        .cumulativeStatistics()
        .fetch()
        .then(stats => {
            return (stats[stat_name]);
        });
}

Se a espera estimada for maior que 120 segundos, a chamada será transferida para o Mindful via tronco SIP. Caso contrário, a chamada será enviada ao Flex por meio de uma fila de tarefas do TaskRouter.

No toolstep chamado transfer_to_vht, definimos o endpoint SIP para o qual transferimos a chamada. Este é o número de telefone que você configurou acima na etapa 5, no seguinte formato: sip:+1xxxxxxxxxx@sip-callback.mindful.cx:5566?x-user-to-user={{trigger.call.From}}

Também enviamos ao Mindful o número de telefone do chamador através do cabeçalho SIP de usuário‐para‐usuário

Cenário 2: Ofereça um retorno de chamada enquanto o cliente estiver em espera em uma fila de tarefas

Neste exemplo, a chamada recebida atinge à fila de tarefas do TaskRouter no fluxo do Studio.

A verificação do tempo médio de espera é realizada no widget Send to Flex (send_to_flex1 no diagrama acima) usando o parâmetro Hold Music TwiML URL. Em vez de apontar para Hold Music TwiML real, você pode apontar para uma função personalizada chamada hold_treatment(), que, por sua vez, chama outra função personalizada transfer_to_vht().

Código para hold_treatment:

/**
 * Esta função espera as mesmas variáveis de ambiente que wait_time.js
 *
 * Variáveis esperadas do contexto:
 - Queue_Estimated_Wait_Time - valor inicial de 0, usado pelo script para armazenar em cache o valor do tempo médio de aceitação da tarefa
 * - Queue_Estimated_Wait_Time_Last_Updated - valor inicial de 0, usado pelo script para armazenar em cache o carimbo de data/hora da última atualização de
 * Queue_Estimated_Wait_Time
 * - Queue_Update_Interval - intervalo médio de atualização de tempo em milissegundos, valor inicial de 60000
 * - Workspace_SID
 * - Task_Queue_SID
 * - Service_SID
 * - Environment_SID
 * - VAR_QEWTLU_SID - SID da variável Queue_Estimated_Wait_Time_Last_Updated
 * - VAR_QEWT_SID - SID da variável Queue_Estimated_Wait_Time
 */
exports.handler = function(context, event, callback) {
    let twiml = new Twilio.twiml.VoiceResponse();

    get_wait_time(context).then(avg_wait_time => {
        let action_url = "https://" + context.DOMAIN_NAME + '/' + 'transfer_to_vht';
        if (avg_wait_time > 120) {
            twiml.gather({action: action_url})
                .say(`Your call will be routed to an agent in approximately ${avg_wait_time / 60} minutes. Press 1 if you want to be called back`);
        }
        return callback(null, twiml);
    });

};

Código para transfer_to_vht:

exports.handler = function(context, event, callback) {
    let response = new Twilio.twiml.VoiceResponse();

    let gathered_digits = 0;
    if (event['Digits']) {
        gathered_digits = parseInt(event['Digits']);
    }
    if (gathered_digits && (gathered_digits === 1)) {
        // leave Flex queue and continue with next node connected to Task completed
        response.leave();
    }

    return callback(null, response);

};

Quando o tempo de espera estimado excede o limite, nesse caso, 120 segundos, a função retorna o TwiML <Leave>, que retorna o controle de volta ao Studio e continua com o próximo widget.

Na condição Task Created, o Studio usará o widget Connect Call To e redirecionará para o Mindful.

Encaminhamento da chamada de retorno

A última etapa deste Guia de implementação é encaminhar as chamadas de retorno do Mindful diretamente para o Flex, mas com maior prioridade. Isso deve ser usado como um acompanhamento para qualquer um dos dois cenários acima.

Podemos fazer isso com o seguinte fluxo do Studio:

Esse fluxo irá pegar o cabeçalho SIP x-user-to-user e irá defini‐lo como um atributo para a tarefa do TaskRouter. Ele também altera a Prioridade de um valor padrão de 0 para 5, para dar a essas chamadas de entrada uma prioridade mais alta. Dependendo da configuração do TaskRouter de sua organização, talvez seja necessário alterar esse valor para um valor que esteja classificado adequadamente.

Depois de conectar todos os fluxos do Studio aos números de telefone apropriados, sua solução de retorno de chamada deverá estar pronta para ser usada. Muito bem - seus clientes agradecem por salvá‐los desses longos períodos de espera!