@pabloquiroga Boa tarde!

Consegue sim!

Você precisa adicionar ao bloco onde direciona essa mensagem ativa (nas condições de saída), ou no bloco após ele, as seguintes ações:

1- HTTP para buscar as últimas mensagens trocadas com o contato: 

POST /commands HTTP/1.1
Host: {{contractId}}.http.msging.net
Authorization: {{key}}
Content-Type: application/json

{
    "id": "{{$guid}}",
    "method": "get",
    "uri": "/threads/{{contact.identity}}?$take=20"
}

2- Script para buscar o último template enviado para o contato:
 

function run(body) {

try {

if (typeof body != 'object') body = JSON.parse(body);

let items = body.resource.items;

let content = items.find((item) => {

if (item.content.type == 'template') return item;

})

return content;

}

catch (e) {

return "DebugErro: " + e;

}

}

3- Script para validar se o template foi enviado a mais de 24h.

 

function run(ultimoTemplate) {

try {

var dataUltimaMensagem = new Date(recuperaDataUltimaMensagem(ultimoTemplate));

var dataAtual = new Date();

var dataLimiteFim = new Date(dataUltimaMensagem.getFullYear(),

dataUltimaMensagem.getMonth(),

dataUltimaMensagem.getDate(),

dataUltimaMensagem.getHours() + 24,

dataUltimaMensagem.getMinutes(),

dataUltimaMensagem.getSeconds());

return (dataLimiteFim > dataAtual);

}

catch (e) {

return "Ah não, aconteceu um erro ‍♂️/n Erro: " + e;

}

}

function recuperaDataUltimaMensagem(ultimoTemplate) {

var ultimaMensagem = JSON.parse(ultimoTemplate);

var dataUltimaMensagem = ultimaMensagem.date;

return dataUltimaMensagem;

}


Ai basta colocar nas condições de saída do bloco onde adicionar essas ações, que se a variável do último script for true é pq respondeu no prazo de 24h. Caso contrato direciona para a fila padrão.

Nunca utilizei o envio de mensagem ativa do próprio atendente no Blip Desk, mas acredito que seja necessário indicar em qual bloco o contato irá cair. Se isso acontece, acho que é só colocar uma condição de saída no bloco de recepção da mensagem ativa como: “se a resposta do usuário não existe” → direcionar para um bloco receptivo que após a resposta, envia o contato para a queue geral.

Valeu demais, Lucas! Não sei se resolve pro caso onde a pessoa faz o envio individual no Growth retornando pra um operador, acredito que o retorno seja o próprio bloco de atendimento humano e essa pessoa fica em transferência direta até que o operador fique online (ou seja, fica presa mesmo no operador).

Mas a tua solução traz outras possibilidades de resolução.

Poderíamos colocar o e-mail do operador nas variáveis de contato e direcionar pra um bloco que faz essa validação de prazo, caso esteja dentro do prazo dá pra fazer um command criando o ticket pro e-mail do operador, se estiver fora do prazo desconsiderar o operador e abrir um ticket normal.

Essa abordagem com “se a resposta do usuário não existe” não funciona quando enviamos mensagem ativa.

Quando a gente dispara uma mensagem ativa, o contato fica no bloco em que foi direcionado até que ele mande uma próxima mensagem. Com isso, o “Aguardar resposta do usuário” não expira, mesmo que contenha um prazo definido para expirar.