Esta tabla contiene registros de los eventos de apertura y cierre de los tickets.
Latencia nominal: 5 minutos
Latencia máxima: 15 minutos
Objeto: clients_trustedzone.deltashare_core.tickets_new
Retención: 3 días (D-0, D-1, D-2)
Carga histórica inicial (en objeto separado): a definir
La carga histórica debe ser acordada con Blip para su disponibilidad; el objeto queda disponible por 7 días para ingestión.
Conceptos importantes:
TicketId y SequentialId
La clave única para manejar tickets siempre es el TicketId. En algunos casos, la plataforma puede reutilizar el SequentialId y encontramos la misma numeración para tickets distintos en el mismo bot.
Posibilidades de análisis:
Usuarios Únicos Transferidos
Conteo distinto de CustomerIdentity.
Tickets Abiertos
Conteo distinto de TicketId, agrupando por la columna StorageDate.
Tickets Atendidos
Conteo de la columna OpenDate.
Tickets Cerrados
Conteo de la columna ClosedDate.
Métricas de atención
Tiempo de atención: Diferencia entre la fecha de apertura (openDate) y la fecha de cierre (closeDate).
Tiempo de espera en la cola: Diferencia entre la fecha de creación del ticket (storageDate) y la fecha de apertura (openDate).
Tiempo de primera respuesta: Diferencia entre la fecha de apertura (openDate) y la primera respuesta (firstResponseDate).
Asociar tabla de tickets con la tabla de Contactos
Cuando el usuario sale del router y entra en el bot de atención, se genera un nuevo contacto con un nuevo ID dentro del bot de atención. Por lo tanto, la relación solo puede hacerse con el criterio:
Identity: 5266333asdad-asdasdasd-asdasd@tunnel.msging.net
Owner: bottransbordo@msging.net
select * from base.ticket bt
left join base.contact bc
on bt.OwnerIdentity = bc.Owner
and bt.ContactIdentity = bc.Identity
Ejemplo de query con relación entre tablas.
Importante: El contacto referente a la atención se crea cuando el ticket es abierto, es decir, cuando el usuario sale del contexto del router y entra en el bot de atención.
Por lo tanto, si un ticket fue creado en una fecha (ej.: 01/01/2025) y cerrado mucho después (ej.: 31/01/2025), la información del contacto estará disponible cercana a la fecha de creación del ticket (en este caso, 01/01/2025).
Posibilidad de obtener información detallada tras relacionar las tablas
Después de la relación, es posible obtener información adicional del contexto del usuario dentro del bot router, como datos de campañas.
Importante: Los nombres de los campos y la información guardada no se almacenan automáticamente; requieren desarrollo para definir qué campos deben guardarse en los extras.
Ejemplo de JSON de los extras de un contacto:
{
"tunnel.owner": "botIdroteador@msging.net",
"tunnel.originator": "55319999_telefone@wa.gw.msging.net",
"campaignId": "IDCampanha",
"campaignMessageTemplate": "nombreDelTemplate",
"segmento": "segmento",
"elegivelcartao": "false",
"dataexpiracao": "2025-2-12",
"telefone_employee": "",
"activeClient": "true",
"AdvisorCode": "null",
"contactid": "asdasd",
"filaAtendimentoBlip": "",
"pldfinancialapplications": "null",
"cpf": "00000000000",
"contasMesmoCelular": "null",
"usuarioCampanha": "false",
"assessorOnline": "false"
}
Métricas temporales de monitoreo del Blip Desk
Introducción
Este documento describe el proceso de transformación y extracción de métricas a partir de la tabla tickets_new en Delta Share. El objetivo es filtrar los datos correctamente y calcular métricas de tickets Abiertos, Perdidos, Abandonados, Finalizados y Cerrados.
Cálculo de Abiertos, Perdidos y Abandonados
La filtración de los datos debe realizarse con base en la columna storageDate, que representa el momento en que el cliente entra en el transbordo.
Ejemplo de Query:
SELECT
COUNT(storageDate) AS Abiertos,
SUM(CASE WHEN agentIdentity IS NULL AND Status = 'ClosedClient' THEN 1 ELSE NULL END) AS Perdidos,
SUM(CASE WHEN agentIdentity IS NOT NULL AND Status = 'ClosedClient' THEN 1 ELSE NULL END) AS Abandonados
FROM clients_trustedzone.deltashare_core.tickets_new
WHERE OwnerIdentity = 'botid@msging.net'
AND date_format(from_utc_timestamp(storageDate, 'America/Sao_Paulo'), 'yyyy-MM-dd')
BETWEEN '2025-03-18' AND '2025-03-18';
Criterios de cálculo:
Abiertos: Conteo total de registros donde storageDate cumple el filtro.
Perdidos: Tickets sin interacción con un agente (agentIdentity IS NULL) y cerrados por el cliente (Status = 'ClosedClient').
Abandonados: Tickets con interacción con un agente (agentIdentity IS NOT NULL) pero cerrados por el cliente (Status = 'ClosedClient').
Cálculo de Finalizados y Cerrados
Se filtra por la columna closeDate con conversión de zona horaria.
Ejemplo de Query:
SELECT
SUM(CASE WHEN Status IN ('ClosedAttendant', 'Transferred', 'Waiting') THEN 1 ELSE 0 END) AS Finalizados,
COUNT(storageDate) AS Cerrados
FROM clients_trustedzone.deltashare_core.tickets_new
WHERE OwnerIdentity = 'botid@msging.net'
AND date_format(from_utc_timestamp(closeDate, 'America/Sao_Paulo'), 'yyyy-MM-dd')
BETWEEN '2025-03-18' AND '2025-03-18';
Tasa de Recurrencia
Objetivo: Calcular la proporción de usuarios que abrieron más de un ticket en un intervalo de fechas.
Fórmula:
Tasa de Recurrencia = (Usuarios con más de un ticket / Total de usuarios) * 100
Ejemplo de resultado:
(2 / 3) * 100 = 66.67%
Tiempos de Atención
Objetivo: Calcular los tiempos promedio de atención en diferentes fases.
Métricas:
Tiempo medio de espera en la cola.
Tiempo medio hasta la primera respuesta.
Tiempo medio de espera total.
Tiempo medio de atención.
(Se mantienen las queries con sus cálculos y formato de salida en HH:MM:SS).
Conclusión
Este procedimiento asegura que los datos se filtren correctamente y que las métricas se calculen de manera confiable. La tasa de recurrencia y los tiempos de atención permiten evaluar la efectividad del soporte.
Para más información, acceda a la discusión en nuestra comunidad o a los videos en nuestro canal. 😃